持续部署入门:基于 Kubernetes 实现蓝绿发布

时间:2022-07-24
本文章向大家介绍持续部署入门:基于 Kubernetes 实现蓝绿发布,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

前言

软件世界比以往任何时候都更快。为了保持竞争力,需要尽快推出新的软件版本,而不会中断活跃用户访问,影响用户体验。越来越多企业已将其应用迁移到 Kubernetes。

在 Kubernetes 中有几种不同的方式发布应用,所以为了让应用在升级期间依然平稳提供服务,选择一个正确的发布策略就非常重要了,本篇文章将讲解在 Kubernetes 使用蓝绿更新的方式更新镜像。

原理

蓝绿发布是版本 1 与版本 2 会同时存在,通过控制 Service 来决定使用具体哪一个版本,也称为红黑部署。蓝绿发布与滚动更新不同,版本 2 (绿) 与版本 1()一起部署,在测试新版本满足要求后,然后更新 Service 对象,通过替换 label selector 中的版本标签来将流量发送到新版本,更新过程如下图所示

实践

使用 Kubernetes 原生方式升级应用

准备

image

bebullish/demo:v1bebullish/demo:v2

deployment-v1

apiVersion: apps/v1kind: Deploymentmetadata:  name: demo-dp-v1spec:  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/v1kind: Deploymentmetadata:  name: demo-dp-v2spec:  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: v1kind: Servicemetadata:  name: demo-servicespec:  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 版本即可。

使用 CODING CD 方式升级应用

创建服务

service

apiVersion: v1kind: Servicemetadata:  name: demo-servicespec:  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 开头

配置 yaml 及绑定制品

replicaSet

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: demo-rsspec:  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:https://spinnaker.io/guides/user/kubernetes-v2/traffic-management/

RolloutStrategies:https://spinnaker.io/guides/user/kubernetes-v2/rollout-strategies/

CODING 持续部署:https://help.coding.net/docs/cd/overview.html