對於熟悉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

當Kubernetes應用遇到阿裏分批發布模式