【51CTO.com快譯】眾所周知，我們?cè)陂_(kāi)發(fā)云原生應(yīng)用的過(guò)程中，往往比拼的是如何加快單位時(shí)間內(nèi)，應(yīng)用部署的數(shù)量與質(zhì)量。而通過(guò)使用微服務(wù)的方法，開(kāi)發(fā)人員能夠快速設(shè)計(jì)出完全模塊化的應(yīng)用程序，從而讓更多的團(tuán)隊(duì)成員得以同時(shí)向單個(gè)應(yīng)用程序?qū)懭氩⒉渴鸶鞣N變更與發(fā)布?？梢?jiàn)，用時(shí)更短、更頻繁的部署能夠給企業(yè)帶來(lái)以下方面的好處：

• 縮短了上市(time-to-market)的時(shí)間。
• 客戶(hù)能夠更快地使用到新的特性。
• 客戶(hù)的各種反饋能夠更快地到達(dá)產(chǎn)品團(tuán)隊(duì)，同時(shí)產(chǎn)品團(tuán)隊(duì)也能更快地通過(guò)迭代來(lái)解決現(xiàn)有的問(wèn)題。
• 通過(guò)向生產(chǎn)環(huán)境成功發(fā)布更多的新特性，來(lái)鼓舞開(kāi)發(fā)人員的士氣。

當(dāng)然更頻繁的發(fā)布，也會(huì)對(duì)應(yīng)用的可靠性、以及客戶(hù)的體驗(yàn)滿(mǎn)意度增添一些負(fù)面的影響。這就是為什么運(yùn)營(yíng)和DevOps團(tuán)隊(duì)需要共同開(kāi)發(fā)出各種流程、并管理不同的部署策略，從而最小化產(chǎn)品和客戶(hù)可能面對(duì)的風(fēng)險(xiǎn)。(更多關(guān)于CI/CD管道自動(dòng)化的信息，請(qǐng)參見(jiàn))

在本文中，我們將討論Kubernetes的不同部署策略，其中包括滾動(dòng)部署、重建、藍(lán)綠、金絲雀、及其變種等高級(jí)方法。

部署策略

根據(jù)目標(biāo)的不同，我們可以對(duì)Kubernetes采取不同的部署策略。例如：您可能需要針對(duì)某個(gè)特定環(huán)境、或是用戶(hù)與客戶(hù)子集進(jìn)行變更，進(jìn)而推出更多的測(cè)試版本;或許您想在推出某個(gè)通用功能之前，先對(duì)一部分用戶(hù)開(kāi)展測(cè)試。

滾動(dòng)部署(Rolling Deployment)

滾動(dòng)部署是對(duì)Kubernetes的一種標(biāo)準(zhǔn)化、且默認(rèn)的部署方式。它雖然運(yùn)行較為緩慢，但是能夠一個(gè)接一個(gè)地用新版本的pod替換應(yīng)用程序中舊版本的pod，而且不會(huì)產(chǎn)生任何集群的停機(jī)時(shí)間。

在開(kāi)始取代舊的pod之前，滾動(dòng)更新需要通過(guò)就緒探測(cè)器(readiness probe，請(qǐng)參考)，來(lái)確認(rèn)新的pod是否已經(jīng)到位。如果存在問(wèn)題的話(huà)，滾動(dòng)式更新或部署就會(huì)被中斷掉，以免造成整個(gè)集群的停機(jī)。因此，我們可以參照如下的YAML定義文件，來(lái)按照滾動(dòng)部署的方式，將一個(gè)舊的鏡像替換為新的。 

apiVersion: apps/v1beta1 
kind: Deployment 
metadata: 
  name: awesomeapp 
spec: 
  replicas: 3 
  template: 
        metadata: 
           labels: 
             app: awesomeapp 
        spec: 
          containers: 
            - name: awesomeapp 
              image: imagerepo-user/awesomeapp:new 
              ports: 
                - containerPort: 8080 

如下所示，通過(guò)調(diào)整清單(manifest)文件中的各項(xiàng)參數(shù)，我們可以對(duì)滾動(dòng)更新進(jìn)行進(jìn)一步的細(xì)化： 

spec: 
  replicas: 3 
  strategy: 
        type: RollingUpdate 
        rollingUpdate: 
           maxSurge: 25% 
           maxUnavailable: 25%   
  template: 
  ... 

重建(Recreate)

這是一種非常簡(jiǎn)單的部署方式，如下圖所示，它直接“殺”掉所有舊的pod，并立即替換為新的pod。

其對(duì)應(yīng)的標(biāo)準(zhǔn)清單文件，如下所示： 

spec: 
  replicas: 3 
  strategy: 
        type: Recreate 
  template: 
  ... 

藍(lán)/綠或紅/黑部署(Blue/Green or Red/Black)

在藍(lán)/綠(有時(shí)也被稱(chēng)為紅/黑)部署策略中，舊版本的應(yīng)用程序(簡(jiǎn)稱(chēng)為綠)和其對(duì)應(yīng)的新版本(藍(lán))同時(shí)被部署到生產(chǎn)環(huán)境中。如下圖所示，對(duì)于一般用戶(hù)而言，他們只能訪(fǎng)問(wèn)到綠版本;而QA團(tuán)隊(duì)則可以通過(guò)單獨(dú)的服務(wù)、或直接的端口轉(zhuǎn)發(fā)，來(lái)對(duì)藍(lán)版本進(jìn)行自動(dòng)化的測(cè)試。

apiVersion: apps/v1beta1 
kind: Deployment 
metadata: 
  name: awesomeapp-02 
spec: 
  template: 
        metadata: 
           labels: 
             app: awesomeapp 
             version: "02" 

因此，直到新的版本已經(jīng)完全通過(guò)了測(cè)試、并得到了簽發(fā)確認(rèn)之后，面對(duì)用戶(hù)的服務(wù)才被切換到藍(lán)版本之上，而舊的綠版本也才最終“退役”： 

apiVersion: v1 
kind: Service 
metadata: 
  name: awesomeapp 
spec: 
  selector: 
    app: awesomeapp 
    version: "02" 
... 

金絲雀(Canary)

金絲雀部署有點(diǎn)類(lèi)似于藍(lán)/綠部署，但是它更加受控，因此其使用范圍也更加廣泛。金絲雀部署類(lèi)型的主要特點(diǎn)是采用了分段式遞進(jìn)交付模式(progressive delivery，請(qǐng)參見(jiàn))。目前，包括：暗發(fā)布(dark launches)和A/B測(cè)試在內(nèi)的許多策略都屬于此類(lèi)。

當(dāng)您想測(cè)試一些新的特性時(shí)，通?？梢詫?duì)自己的應(yīng)用后端采用該金絲雀的部署方式。在此，您可以準(zhǔn)備兩套幾乎相同的服務(wù)器：延用原有功能的那一套，面向所有用戶(hù);而部署了新功能的另一套，則僅向一小部分用戶(hù)開(kāi)放。通過(guò)運(yùn)行效果的比較，當(dāng)不再出現(xiàn)任何報(bào)告錯(cuò)誤時(shí)，新版本就可以被逐步“滾動(dòng)”到生產(chǎn)系統(tǒng)架構(gòu)的其余部分之中。

雖然此類(lèi)策略可以通過(guò)使用Kubernetes的相關(guān)資源，來(lái)實(shí)現(xiàn)新舊Pod的替換，但是人們通常會(huì)使用Istio之類(lèi)的服務(wù)網(wǎng)(service mesh)，來(lái)更為方便輕松地予以實(shí)現(xiàn)。

如下例所示，您可以將兩種不同的清單放入Git，將其中的一個(gè)GA(GitApp)標(biāo)記為0.1.0，而將另一個(gè)金絲雀版本標(biāo)記為0.2.0。在Istio虛擬網(wǎng)關(guān)的清單文件中，我們通過(guò)修改不同的權(quán)重，來(lái)管理針對(duì)這兩種部署的流量百分比配額。

有關(guān)如何使用Istio來(lái)實(shí)現(xiàn)金絲雀的分步部署，請(qǐng)參見(jiàn)《在GitOps工作流中使用Istio》教程。

用Weaveworks Flagger進(jìn)行金絲雀部署

另一個(gè)簡(jiǎn)單有效地管理金絲雀部署的方法是使用Weaveworks Flagger(請(qǐng)參見(jiàn))

Flagger能夠促進(jìn)金絲雀部署的自動(dòng)化。它使用Istio或APP Mesh來(lái)路由和轉(zhuǎn)移流量，并且用到了Prometheus metrics的金絲雀分析。另外，金絲雀分析也可以針對(duì)各種驗(yàn)收測(cè)試、負(fù)載測(cè)試、以及其他類(lèi)型的自定義驗(yàn)證，進(jìn)行WebHook的擴(kuò)展。

Flagger采用了Kubernetes部署，并選用HPA(horizontal pod autoscaler)來(lái)創(chuàng)建一系列對(duì)象(包括：Kubernetes部署、ClusterIP服務(wù)、Istio與APP Mesh虛擬服務(wù))，進(jìn)而驅(qū)動(dòng)金絲雀式的分析與推送。

通過(guò)實(shí)施控制環(huán)路，F(xiàn)lagger會(huì)持續(xù)觀測(cè)諸如HTTP請(qǐng)求成功率、請(qǐng)求平均時(shí)長(zhǎng)、以及Pod健康性等關(guān)鍵性能指標(biāo)，并逐步將流量轉(zhuǎn)移到金絲雀的服務(wù)中。同時(shí)，我們可以通過(guò)對(duì)KPI的分析，來(lái)獲悉金絲雀服務(wù)水平的提升與下降，進(jìn)而將分析結(jié)果發(fā)布到Slack上。有關(guān)此方面的詳述與范例，請(qǐng)參見(jiàn)《APP Mesh的遞進(jìn)式交付》。

暗部署與A/B部署

暗部署是金絲雀的另一個(gè)變種。它和金絲雀之間的區(qū)別在于：暗部署多被用于處理前端，而金絲雀常被用到后端。

暗部署的另一個(gè)名稱(chēng)叫A/B測(cè)試。為了測(cè)試某種新的功能，我們可能需要在用戶(hù)不知情的前提下選取一小部分用戶(hù)，予以部署和推送，這就是所謂的“暗”部署。

通過(guò)使用特征切換和其他類(lèi)型的工具，您可以獲悉用戶(hù)是如何與新特性進(jìn)行交互的。籍此，您可以判斷是否要將該特性正式推送給用戶(hù)，發(fā)現(xiàn)新的UI是否出現(xiàn)了混亂狀況，以及其他類(lèi)型的參數(shù)指標(biāo)。

Flagger和A/B部署

其實(shí)除了加權(quán)路由，F(xiàn)lagger還能夠在基于HTTP的各種匹配條件下，將訪(fǎng)問(wèn)流量路由到金絲雀服務(wù)之中。例如，在A/B測(cè)試場(chǎng)景中，您可以使用各種HTTP頭或Cookie，來(lái)針對(duì)某一部分的用戶(hù)進(jìn)行路由轉(zhuǎn)發(fā)。顯然，這對(duì)于那些需要進(jìn)行會(huì)話(huà)關(guān)聯(lián)的前端應(yīng)用來(lái)說(shuō)，是特別實(shí)用的。當(dāng)然具體內(nèi)容，您可以去參考Flagger的相關(guān)文檔。

原文標(biāo)題：Kubernetes Deployment Strategies，作者：Anita Buehrle

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】