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

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

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

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

部署策略

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

滾動部署(Rolling Deployment)

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

在開始取代舊的pod之前，滾動更新需要通過就緒探測器(readiness probe，請參考)，來確認(rèn)新的pod是否已經(jīng)到位。如果存在問題的話，滾動式更新或部署就會被中斷掉，以免造成整個(gè)集群的停機(jī)。因此，我們可以參照如下的YAML定義文件，來按照滾動部署的方式，將一個(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 

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

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

重建(Recreate)

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

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

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

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

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

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

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

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

金絲雀(Canary)

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

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

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

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

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

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

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

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

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

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

暗部署與A/B部署

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

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

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

Flagger和A/B部署

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

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

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