當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之間通常不進行直接的通信，全部內部應用之間的流量或者集羣外部的流量都須要經過一個單獨的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的能力。

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

 

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。