探討Kubernetes的不同部署策略
譯文【51CTO.com快譯】眾所周知，我們在開發云原生應用的過程中，往往比拼的是如何加快單位時間內，應用部署的數量與質量。而通過使用微服務的方法，開發人員能夠快速設計出完全模塊化的應用程序，從而讓更多的團隊成員得以同時向單個應用程序寫入并部署各種變更與發布。可見，用時更短、更頻繁的部署能夠給企業帶來以下方面的好處：
- 縮短了上市(time-to-market)的時間。
- 客戶能夠更快地使用到新的特性。
- 客戶的各種反饋能夠更快地到達產品團隊，同時產品團隊也能更快地通過迭代來解決現有的問題。
- 通過向生產環境成功發布更多的新特性，來鼓舞開發人員的士氣。
當然更頻繁的發布，也會對應用的可靠性、以及客戶的體驗滿意度增添一些負面的影響。這就是為什么運營和DevOps團隊需要共同開發出各種流程、并管理不同的部署策略，從而最小化產品和客戶可能面對的風險。(更多關于CI/CD管道自動化的信息，請參見)
在本文中，我們將討論Kubernetes的不同部署策略，其中包括滾動部署、重建、藍綠、金絲雀、及其變種等高級方法。
部署策略
根據目標的不同，我們可以對Kubernetes采取不同的部署策略。例如：您可能需要針對某個特定環境、或是用戶與客戶子集進行變更，進而推出更多的測試版本;或許您想在推出某個通用功能之前，先對一部分用戶開展測試。
滾動部署(Rolling Deployment)
滾動部署是對Kubernetes的一種標準化、且默認的部署方式。它雖然運行較為緩慢，但是能夠一個接一個地用新版本的pod替換應用程序中舊版本的pod，而且不會產生任何集群的停機時間。
在開始取代舊的pod之前，滾動更新需要通過就緒探測器(readiness probe，請參考)，來確認新的pod是否已經到位。如果存在問題的話，滾動式更新或部署就會被中斷掉，以免造成整個集群的停機。因此，我們可以參照如下的YAML定義文件，來按照滾動部署的方式，將一個舊的鏡像替換為新的。
- 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
如下所示，通過調整清單(manifest)文件中的各項參數，我們可以對滾動更新進行進一步的細化：
- spec:
- replicas: 3
- strategy:
- type: RollingUpdate
- rollingUpdate:
- maxSurge: 25%
- maxUnavailable: 25%
- template:
- ...
重建(Recreate)
這是一種非常簡單的部署方式，如下圖所示，它直接“殺”掉所有舊的pod，并立即替換為新的pod。
其對應的標準清單文件，如下所示：
- spec:
- replicas: 3
- strategy:
- type: Recreate
- template:
- ...
藍/綠或紅/黑部署(Blue/Green or Red/Black)
在藍/綠(有時也被稱為紅/黑)部署策略中，舊版本的應用程序(簡稱為綠)和其對應的新版本(藍)同時被部署到生產環境中。如下圖所示，對于一般用戶而言，他們只能訪問到綠版本;而QA團隊則可以通過單獨的服務、或直接的端口轉發，來對藍版本進行自動化的測試。
- apiVersion: apps/v1beta1
- kind: Deployment
- metadata:
- name: awesomeapp-02
- spec:
- template:
- metadata:
- labels:
- app: awesomeapp
- version: "02"
因此，直到新的版本已經完全通過了測試、并得到了簽發確認之后，面對用戶的服務才被切換到藍版本之上，而舊的綠版本也才最終“退役”：
- apiVersion: v1
- kind: Service
- metadata:
- name: awesomeapp
- spec:
- selector:
- app: awesomeapp
- version: "02"
- ...
金絲雀(Canary)
金絲雀部署有點類似于藍/綠部署，但是它更加受控，因此其使用范圍也更加廣泛。金絲雀部署類型的主要特點是采用了分段式遞進交付模式(progressive delivery，請參見)。目前，包括：暗發布(dark launches)和A/B測試在內的許多策略都屬于此類。
當您想測試一些新的特性時，通常可以對自己的應用后端采用該金絲雀的部署方式。在此，您可以準備兩套幾乎相同的服務器：延用原有功能的那一套，面向所有用戶;而部署了新功能的另一套，則僅向一小部分用戶開放。通過運行效果的比較，當不再出現任何報告錯誤時，新版本就可以被逐步“滾動”到生產系統架構的其余部分之中。
雖然此類策略可以通過使用Kubernetes的相關資源，來實現新舊Pod的替換，但是人們通常會使用Istio之類的服務網(service mesh)，來更為方便輕松地予以實現。
如下例所示，您可以將兩種不同的清單放入Git，將其中的一個GA(GitApp)標記為0.1.0，而將另一個金絲雀版本標記為0.2.0。在Istio虛擬網關的清單文件中，我們通過修改不同的權重，來管理針對這兩種部署的流量百分比配額。
有關如何使用Istio來實現金絲雀的分步部署，請參見《在GitOps工作流中使用Istio》教程。
用Weaveworks Flagger進行金絲雀部署
另一個簡單有效地管理金絲雀部署的方法是使用Weaveworks Flagger(請參見)
Flagger能夠促進金絲雀部署的自動化。它使用Istio或APP Mesh來路由和轉移流量，并且用到了Prometheus metrics的金絲雀分析。另外，金絲雀分析也可以針對各種驗收測試、負載測試、以及其他類型的自定義驗證，進行WebHook的擴展。
Flagger采用了Kubernetes部署，并選用HPA(horizontal pod autoscaler)來創建一系列對象(包括：Kubernetes部署、ClusterIP服務、Istio與APP Mesh虛擬服務)，進而驅動金絲雀式的分析與推送。
通過實施控制環路，Flagger會持續觀測諸如HTTP請求成功率、請求平均時長、以及Pod健康性等關鍵性能指標，并逐步將流量轉移到金絲雀的服務中。同時，我們可以通過對KPI的分析，來獲悉金絲雀服務水平的提升與下降，進而將分析結果發布到Slack上。有關此方面的詳述與范例，請參見《APP Mesh的遞進式交付》。
暗部署與A/B部署
暗部署是金絲雀的另一個變種。它和金絲雀之間的區別在于：暗部署多被用于處理前端，而金絲雀常被用到后端。
暗部署的另一個名稱叫A/B測試。為了測試某種新的功能，我們可能需要在用戶不知情的前提下選取一小部分用戶，予以部署和推送，這就是所謂的“暗”部署。
通過使用特征切換和其他類型的工具，您可以獲悉用戶是如何與新特性進行交互的。籍此，您可以判斷是否要將該特性正式推送給用戶，發現新的UI是否出現了混亂狀況，以及其他類型的參數指標。
Flagger和A/B部署
其實除了加權路由，Flagger還能夠在基于HTTP的各種匹配條件下，將訪問流量路由到金絲雀服務之中。例如，在A/B測試場景中，您可以使用各種HTTP頭或Cookie，來針對某一部分的用戶進行路由轉發。顯然，這對于那些需要進行會話關聯的前端應用來說，是特別實用的。當然具體內容，您可以去參考Flagger的相關文檔。
原文標題：Kubernetes Deployment Strategies，作者：Anita Buehrle
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
