摘要： 對於熟悉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的能力。

當然，後續雲效會直接將這部分能力整合到整個流水線過程中，讓整個過程變的更加順滑。