云原生时代的灰度发布有几种“姿势”？

作者：嘉为蓝鲸

2022-12-21
广东
本文字数：2491 字
阅读完需：约 8 分钟

随着企业数字化转型进程不断发展，云原生时代的来临，企业应用越来越多，不得不面对应用程序升级的巨大挑战。传统的停机发布方式，新旧版本应用切换少则停机 30 分钟，多则停机 10 小时以上，愈发无法满足业务端的需求。

“业务无感知”的发布策略成为应用运维团队的不二选择，尽可能降低发布对业务的影响。“业务无感知”的发布策略有滚动发布、蓝绿发布、灰度发布。

本文将从什么是灰度发布，发布类型，灰度发布自动化实践三个维度来展开。

01 灰度发布的概念

灰度发布，又名金丝雀发布，即在产品发布时，先让一小部分用户体验产品新版本的特性，这一小部分用户的用户范围可以是内部用户、测试用户和非核心用户，但主要用户还是继续使用产品旧版本。

新版本发布完成之后，验证业务及用户反馈是否正常，一切正常之后再逐步扩大新版本覆盖范围：20%、50%、70%，每发布一次就进行业务验证、观察用户反馈。最后用新版本覆盖所有用户，完成一次灰度发布。

灰度发布的最大优势是将新版本使用范围控制在小范围内，如果新版本出现问题，能够极大降低问题影响范围，避免影响所有用户，造成严重的生产故障，引发大范围的投诉，从而影响到公司业务和品牌。

02 发布类型

1、滚动发布

滚动发布，是指一个应用有多个主机副本，将其分成多个批次。首先升级第一个批次，之后依次升级其他批次，直到所有批次升级完成。每个批次升级前，需要在 LB 中移除对应主机的流量转发，升级完成后，再恢复对应主机的流量转发。

将应用分成多个批次，升级前后的 LB 操作工作量比较大，对应用运维人员来说操作麻烦，手工操作出错的概率较大，嘉为蓝鲸应用发布中心，通过自动化流程实现应用的滚动发布。

同时，嘉为蓝鲸应用发布中心支持随机分批和自定义分批两种方式的滚动发布。选择分批方式后，在批次内可以选择串行和并行的执行方式

2、蓝绿发布

蓝绿发布，是指应用分为两个版本，发布时将旧版本所有流量直接切换到新版本上。新版本部署时，按照旧版本的规格完全独立部署一套，部署完成之后，进行简单测试验证，正常之后将旧版本的流量直接导到新版本上。

3、灰度发布

灰度发布，是指应用分为两个版本，发布时将旧版本的流量，分阶段 10%、30%、80%、100%切换到新版本上。每阶段切换后，任务需要暂停，应用运维人员可以检查程序是否正常，监控日志是否正常，同步业务方检查业务指标是否正常。确认一切正常之后，执行下一部分发布动作。

03 灰度发布自动化实践

场景一：基于 F5 设备进行蓝绿发布的场景

用户通过 F5 设备控制业务流量，将业务流量转发到后端真实应用服务上。为了保证升级时用户能够正常访问，需要进行蓝绿发布。

在进行蓝绿发布时，分成三个发布步骤：

先部署新版本应用，此时新版本应用没有业务流量；
然后执行 F5 命令进行流量切换，用户访问流量切到新版本应用服务上；
最后进行业务逻辑验证，查看业务流量确认业务正常，则蓝绿发布完成，如果业务异常，快速执行回滚任务，进行流量回切。

通过标准运维自动化执行切换 F5 流量的命名，如下：

开启 F5 member：

curl -sk -u user:pwd -H "Content-Type: application/json" -X PUT -d '{"enabled":true}' https://${F5_IP}/mgmt/tm/gtm/pool/a/~Common~pool_api_test/members/~Common~server_${F5_IP}:~Common~vs_api_test_1?ver={app_host_ip}

关闭 F5 member：

curl -sk -u user:pwd -H "Content-Type: application/json" -X PUT -d '{"disabled":true}' https://{F5_IP}/mgmt/tm/gtm/pool/a/~Common~pool_api_test/members/~Common~server_{F5_IP}:~Common~vs_api_test_1?ver={app_host_ip}

备注：{F5_IP}：为 F5 设备 IP，{app_host_ip}：为 F5 后端的服务主机 IP

关键参数通过变量传入，该标准运维流程可以被多个业务系统复用，无需每个业务系统单独编排。

场景二：基于 Nginx 进行灰度发布的场景

用户通过 Nginx 代理或者负载均衡设备来控制业务流量的转发，为了提高应用升级的稳定性，升级后先让部分用户体验新版本，通过标准运维脚本命令切换 Nginx 中流量转发策略，将小部分随机用户流量转发到新版本服务上。

确认新版本功能正常后，逐步扩大新版本覆盖的用户范围。避免在蓝绿发布中，新版本异常会影响到所有用户访问的问题。

大部分用户访问业务正常，验证了新版本的稳定性，再让新版本覆盖所有用户，完成基于 Nginx 的灰度发布。

具体标准运维任务参考：

场景三：容器应用灰度发布的场景

容器应用在升级时，为了保证业务无感知，应用运维人员也需要考虑灰度发布方案，将一次完成的发布流程，拆分成多个发布流程，降低每一次应用发布的影响范围。

容器发布场景，应用一般通过 ingress-nginx 或者 istio 控制流量分发，每次发布更新 ingress 中的权重参数，实现不同流量比例的切换。

在这个场景中，先部署新应用的 deploy 和 service，然后部署 ingress，切 20%流量到新应用，此时发布任务暂停，业务人员进行应用检查和验证。验证业务正常之后，再切换 40%、70%、100%应用到新应用上，完成容器应用场景的灰度发布。

场景四：容器应用多地域灰度发布的场景

业务应用在全国多个省市都有部署，在进行升级时，分地域进行灰度升级。

先升级华东地域应用，华东地域内串行发布，确保业务能够正常稳定发布成功；然后依次升级华中地域、华南地域、华北地域、西南地域、港澳台地域，地域内并行发布执行。

场景五：K8s 集群版本灰度升级的场景

K8s 不支持跨大版本进行升级，如果考虑一个个小版本的升级会非常麻烦，每次小版本升级对应用运维人员来说都是非常大的挑战。因此一个自动化、业务无感知的 K8s 集群版本灰度升级是非常关键的。

业务端通过 APISIX 或者 Istio 控制业务流量。首先自动化部署 v1.24 版本的 K8s 集群，然后在 v1.24 版本集群中部署容器应用，通过 APISIX 灰度迁移少部分业务流量，验证业务的可用性和稳定性，慢慢将所有应用灰度迁移到新版本集群。所有应用迁移完成后，将 v1.16 版本 K8s 集群下线资源回收。