当Kubernetes应用遇到阿里分批发布模式

对于熟悉Kubernetes的用户来说，应该知道当你的应用程序一旦部署到Kubernetes以后，Kubernetes能够自动帮你管理应用程序，当Pod发生故障后可以自动调度重建，确保服务的持续可用。但Kubernetes的原生发布策略难以满足生产级别的发布要求。 本文将介绍一种在阿里巴巴常用的应用发布模式：分批发布，以及在云效是如何在Kubernetes是如何实现这种发布模式的。

Kubernetes的滚动升级

Kubernetes的RollingUpdate（滚动更新）是Kubernetes提供的原生服务升级策略。意图通过该方式在不停止对外服务的前提下完成对应用的更新。

在原生RollUpdate中用户可以设置升级策略，如maxSurge和maxUnavailable控制Pod启动策略以及最大不可用Pod数，来确保可以Pod能够在滚动升级中不出现没有可用Pod的情况。

对于Kubernetes老手来说，肯定也会加上livenessProbe与readinessProbe探针，来确认服务是否可用。

但是，理想总是丰满，现实总是骨干。在现实的发布过程中，服务升级成功了镜像也启动成功了。 但是并不意味着你这次的“发布”完成了。

关注持续交付领域的朋友，可能会听过各种发布策略，比如蓝绿发布、灰度发布等等。 这些发布策略，寻根溯本，都是为了将部署与发布进行分离，在服务真正上线之前能够有人工介入的机会确保这次升级是是真正的满足业务需求的。

阿里巴巴分批发布模式

分批发布是在阿里巴巴内部大量使用的一种服务发布上线方式。分批发布简单来说就是按照一定的批次，每次只对服务的一部分实例进行升级。

分批发布一个很重要的动作就是暂停，在暂停后，用户可以手动对新升级的实例进行验证，如果确认一切无误后，再继续后批次服务实例的升级动作。

分批发布的重要的意义在于提供了人工或自动（无人值守发布）介入发布过程验证的功能，以及一旦发现问题快速回滚的能力。

在Kubernetes上实现分批发布

在Kubernetes的应用模型中，Pod和Pod之间一般不进行直接的通讯，所有内部应用之间的流量或者