如何在 Kubernetes 中对无状态应用进行分批发布

骑猪看日落 2022-02-22 05:59 253阅读 0赞

在 Kubernetes 中针对各种工作负载，提供了多种控制器，其中 Deployment 为官方推荐，被用于管理无状态应用的 API 对象。本文将结合 Deployment 的特性，与常见的发布策略，以及我们在分批发布场景下的实践，做一些分享。

## 使用 Deployment 的场景 ##

Deployment 在 Kubernetes 1.9 版本后被晋升为 GA 版本，基于 Spec 定义管理 Pod，无需关心每个实例的部署结构差异。

对于日常应用变更，可以满足如下典型场景：

•\\t应用变更，提供滚动升级策略，失败自动暂停。  
  
•\\t应用变更失败，回滚到之前版本。  
  
•\\t应用水平伸缩，支撑更高负载。  
  
•\\t历史资源回收，不需要手工回收 Pod 或 ReplicaSet 资源。

Deployment 提供了 RollingUpdate 滚动升级策略，升级过程中根据 Pod 状态，采用自动状态机的方式，通过下面两个配置，对新老 Pod 交替升级，控制升级速率。

•\\tMax Unavailable : 最大不可用实例数/比例。  
  
•\\tMax Surge : 调度过程中，可超过最大期望实例数的数/比例。

## Kubernetes 生态中常见变更策略 ##

基于 Deployment 的基础功能，结合 Service / Ingress / Istio 等流量控制组件，常见如下几种策略。具体对比分析与实现，可参考网上文章 ，这里不做过多展开：

1.  滚动 Rolling：渐进式创建新版本，然后停止老版本，自动完成整个流程。

![\\"\\"][172c844d05116c1ced0252e5cdee36d3.png]

1.  金丝雀 Canary：小部分流量，升级并导入新版本，手工验证完毕后，全量升级部署。

![\\"\\"][bfbef00a10d758285cc86aa45a3dd172.png]

1.  蓝绿 Blue/Green：创建出新版本，与老版本并存，通过切换流量实现发布与回滚。

![\\"\\"][8b06addeff2f23212d78906ae6739b0f.png]

1.  重建 Recreate：杀死所有老版本，再用新版本重建。适用于开发、测试环境重新初始化。
2.  A/B 测试：部署新版本，流量控制倒流，长期在线。严格来说，这是一种线上业务与商业化验证的模式，不是变更策略。

![\\"\\"][a02a24cf665118817bcd809a7abff2aa.png]

## 为何需要分批暂停 ##

在日常变更中，上述机制会让变更变得简单和便捷，但 Deployment 有如下限制：

•\\t需要手工回滚。  
  
•\\t无法暂停滚动升级过程。

那么客户发布过程中，经常会遇到哪些情况，导致发布失败呢？我们 在整理与分析客户失败的发布时发现，主要出现在下面阶段：

•\\t开始灰度发布：因配置错误、打包异常、代码 BUG，或灰度后功能验证中发现了问题。  
  
•\\t灰度验证成功，分批发布过程中：因网络白名单、资源不足、单机配置错误。  
  
•\\t发布上线后：客户反馈、监控报警。

不难看出，一次常见的发布，在不同发布阶段，需要一个手动的、可以更细粒度的控制，减少对线上的不良影响。所以滚动升级的分批暂停功能，对核心业务发布来说，是质量保障必不可少的一环。那有没有什么方法，即可使用 Deployment 的滚动升级机制，又可以在发布过程中，结合金丝雀发布，分阶段暂停发布流程呢？

### 阿里在K8s 中的分批发布实践：手动灰度+自动/手动分批发布 ###

在阿里巴巴内部，分批发布是最常见的发布手段，用于保障线上发布。结合“可灰度、可监控、可回滚”作为基本发布要求，发布阶段可以分为主要两个阶段：

•\\t灰度阶段：先灰度 1-2 台，线上验证流量正确性。该阶段出现问题后，影响面可控、可快速回滚。大部分应用变更过程中，可能会出现的问题，均会在此阶段被发现或暴露。  
  
•\\t自动/手动分批阶段：灰度成功后，一批批发布，为监控和报警，留足时间窗口，提前发现问题。

结合上述场景，我们采用管控 + 双 Deployment 方式实践了可暂停的分批发布。主要是基于如下两种发布策略的组合使用：

•\\tCanary + Batch Rolling 策略结合。  
  
•\\tCanary : 灰度发布 XX 台，发布后暂停。线上验证流量。  
  
•\\tBatch Rolling : 分批发布 XX 批，发布后自动/手动继续发布下一批。

针对具体发布策略，我们的考虑和做法是这样的：

•\\t创建新 Deployment : 新版本发布，作为灰度验证的部署实例，初始实例数为 0；  
  
•\\t进入灰度阶段：仅选取少量实例，扩容新版本 Deployment，缩容线上 Deployment；  
  
•\\t进入分批阶段：根据分批实例，自动变更新老 Deployment 实例；  
  
•\\t回滚阶段：反向做分批流程，将新版本实例数缩容到 0，老版本重新扩容到原有预期的实例数。

![\\"\\"][b4ce9cfd9e04aa4c783defb2366ef0b5.png]

若发布过程中出现异常状态，如何及时发现错误，设置滚动升级卡点，或做到自动回滚呢？现在考虑如下：

•\\t自动健康检查：结合应用 Liveness / Readiness 检查配置，根据 Kubernetes Pod 状态，若发布过程中有任何发布失败情况，均停止当前批次新老 Deployment 的滚动升级操作。  
  
•\\t终止发布回滚：认为任何的发布失败，不应该是等待排查问题再发一次，而是应该第一时间回滚代码，保障线上业务质量，然后再考虑第二次变更。所以当未完成本次分批发布时，终止变更，会自动回滚本次变更。

## 思考 ##

通过扩展滚动更新，提供手工分批能力后，还有更多可以保障发布的策略与发布。

•\\t对灰度发布，结合流量控制规则，进行线上灰度验证。  
  
•\\t结合更多监控指标，与线上服务情况，确定指标基线，作为发布卡点，让分批发布更自动化。

--------------------

作者简介

孙齐（花名：代序），阿里巴巴高级工程师，负责企业级分布式应用服务 EDAS 及 EDAS Serveless的开发和维护工作。

[172c844d05116c1ced0252e5cdee36d3.png]: /images/20220222/2f19ed1d2f3c4aee94d5beb365de9de9.png
[bfbef00a10d758285cc86aa45a3dd172.png]: /images/20220222/20192770a0e44e9aa18164e59fc904a2.png
[8b06addeff2f23212d78906ae6739b0f.png]: /images/20220222/a3ce659775e54c5fa640377a55c79c24.png
[a02a24cf665118817bcd809a7abff2aa.png]: /images/20220222/4c83e57d65f34c788c636cd0c2f8fc22.png
[b4ce9cfd9e04aa4c783defb2366ef0b5.png]: /images/20220222/ebed321e12674c50b497555cbc5f5e77.png