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

前言

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

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

原理

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

实践

使用 Kubernetes 原生方式升级应用

准备

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 版本即可。

使用 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 版本同时存在的时间差。

总结

使用 Kubernetes 原生方式实现蓝绿更新步骤较多，但也容易出错，推荐使用 coding.net 提供的 CD 功能，配置一次，永久使用。不仅降低了人工成本，提高容错率，还提供了非常丰富的 CD 功能，推荐使用哦~

参考文章

TrafficManagement

RolloutStrategies

CODING 持续部署