软件世界比以往任何时候都更快。为了保持竞争力,需要尽快推出新的软件版本,而不会中断活跃用户访问,影响用户体验。越来越多企业已将其应用迁移到 Kubernetes。
在 Kubernetes 中有几种不同的方式发布应用,所以为了让应用在升级期间依然平稳提供服务,选择一个正确的发布策略就非常重要了,本篇文章将讲解在 Kubernetes 使用蓝绿更新的方式更新镜像。
蓝绿发布是版本 1 与版本 2 会同时存在,通过控制 Service 来决定使用具体哪一个版本,也称为红黑部署。蓝绿发布与滚动更新不同,版本 2 (绿
) 与版本 1(蓝
)一起部署,在测试新版本满足要求后,然后更新 Service 对象,通过替换 label selector 中的版本标签来将流量发送到新版本,更新过程如下图所示
image
bebullish/demo:v1 bebullish/demo:v2
deployment-v1
apiVersion: apps/v1 kind: Deployment metadata: name: demo-dp-v1 spec: selector: matchLabels: app: demo version: v1 replicas: 3 template: metadata: labels: app: demo version: v1 spec: containers: - name: demo image: bebullish/demo:v1 ports: - containerPort: 8080
deployment-v2
apiVersion: apps/v1 kind: Deployment metadata: name: demo-dp-v2 spec: selector: matchLabels: app: demo version: v2 replicas: 3 template: metadata: labels: app: demo version: v2 spec: containers: - name: demo image: bebullish/demo:v2 ports: - containerPort: 8080
service
apiVersion: v1 kind: Service metadata: name: demo-service spec: selector: app: demo version: v1 # 通过更改 version 来控制流量走向 type: LoadBalancer ports: - port: 80 targetPort: 8080 protocol: TCP
将上述 deployment-v1
以及 service
保存为 yaml 文件,使用 kubectl apply -f
命令创建 yaml 资源,等待创建成功后,使用 kubectl get svc
获取 EXTERNAL-IP。
如果使用浏览器测试的话,你会发现每次调用都会返回同一个 pod 的名字,那是因为浏览器发出的请求包含 keepAlive,所以需要使用 curl 来保证每次发出的请求都是重新创建的。
curl -X GET http://${EXTERNAL-IP}
将上述 deployment-v2
保存为 yaml 文件,使用 kubectl apply -f
命令创建 yaml 资源,切换流量之前先执行命令,以便查看镜像更新过程
while true; do curl -X GET http://${EXTERNAL-IP} ; done
等待 deployment-v2
创建成功后,通过将 service 的 version 值改为 v2 来切换流量
kubectl edit service demo-service
首先可以发现在更新过程中,程序保持一直可用的状态,v2 版本部署成功之后,所有请求还是 v1 版本,当流量切换后,立刻出现 v2 版本的日志,并且不会出现 v1 版本的日志,说明流量是一次性切换的,如果需要回滚只需要将流量切回 v1 版本即可。
service
apiVersion: v1 kind: Service metadata: name: demo-service spec: selector: createBy: demo-service # 这里填写的标签,会被添加到对应的 ReplicaSet 中 type: LoadBalancer ports: - port: 80 targetPort: 8080 protocol: TCP
这里注意,service 创建之后应不会匹配到任何资源,即 endpoint 为空,而在后面执行部署流程时会为 ReplicaSet 添加 label createBy: demo-service
,从而决定流量走向。
部署成功之后可以看到 demo-service
使用 docker 官方镜像需要以 docker.io
开头
replicaSet
apiVersion: apps/v1 kind: ReplicaSet metadata: name: demo-rs spec: replicas: 3 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - image: docker.io/bebullish/demo name: demo ports: - containerPort: 8080
阶段中选择 部署(Manifest)
,输入上述 yaml 文件(目前发布策略选项仅支持 ReplicaSet),这里需要把镜像的版本删除掉,在需要绑定的制品选择之前配置的制品。这样配置之后,每次执行的时候版本是动态传入的。
在下方勾选让 CODING 部署控制台管理入口流量,然后选择 demo-service
所在的命名空间(我这里是在 marlon
这个命名空间下),然后选择 demo-service
,策略选择 Red/Black(Blue/Green),保存即可。
选择应用和部署流程,输入版本 v1。
等待一小段时间后,就可以在部署控制台中看到发布的资源了。
再次执行发布,版本输入 v2。
基于 CODING CD 的蓝绿发布和一般的蓝绿发布略有不同,一旦 v2 版本的 pod 处于就绪状态后,他就会立即获得流量,而当所有的 v2 版本的 pod 处于就绪状态后,会禁用 v1 版本的 pod,此时所有流量会打到 v2 版本上,从而完成更新。
注意:基于 CODING CD 的蓝绿发布会出现 v1 版本和 v2 版本同时获得流量的情况,具体取决于 pod 的就绪探针,v2 版本的 pod 一旦就绪,那么它就会获得流量,所以需要合理设计就绪探针,尽量减少 v1 版本和 v2 版本同时存在的时间差。
使用 Kubernetes 原生方式实现蓝绿更新步骤较多,但也容易出错,推荐使用 coding.net 提供的 CD 功能,配置一次,永久使用。不仅降低了人工成本,提高容错率,还提供了非常丰富的 CD 功能,推荐使用哦~
TrafficManagement
RolloutStrategies
CODING 持续部署