共计 3020 个字符，预计需要花费 8 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关基于 Kubernetes 如何实现蓝绿发布，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
前言
软件世界比以往任何时候都更快。为了保持竞争力，需要尽快推出新的软件版本，而不会中断活跃用户访问，影响用户体验。越来越多企业已将其应用迁移到 Kubernetes。
在 Kubernetes 中有几种不同的方式发布应用，所以为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了，丸趣 TV 小编将讲解在 Kubernetes 使用蓝绿更新的方式更新镜像。
原理
蓝绿发布是版本 1 与版本 2 会同时存在，通过控制 Service 来决定使用具体哪一个版本，也称为红黑部署。蓝绿发布与滚动更新不同，版本 2（绿）与版本 1（蓝）一起部署，在测试新版本满足要求后，然后更新 Service 对象，通过替换 label selector 中的版本标签来将流量发送到新版本，更新过程如下图所示
实践使用 Kubernetes 原生方式升级应用准备
image
bebullish/demo:v1
bebullish/demo:v2deployment-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: 8080deployment-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: 8080service
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 版本即可。
使用 CODING CD 方式升级应用创建服务
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 开头
配置 yaml 及绑定制品
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 版本同时存在的时间差。
上述就是丸趣 TV 小编为大家分享的基于 Kubernetes 如何实现蓝绿发布了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
