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

摘要： 对于熟悉Kubernetes的用户来讲，应该知道当你的应用程序一旦部署到Kubernetes之后，Kubernetes可以自动帮你管理应用程序，当Pod发生故障后能够自动调度重建，确保服务的持续可用。

对于熟悉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的能力。

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

云效Kubernetes分批发布详细教程：https://help.aliyun.com/document_detail/96666.html

原文连接