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

Kubernetes的滚动升级

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

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

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

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

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

阿里巴巴分批发布模式

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

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

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

在Kubernetes上实现分批发布

在Kubernetes的应用模型中，Pod和Pod之间一般不进行直接的通讯，所有内部应用之间的流量或者集群外部的流量都需要通过一个单独的Serviec对象。

在云效的部署模型中，我们将Service抽象为一个部署的目标应用。 在执行分批发布过程中，我们会自动为当前Service关联的Deployment对象创建一个新版本的副本。用户可以为整个分批发布过程中定义一个执行批次。

如下所示，在分批发布过程中，云效通过控制当前版本以及新版本Deployment对象的副本数，来控制不同版本Pod的实例数：

在第一批发布完成后，整个过程将会自动暂停。 此时，用户可以直接到集群中对部署结果进行验证，在验证无误的情况下确认是否继续后续的发布过程，而如果用户判断发布存在异常，则可以直接对整个发布过程进行回滚，应用自动回滚到发布前状态：

在整个分批发布过程中为了确保Service流量不会进行到启动中的Pod实例，结合使用LivenessProbe和ReadinessProbe可以确保整个发布过程中服务的持续可用。

使用Istio增强分批发布发布能力

在Kubernetes原生的Service负载均衡实现中，其通过iptable实现从ClusterIP到PodIP的流量路由，其中利用了iptables的--probability的特性来实现分流。

在上面的例子中，如果分批发布为2批，那么新版和旧版Pod会各有50%左右的流量进入。在基于原生Kubernetes的分批发布策略中可以通过增加应用的副本数（Replicas）来控制新版本和旧版本之间的流量比例。

而云效的分批发布策略对于已经使用Istio的用户，则可以轻松实现更精细化的流量控制规则。云效在发布过程中会自动为Deployment实例添加版本标签。

基于版本标签，Istio用户可以通过RouteRule轻松控制不同版本之间的流量比例或者是基于Cookie直接实现AB Test的能力。

当然，后续云效会直接将这部分能力集成到整个流水线过程中，让整个过程变的更加顺滑。

 

原文链接
本文为云栖社区原创内容，未经允许不得转载。