关于git:CODING-DevOps-Nginxingress-实现自动化灰度发布

作者：王炜，CODING DevOps 后端开发工程师，领有多年研发教训，云原生、DevOps、Kubernetes 资深爱好者，Servicemesher 服务网格中文社区成员。取得 Kubernetes CKA、CKAD 认证。

在 Kubernetes 上的利用实现灰度公布，最简略的计划是引入官网的 Nginx-ingress 来实现。

咱们通过部署两套 deployment 和 services，别离代表灰度环境和生产环境，通过负载平衡算法，实现对两套环境的依照灰度比例进行分流，进而实现灰度公布。

通常的做法是当我的项目打包新镜像后，通过批改 yaml 文件的镜像版本，执行 kubectl apply 的形式来更新服务。如果公布流程还须要进行灰度公布，那么能够通过调整两套服务的配置文件权重来管制灰度公布，这种形式离不开人工执行。如果我的项目数量多，灰度的时间跨度过长，人为误操作的概率将大大增加，过于依赖于人工执行，这对于 DevOps 工程实际是不能忍耐的。

那么，有没有一种形式可能实现无需人工干预的自动化灰度呢？例如在代码更新后，主动公布到预公布和灰度环境，并在一天的工夫内主动将灰度比例从 10% 权重进步到 100%，且可能随时终止，灰度通过后主动公布到生产环境？

答案是必定的，利用 CODING DevOps 就可能满足此类需要。

迅速回顾一下 Nginx-ingress 的架构和实现原理：

Nginx-ingress 通过前置的 Loadbalancer 类型的 Service 接管集群流量，将流量转发至 Nginx-ingress Pod 内并对配置的策略进行查看，再转发至指标 Service，最终将流量转发至业务容器。

传统的 Nginx 须要咱们配置 conf 文件策略。但 Nginx-ingress 通过实现 Nginx-ingress-Controller 将原生 conf 配置文件和 yaml 配置文件进行了转化，当咱们配置 yaml 文件的策略后，Nginx-ingress-Controller 将对其进行转化，并且动静更新策略，动静 Reload Nginx Pod，实现主动治理。

那么 Nginx-ingress-Controller 如何可能动静感知集群的策略变动呢？办法有很多种，能够通过 webhook admission 拦截器，也能够通过 ServiceAccount 与 Kubernetes Api 进行交互，动静获取。Nginx-ingress-Controller 应用后者来实现。所以在部署 Nginx-ingress 咱们会发现 Deployment 内指定了 Pod 的 ServiceAccount，以及实现了 RoleBinding，最终达到 Pod 可能与 Kubernetes Api 交互的目标。

为了实现以上指标，咱们设计了以下继续部署流水线。

此继续部署流水线次要实现了以下几个步骤：

1、主动部署到预公布环境
2、是否进行 A/B 测试
3、主动灰度公布（主动进行 3 次逐步晋升灰度比例）
4、公布到生产环境

同时，本文案例还演示了从 Git 提交代码到主动触发继续集成的步骤：

1、提交代码后触发继续集成，主动构建镜像
2、镜像构建实现后，主动推送镜像到制品库
3、触发继续部署

1、提交代码后触发继续集成，主动构建镜像并推送到制品库

2、触发继续部署，并公布到预公布环境

3、人工确认：进行 A/B 测试（或跳过间接进入主动灰度）

进行 A/B 测试时，只有 Header 蕴含 location=shenzhen 能够拜访新版本，其余用户拜访生产环境依然为旧版本。

4、人工确认：是否主动灰度公布（主动进行 3 轮逐步晋升灰度比例，每轮距离 30s）

第一次灰度：新版本 30% 的灰度比例，此时拜访生产环境大概有 30% 的流量进入新版本灰度环境：

30s 后主动进行第二轮灰度：新版本 60% 的灰度比例：

60s 后主动进行第三轮灰度：新版本 90% 的灰度比例：

本案例中，咱们配置了自动化灰度公布将会以 3 次渐进式进行，每次进步 30% 的比例，每次继续 30s 后主动进入下一个灰度阶段。在不同的灰度阶段，会发现申请新版本呈现的概率越来越高。渐进式的灰度可依据业务须要进行任意配置，例如继续 1 天工夫分 10 次主动进行灰度，直至公布到生产环境而无需人工值守。

5、灰度实现，30s 后公布到生产环境

我的项目源码地址：https://wangweicoding.coding….

├── Jenkinsfile  # 继续集成脚本
├── deployment
│   ├── canary
│   │   └── deploy.yaml   # 灰度公布部署文件
│   ├── dev
│   │   └── deploy.yaml   # 预公布部署文件
│   └── pro
│       └── deploy.yaml   # 生产部署文件
├── docker
│   ├── Dockerfile
│   └── html
│       └── index.html
├── nginx-ingress-init
│   ├── nginx-ingress-deployment  # nginx-ingress 部署文件
│   │   ├── ClusterRoleBinding.yaml
│   │   ├── RoleBinding.yaml
│   │   ├── clusterRole.yaml
│   │   ├── defaultBackendService.yaml
│   │   ├── defaultBackendServiceaccount.yaml
│   │   ├── deployment.yaml
│   │   ├── nginxDefaultBackendDeploy.yaml
│   │   ├── roles.yaml
│   │   ├── service.yaml
│   │   └── serviceAccount.yaml
│   └── nginx-ingress-helm   # nginx-ingress Helm 包
│       └── nginx-ingress-1.36.3.tgz
└── pipeline   # 继续部署流水线模板
    ├── gray-deploy.json  # 灰度公布流水线
    ├── gray-init.json    # 灰度公布初始化（首次运行）└── nginx-ingress-init.json  # nginx-ingress 初始化（首次运行）

灰度环境和生产环境次要由 deployment/canary/deploy.yaml 和 deployment/pro/deploy.yaml 来实现，次要是实现了两套环境的：

Deployment
Service
Ingress

A/B 测试和灰度由配置的 Ingress 进行管制：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx  # nginx=nginx-ingress| qcloud=CLB ingress
    nginx.ingress.kubernetes.io/canary: "true"  # 开启灰度
    nginx.ingress.kubernetes.io/canary-by-header: "location"  # A/B 测试用例 Header key
    nginx.ingress.kubernetes.io/canary-by-header-value: "shenzhen"  # A/B 测试用例 Header value
  name: my-ingress
  namespace: pro
spec:
  rules:
  - host: nginx-ingress.coding.pro
    http:
      paths:
      - backend:
          serviceName: nginx-canary
          servicePort: 80
        path: /

A/B 测试次要由注解 nginx.ingress.kubernetes.io/canary-by-header 和 nginx.ingress.kubernetes.io/canary-by-header-value 进行管制，来匹配申请 Header 的 Key 和 Value。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx  # nginx=nginx-ingress| qcloud=CLB ingress
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: 30
  name: my-ingress
  namespace: pro
spec:
  rules:
  - host: nginx-ingress.coding.pro
    http:
      paths:
      - backend:
          serviceName: nginx-canary
          servicePort: 80
        path: /

而灰度则由注解 nginx.ingress.kubernetes.io/canary-weight 管制，值范畴能够是 0-100，对应灰度权重比例。在 Nginx-ingress，负载平衡算法次要由 加权轮询 的算法来实现分流。

整体架构图如所示：

1、K8S 集群，举荐应用腾讯云容器服务；
2、开明 CODING DevOps，提供镜像构建和流水线的部署能力。

1、克隆源码并推送至本人的 CODING Git 仓库

$ git clone https://e.coding.net/wangweicoding/nginx-ingress-gray/nginx-ingress-gray.git
$ git remote set-url origin https://you coding git
$ git add .
$ git commit -a -m 'first commit'
$ git push -u origin master

留神，推送前请将 deployment/dev、deployment/canary、deployment/pro 文件夹的 deploy.yaml image 批改为本人的制品库镜像地址。

2、创立继续集成流水线
应用“自定义构建过程”创立构建打算，并抉择应用代码仓库的 Jenkinsfile

3、新增云账号并创立继续部署流水线，复制我的项目的 pipeline Json 模板到创立的流水线内（3 个）

为了便于应用模板，创立继续部署流水线利用名为：nginx-ingress

创立持续创立空白部署流程，复制 Json 模板到继续部署流水线中，一共创立三条流水线：

nginx-ingress-init – 用于初始化 nginx-ingress
gray-init – 用于首次初始化环境
gray-deploy – 用于演示灰度公布

留神：请将以上流水线的云账号抉择为本人的云账号，另外 gray-deploy 流水线中，请重新配置“启动所需制品”和“触发器”。

4、初始化 nginx-ingress（首次运行）
首次运行 nginx-ingress 流水线将主动为您部署nginx-ingress。部署胜利后，运行 kubectl get svc | grep nginx-ingress-controller 获取 Ningx-ingress 的 EXTERNAL-IP，此 IP 为集群申请入口 IP。并为本机配置 Host，便于拜访。

5、初始化灰度公布（首次运行）
首次运行 gray-init 流水线将主动部署一套残缺的环境，否则自动化灰度流水线将会失败。

6、主动触发灰度公布
当初，您能够尝试批改我的项目 docker/html/index.html 文件，推送后将主动触发构建和继续部署，触发后，进入“继续部署”页面，查看部署详情和流程。

咱们次要利用了 CODING 继续部署 的期待 阶段，通过对不同灰度比例的阶段设定等待时间，自动化逐个运行灰度阶段，最终实现无人工值守的自动化灰度公布。

利用 期待 阶段，能够实现平滑的公布流程，只有当公布呈现问题，才须要人工染指。配合继续部署告诉性能，能够很不便的将以后公布状态推送到企业微信、钉钉等合作工具。

为了不便展现，案例中对灰度比例和等待时间进行了硬编码，你也能够应用阶段的“自定义参数”来实现对灰度比例和期待实现进行动态控制，针对以后的公布等级动静输出灰度比例和流程管制，使得公布更加灵便。

本文的 Nginx-ingress 采纳 deployment 的部署形式来实现。Nginx-ingress 作为 Kubernetes 集群的边缘网关，承当着所有入口流量，其高可用性间接决定了 Kubernetes 集群的高可用性。

在生产环境，部署 Nginx-ingress 倡议遵循以下几点：

举荐应用 DaemonSet 的形式部署，防止节点故障。
通过标签选择器，将 Nginx-ingress-controller 部署在独立的 Node 节点（如高主频、高网络、高 IO 节点）或者低负载的节点。
如果采纳 Deployment 的形式部署，能够为 Nginx-ingress 配置 HPA 程度伸缩。

对于 CODING，理解更多

关于git:CODING-DevOps-Nginxingress-实现自动化灰度发布

前言

Nginx-ingress 架构和原理

实现计划预览

我的项目源码和原理剖析

环境筹备

实际步骤

总结

生产倡议