CODING CD + Nginx Ingress 实现蓝绿发布

本文作者：杨浩佳 - CODING 后端开发工程师
全文约 4000+ 字，预计阅读时间 20 分钟

前言

本文将介绍如何通过 CODING CD 使用 Nginx Ingress 来实现蓝绿发布。

为什么要采用蓝绿发布？随着业务的快速发展，对开发团队的要求越来越高，一方面要求为用户提供稳定的服务，一方面要求进行快速业务迭代。因此基于系统稳定性和快速业务迭代的综合考虑，需要采用蓝绿发布上线新版本服务的方式，实现应用服务的平稳升级。

为什么要使用 CODING CD？传统的部署是修改 YAML 文件的镜像版本，然后通过命令行 kubectl apply 的方式更新应用服务的版本，这种发布方式过于依赖人工执行，对于 DevOps 团队来说是不可忍受的。而通过 CODING CD 部署流程实现自动化流水线，流水线的所有阶段都可以供团队中的任何人检查、改进和验证，开发团队可以提高发布的速度和降低发布的风险和成本。

概述

什么是 Nginx Ingress

Nginx Ingress 是 Kubernetes Ingress 的一种实现，它通过 watch Kubernetes 集群的 Ingress 资源，将 Ingress 规则转换成 Nginx 的配置，然后让 Nginx 来进行 7 层的流量转发。

使用注解说明

我们通过给 Ingress 资源指定 Nginx Ingress 所支持的一些 annotation 可以实现蓝绿发布，需要给服务创建两个 Ingress，一个正常的 Ingress（myapp-ingress），另一个是带 nginx.ingress.kubernetes.io/canary: "true" 这个固定的 annotation 的 Ingress，我们姑且称它为 Canary Ingress（myapp-blue-ingress），一般代表新版本的服务，结合另外针对流量切分策略的 annotation 一起配置即可实现多种场景的蓝绿发布，以下是对本次实践使用到的 annotation 的介绍：

• nginx.ingress.kubernetes.io/canary-by-header: 表示如果请求头中包含这里指定的 header 名称，并且值为 always 的话，就将该请求转发给该 Ingress 定义的对应后端服务；如果值为 never 就不转发，可以用于回滚到旧版；如果是其它值则忽略该 annotation。

• nginx.ingress.kubernetes.io/canary-by-header-value: 这个可以作为 canary-by-header的补充，允许指定请求头的值可以自定义成其它值，不再只能是 always 或 never；当请求头的值命中这里的自定义值时，请求将会转发给该 Ingress 定义的对应后端服务，如果是其它值则将会忽略该 annotation。

• nginx.ingress.kubernetes.io/canary-weight: 表示 Canary Ingress 所分配流量的比例的百分比，取值范围 [0-100]，比如设置为 10，意思是分配 10% 的流量给 Canary Ingress 对应的后端服务。

更多关于 Nginx Ingress 的注解说明可以参考官方文档。

什么是蓝绿发布

蓝绿发布，是在生产环境稳定集群之外，额外部署一个与稳定集群规模相同的新集群，并通过流量控制，逐步引入流量至新集群直至 100%，原先稳定集群将与新集群同时保持在线一段时间，期间发生任何异常，可立刻将所有流量切回至原稳定集群，实现快速回滚。直到全部验证成功后，下线老的稳定集群，新集群成为新的稳定集群。

发布流程

蓝绿发布的流程，包括：蓝绿发布开始、蓝绿初始化、蓝绿验证、蓝绿取消或完成上线。

如上图所示，老集群集群的版本为 v1，该集群通过 version=v1 标签被 Service myapp-svc 访问到。

• 额外部署了一个新集群，版本为 v2，该集群通过 version=v2 标签被 Service myapp-blue-svc 访问到。

• 通过流量控制，控制部分流量或全部流量到新集群，进行蓝绿验证，同时原稳定集群继续保持在线。

• 如果验证没有发现任何故障，则应用 myapp 的蓝绿发布完成，v2 版本集群成为新的稳定集群。

• 如果在验证中发现了故障，则通过流量控制，将全部流量切回原来稳定的老集群，实现快速回滚。

实践

前提条件：

Kubernetes 集群中需要部署 Nginx Ingress 作为 Ingress Controller，并且对外暴露了统一的流量入口。

老集群初始化

发布流程

配置

这里配置部署 myapp 应用服务所需要的 docker 镜像制品，还有启动参数 version，该参数的作用主要是作为标签为 Service 提供筛选过滤条件，实现新老版本服务的流量控制。

发布策略

发布策略采用人工确认阶段，可配置确认人，选择不同发布方式。

常规发布

常规发布采用预置条件检查阶段，预置条件配置 #judgment("发布策略") == '常规发布' 表达式，表达式中的 judgment 函数返回人工确认阶段选定的选项，并通过 == 关系运算符来比较表达式中的值，如果表达式判断成功，将执行这个分支的阶段。

新集群(即绿集群)部署

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    strategy.spinnaker.io/max-version-history: '3'   # 表示保留 3 个历史版本的 myapp-deploy
    strategy.spinnaker.io/versioned: 'true'   # 表示 Spinnaker 对 myapp-deploy 进行版本管理
  name: myapp-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: '${
   parameters.version}'   # 引用配置中的启动参数 version
  template:
    metadata:
      labels:
        app: myapp
        version: '${parameters.version}'
    spec:
      containers:
        - image: selinaxeon-docker.pkg.coding.net/coding-yhj/docker/myapp
          name: myapp
          ports