容器平台,难落地
技术升级改造过程,最难落地的部分就是—容器化。
原因是微服务化后,再加上容器化,肯定会遇到部署难,调试难,访问难,配置难。
难就难在,任何一个没有解决,都没法完全落地。
本文说说容器化工作的容器平台,这部分落地的一些心得。
容器平台成果与技术图谱
容器平台难落地,也难在涉及多层次的技术。
涉及 网络、容器、应用框架(Java 微服务的注册中心、配置中心)。
以容器层为中心,向上涉及应用微服务框架、向下涉及容器网络、基础网络。还涉及DevOps工具链、CICD。
目前落地成型后,涉及到的技术:
技术选型 | 地址 | 说明 |
---|---|---|
rancher | https://rancher.com/products/rancher/ | 多k8s集群管理工具 |
rke | https://rancher.com/products/rke/ | 一种k8s发行版 |
tke/ack/cce | 见腾讯云、阿里云、华为云的容器服务 | 公有云k8s paas服务 |
nginx-ingress/traefik | https://github.com/kubernetes/ingress-nginx | ingress controller |
nacos | https://nacos.io/en-us/ | 微服务配置中心、注册中心 |
vyos/nat/路由器/交换机 | https://wiki.vyos.net/ | 可云上部署的,多种协议的路由器、交换机、防火墙 |
s2e-runner | https://github.com/chimeh/cicd-s2e-runner | 二次开发的cicd |
helm | https://helm.sh/ | 开源k8s 部署工具 |
docker-compose | https://docs.docker.com/compose/reference/ | 单机 docker 化工具 |
xxxxxxxxxxxx |
神器 : Rancher
开发小M:应用部署后,我想看日志,看应用访问地址,是否Runing …
要实际大幅提高研发体验,提高效率、质量。除了rancher 安装之外还有不少工作要做。
心得:
- 和AD/LDAP集成,合理分配权限。跟组织架构对应。
- 配置域名与https。
- 【重要】取名很重要,大幅降低名称相关的沟通。尤其是代码仓库、应用名称、包括deployment、service 有简单因素关联,比如都以git仓库名为名。
- rancher cluster和业务cluster分离。
- 合理设计rancher个数,比如beta、prod一个rancher;非生产的一个rancher
- 公有云使用import 方式管理Kubernetes;
- 私有云使用import 方式管理Kubernetes;
- Project 、Namespace、应用环境有明确对应关系。-dev、-test、-uat、-beta、-prod
- 敢于做技术取舍。像pvc、statefulset,可维护性低的技术能不用则不用。
下图为某项目,多个微服务应用部署到 Rancher, 的截图。
私有云k8s: RKE,装!
工作不仅仅是安装。要想大幅提高开发、测试效率。在于安装之外,包括网络、访问方式等方面精心考虑,精心规划!
心得:
- 【重要】控制面master与负载面分离。
- 【重要】规划 容器CIDR。解决访问难问题。
- 【重要】underlay 网络与overlay 容器网络 统一IP空间,统一规划,打通链路。方便访问,才能提高调试效率。
- 部署ingress(nginx-ingress/traefik/kong-ingress)。解决访问难问题。
- 泛域名通配符解析,以便ingress 一旦创建,流量就能进入集群。
- 自建DNS服务。配合泛域名解析。
- 结合人员组织架构、项目、环境类型;规划RKE。
- import 到rancher中。
- 公有云、私有云混合网络,充分利用公有云 数据库PaaS。
公有云k8s:TKE/ACK/CCE,买!
部署简单,就是买!买容器服务 腾讯云TKE/阿里云ACK/华为云CCE。
精心规划!
提高效率、提高可维护性,还也在于,在VPC网络、容器网络、ingress、域名、域名解析方面的巧妙设计:
心得:
- 参考上一章节私有云心得。
- 统筹考虑 私有云CIDR、公有云VPC CIDR、容器CIDR、办公网络CIDR。
- 利用SSL V|P|N、Ipsec、OSPF、vxlan等网络技术 解决访问难、调试难问题。
代码容器化:代码模板
Q:我的新的代码怎么支持CICD?
容器化,不就是写个Dockerfile吗?
实际上引入微服务技术后,git代码仓库的量变多。就没那么简单了。
A:把那3个文件 COPY 到你顶级目录,提交!
做的工具/流程/指导文章是否好,我们内部经常用于自我评价的:
一句话比一篇文章好、一条命令比几个步骤好!
代码模板,解决什么问题呢,心得:
- 屏蔽技能问题。不是每个前后端开发都会写Dockerfile。
- 解决标准统一问题。 各个开发写的Dockerfile 基础镜像,entrypoint等都各不一样,Dockerfile 文件目录位置不一样。
- 解决以上问题。尤其是微服务技术下,Git仓库量多,放大了以上问题。
- 统一的代码目录结构。优点不言而喻。
- CICD标准化。更加方便CICD工具处理。
java 微服务工程模板
仓库名规范: 字母开头,不含点,全小写,可用于域名一部分。
注意 docker-entrypoint.sh 已写成通用的!
cicd-java-refer/
├── docker
│ ├── docker-entrypoint.sh
│ ├── healthy.sh
│ └── ready.sh
├── Dockerfile
├── pom.xml
├── README.md
├── src
│ └── main
│ ├── java
│ └── test
│ └── resources
开发人员只需要简单2步,即可支持CICD:
xxx 是你的git 代码仓库
1. 拷贝 docker/ 整个目录,到 xxx 第一级目录,无需修改。
2. 拷贝 .gitlab-ci.yml,到 xxx 第一级目录,无需修改。
3. 拷贝 Dockerfile,到 xxx 第一级目录,可能需要修改里面EXPOSE。
4. git commit 。
cicd runner:二次开发、容器化、工具化!
站在
所以:
开发小M:源码给你,帮我部署到Dev环境。
运维小O:点一下gitlab的那个按钮!
运维小O:不想写yaml,简单一条命令或者一个鼠标左键,能搞定就好了。
场景:你维护者3个项目,6个环境的CICD,共70个git project,你会遇到什么问题、难题?
万众归一,所有的流水线能需要 artifact构建、扫描、docker 构建、入库、部署,能不能写成一个通用工具。我只需要维护好、使用好这个工具即可!
心得:
开发一个易用性好的命令行工具,能一条命令完成 源码检测、构建、docker构建、k8s部署、应用IP访问生产、域名生成。
巧妙设计namespace:容器环境与灰度
开发小M:每次生产上线,怕!没有安全感。
环境及灰度部署设计,给研发以安全感。
这里的环境设计要综合考虑 基础设施成本、维护成本、团队规模、团队技术能力、可用性、上线稳定性要求。
在非生产的易用性、生产的上线稳定性的的一些,
心得:
- 生产环境引入beta部署,方便快速在线上验证,并且影响最小化。这对上生产的信心很重要。巧妙的地方在生产两套入口、两套业务容器(namespace)、两套配置中心、但是共用数据库、部分共用注册中心。
- 生产上多个层次的高可用考虑。在云平台地域、网络层、容器层、应用部署层、上线操作过程均做考虑。
- 生产应用容器的灰度部署考虑。比如一个应用两个deployment,每个deployment多个pod。
环境 | 访问入口(域名/IP) | 业务容器 namespace | 配置中心 | 注册中心 | 数据库 |
---|---|---|---|---|---|
dev环境 | 独立 | 独立,xxx-dev | 独立 | 独立 | 独立 |
test环境 | 独立 | 独立,xxx-test | 独立 | 独立 | 独立 |
uat&pre环境 | 独立 | 独立,xxx-uat | 独立 | 独立 | 独立 |
beta&prod环境 | 独立,2个独立入口,prod入口对外服务 | 独立 | 独立 | 共用 | 共用,beta和prod共用数据库,prod 有灰度 |
创造性的网络互联:打通办公网、容器网络
开发小M:我本地开IDE,想连入环境调试一下,调用过来!
待续
巧妙的泛域名解析:ingress 自动化零介入
运维小O:每个应用都要去配域名DNS,好繁琐啊
待续
神器在手,就没有困难吗?
用了Rancher,容器平台,就没有困难了吗? 不,困难问题还不少,根据落地的经验,一一道来。
应用 - 构建难、部署难
运维小O:我在加班,几十个Dockerfile,几十个.gitlab-ci.yaml 又得改一遍。
开发小M:我的应用部署道XX环境了吗?
运维小O:几百个应用,搞不过来啊,上百个yaml要写改呢。
如果不是微服务架构,请跳过部署难。微服务架构下,部署问题会成为一个比较严重的问题。
体现在:
难点1:人工部署缺乏规范性
- 名称不规范。deployment、service name。服务数量超过10个,业务开发天天问,应用A部署名称是A1,应用C怎么也是A2,不能取C吗?晕!晕!晕!!
- label 不规范。这个service到底是哪些deployment的service。能不能统一一下。
难点2:人工部署工作量大
- 一个项目应用Git代码仓库多个。Git 40+,docker镜像 40+。
- 环境3+多。Dev、Test、Prod,怎么也得3套吧,还不说UAT、Beta。
- 项目多。ToB行业,怎么也得3个项目吧。
- yaml 文件多。每个应用 3+ 个yaml文件,
deployment.yaml
,service.yaml
,configmap.yaml
,还不说 ingress - 流水线文件维护量大。 维护40个
.gitlab-ci.yaml
或Jenkinsfile
,改一下都要改40多次。
很快,团队中都有个人专职 yaml boy了。一个项目维护至少 N405*3=600个yaml。
难点3:人工部署工作重复、易出错
解决要点
要点1: 启用 CICD 流水线,支持自动部署。
要点2:赋能开发人员自助配置流水线,非常强调简单性、零维护。
- CICD流水线化。非常强调自动化,简单性,零维护。
- CICD流水线配置要及其简单,交给开发。 让开发做最简单的事情,Ctrl-C,Ctrl-V,鼠标单击。
如何达到这些要点呢?
#s2i:1
stages:
- s2i
s2i:
stage: s2i
script:
- s2i .
举例,某个工程支持cicd,只需要把以上代码复制、粘贴替换到.gitlab-ci.yaml
(类似于Jenkinsfile)里,然后提交。s2i完成了很多事情。而devops,只需要维护s2i就行了。
要点3:runner 容器化,和工具集成
场景:来了一个项目,又得搞一个runner或者jenkins-slave。A项目要求kubectl版本1.13,B项目要求1.18。天天yum install, apk add。
既然业务应用容器化,CICD的工具也容器化,不香吗
开源出来地址:https://github.com/chimeh/cicd-s2e-runner/blob/master/Dockerfile
要点4:把应用的源码检测、构建、质量扫描、打docker、生成yaml、部署等等写成一个通用工具s2i
usage:
A cicd tool, from src to artifact, to docker img, deploy into kubernetes:
I. default do all action(artifact,docker,deploy):
s2i /path/to/srctop
II. only do specify action:
s2i /path/to/srctop [ analysis|artifact|docker|deploy|deploy-update-blue ]
1. only do artifact
s2i /path/to/srctop artifact
2. only do docker build push
export DOCKER_REPO=harbor.benload.com
export DOCKER_NS=bu5
s2i /path/to/srctop docker
3. only do kubernetes deploy
export K8S_KUBECONFIG=/root/.kube/config
export K8S_NS_SUFFIX=-dev
export K8S_NS=default
export K8S_DOMAIN_INTERNAL=benload.cn
export K8S_DOMAIN_PUBLIC=bu5-dev.tx
export INGRESS_INTERNAL_ENABLED=1
export INGRESS_PUBLIC_ENABLED=1
export INGRESS_CLASS_INTERNAL=nginx
export INGRESS_CLASS_PUBLIC=nginx
s2i /path/to/srctop deploy
III. do exec cmd:
s2i /path/to/rundir exec wrappercmd [...]
1. do ls on /root directory
s2i /root ls
应用 - 访问难
开发小M:xxx 应用的访问地址是啥?
开发小M:帮我配置一下域名、IP端口,我要公网https访问。
运维小O:好多yaml要写啊!又写错了
运维小O:靠,NodePort端口冲突!
应用部署进Kubernetes集群内了。部署搞定、下一步要访问了。
访问难,难在哪?
难点1:部署后,不能立即直接访问
主机/系统/应用 、主机/系统/docker-compose/应用 方式部署时,访问简单直观。可以使用HOST-IP和HOST-PORT, 如下图。
但是,Kubernetes 里的应用访问呢?
NodePort、Ingress、LoadBalancer配置?微服务化后,难!难在人工工作量大,难在人工缺乏规范性。
难点2:用NodePort 端口有限,不直观,人工配置
- 用NodePort 端口难管理。
- 用NodePort 研发人员记不住。
难点3:用ingress 只支持https(s),人工配置工作量大
- 用 ingress,几十上百个ingress yaml 谁来写。
- 用ingress 不支持TCP。只有http,https,纯粹TCP呢,集群外怎么访问?
解决要点
应用 - 调试难
开发小M:这个IP地址:端口是哪个应用的地址?又忘了
开发小M:有没有https
开发小M:每次调试都要提交代码走CICD好慢啊,能不能本地调
开发小M:哪里看日志?
开发小M:…,效率好低,又得加班
解决要点
待续…
应用 - 配置难
开发小M:容器重启以后啥都没了,我配置放哪里,
开发小M:DEV、TEST的数据库的地址不一样
待续…
解决要点
待续…
应用 - 权限难
测试小T:谁把我的应用容器重启了,我在测试啊
开发小M:谁重启了我的应用。。。
待续…
待续…
应用 - 上线难
开发小M:我要上生产,怎么个流程
待续…
集群 - 稳定难
待续…
集群 - 混合云
待续…
人员 - 多业务部门
待续…
应用 - 日志/监控/APM
待续…
思考
DevOps部门平台化OR部门化?
待续…
颠簸的技术升级历程回顾
回顾一下我们的容器平台历程,有一些参考意义。
docker-compose 阶段
地址:http://docs.rancher.com/rancher/v1.6/en
评价 | 说明 |
---|---|
优 | |
劣 |
kubernetes dashboard 阶段
地址:https://github.com/kubernetes/dashboard
评价 | 说明 |
---|---|
优 | |
劣 |
okd(openshift) 阶段
地址:https://docs.okd.io/
评价 | 说明 |
---|---|
优 | |
劣 |
Rancher/RKE/TKE/容器服务阶段
RKE 地址:https://rancher.com/products/rke/
Rancher地址:https://rancher.com/products/rancher/
评价 | 说明 |
---|---|
优 | |
劣 |
下一个阶段,servicemesh?
2020年初,我们经过评估,servicemesh的复杂性过高。
还需要等待技术更成熟,包括易用性,再考虑升级到servicemesh。