持续部署入门：基于 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 持续部署

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！