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

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

Kubernetes的滾動(dòng)升級(jí)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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