摘要：?對于熟悉Kubernetes的用戶來說，應(yīng)該知道當(dāng)你的應(yīng)用程序一旦部署到Kubernetes以后，Kubernetes能夠自動幫你管理應(yīng)用程序，當(dāng)Pod發(fā)生故障后可以自動調(diào)度重建，確保服務(wù)的持續(xù)可用。

對于熟悉Kubernetes的用戶來說，應(yīng)該知道當(dāng)你的應(yīng)用程序一旦部署到Kubernetes以后，Kubernetes能夠自動幫你管理應(yīng)用程序，當(dāng)Pod發(fā)生故障后可以自動調(diào)度重建，確保服務(wù)的持續(xù)可用。但Kubernetes的原生發(fā)布策略難以滿足生產(chǎn)級別的發(fā)布要求。 本文將介紹一種在阿里巴巴常用的應(yīng)用發(fā)布模式：分批發(fā)布，以及在云效是如何在Kubernetes是如何實現(xiàn)這種發(fā)布模式的。

Kubernetes的滾動升級

Kubernetes的RollingUpdate（滾動更新）是Kubernetes提供的原生服務(wù)升級策略。意圖通過該方式在不停止對外服務(wù)的前提下完成對應(yīng)用的更新。

在原生RollUpdate中用戶可以設(shè)置升級策略，如maxSurge和maxUnavailable控制Pod啟動策略以及最大不可用Pod數(shù)，來確?？梢訮od能夠在滾動升級中不出現(xiàn)沒有可用Pod的情況。

對于Kubernetes老手來說，肯定也會加上livenessProbe與readinessProbe探針，來確認(rèn)服務(wù)是否可用。

但是，理想總是豐滿，現(xiàn)實總是骨干。在現(xiàn)實的發(fā)布過程中，服務(wù)升級成功了鏡像也啟動成功了。 但是并不意味著你這次的“發(fā)布”完成了。

關(guān)注持續(xù)交付領(lǐng)域的朋友，可能會聽過各種發(fā)布策略，比如藍(lán)綠發(fā)布、灰度發(fā)布等等。 這些發(fā)布策略，尋根溯本，都是為了將部署與發(fā)布進(jìn)行分離，在服務(wù)真正上線之前能夠有人工介入的機會確保這次升級是是真正的滿足業(yè)務(wù)需求的。

阿里巴巴分批發(fā)布模式

分批發(fā)布是在阿里巴巴內(nèi)部大量使用的一種服務(wù)發(fā)布上線方式。分批發(fā)布簡單來說就是按照一定的批次，每次只對服務(wù)的一部分實例進(jìn)行升級。

分批發(fā)布一個很重要的動作就是暫停，在暫停后，用戶可以手動對新升級的實例進(jìn)行驗證，如果確認(rèn)一切無誤后，再繼續(xù)后批次服務(wù)實例的升級動作。

分批發(fā)布的重要的意義在于提供了人工或自動（無人值守發(fā)布）介入發(fā)布過程驗證的功能，以及一旦發(fā)現(xiàn)問題快速回滾的能力。

在Kubernetes上實現(xiàn)分批發(fā)布

在Kubernetes的應(yīng)用模型中，Pod和Pod之間一般不進(jìn)行直接的通訊，所有內(nèi)部應(yīng)用之間的流量或者集群外部的流量都需要通過一個單獨的Serviec對象。

在云效的部署模型中，我們將Service抽象為一個部署的目標(biāo)應(yīng)用。 在執(zhí)行分批發(fā)布過程中，我們會自動為當(dāng)前Service關(guān)聯(lián)的Deployment對象創(chuàng)建一個新版本的副本。用戶可以為整個分批發(fā)布過程中定義一個執(zhí)行批次。

如下所示，在分批發(fā)布過程中，云效通過控制當(dāng)前版本以及新版本Deployment對象的副本數(shù)，來控制不同版本Pod的實例數(shù)：

在第一批發(fā)布完成后，整個過程將會自動暫停。 此時，用戶可以直接到集群中對部署結(jié)果進(jìn)行驗證，在驗證無誤的情況下確認(rèn)是否繼續(xù)后續(xù)的發(fā)布過程，而如果用戶判斷發(fā)布存在異常，則可以直接對整個發(fā)布過程進(jìn)行回滾，應(yīng)用自動回滾到發(fā)布前狀態(tài)：

在整個分批發(fā)布過程中為了確保Service流量不會進(jìn)行到啟動中的Pod實例，結(jié)合使用LivenessProbe和ReadinessProbe可以確保整個發(fā)布過程中服務(wù)的持續(xù)可用。

使用Istio增強分批發(fā)布發(fā)布能力

在Kubernetes原生的Service負(fù)載均衡實現(xiàn)中，其通過iptable實現(xiàn)從ClusterIP到PodIP的流量路由，其中利用了iptables的--probability的特性來實現(xiàn)分流。

在上面的例子中，如果分批發(fā)布為2批，那么新版和舊版Pod會各有50%左右的流量進(jìn)入。在基于原生Kubernetes的分批發(fā)布策略中可以通過增加應(yīng)用的副本數(shù)（Replicas）來控制新版本和舊版本之間的流量比例。

而云效的分批發(fā)布策略對于已經(jīng)使用Istio的用戶，則可以輕松實現(xiàn)更精細(xì)化的流量控制規(guī)則。云效在發(fā)布過程中會自動為Deployment實例添加版本標(biāo)簽。

基于版本標(biāo)簽，Istio用戶可以通過RouteRule輕松控制不同版本之間的流量比例或者是基于Cookie直接實現(xiàn)AB Test的能力。

當(dāng)然，后續(xù)云效會直接將這部分能力集成到整個流水線過程中，讓整個過程變的更加順滑。

云效Kubernetes分批發(fā)布詳細(xì)教程：https://help.aliyun.com/document_detail/96666.html