作者：鄭雲龍，阿裡雲雲效技術專家
Kubernetes面向通用場景提供了非常靈活的應用管理和運維方式，而作為
雲效CI/CD平台的開發同學，在日常和使用者交流過程中，我們經常會被使用者問到關于釋出的問題，比如不同職能團隊之間應該如何配合、釋出的最佳實踐應該是什麼樣子的等等。
今天我們就來聊聊Kubernetes下應用釋出方式的選擇，每種釋出模式适合什麼樣的場景，以及如何在雲效上高效落地。
Kubernetes應用
首先我們來看看一般情況下Kubernetes是如何管理應用的。 Kubernetes通過聲明式的API，并提供了一系列的資源來滿足各種各樣的應用運維場景：
• 從應用的角度我們會關注應用容器（Pod），應用配置（ConfigMap/Secret），應用需要持久化的資訊（Volume），應用與應用之間的服務發現（Service），以及如何将應用服務暴露給叢集外的使用者（Ingress）等。
• 從叢集運維的角度看，由于應用運作在叢集中我們需要控制應用在叢集中的權限（ServiceAccount/ClusterRole/Role）使得應用能夠以最小所需權限原則在叢集中運作，同時運維要管理和配置叢集的存儲資源(PV/PVC)，同時對于資源有限的情況我們還需要管理和控制應用本身的資源暫用以及配額（quata）等等等。
而在實際場景中由于應用使用的架構（Dubbo/Spring Cloud）的不同，應用對外提供的服務場景不同（後端或者前端），不同的應用可能隻需要關注其中的一小部分資源
比如當你采用了像Spring Cloud或者Dubbo這類自帶了服務發現的應用開發架構，你可能并不關心Kubernetes所提供的服務發現能力(Service)，隻需要通過Deployment來部署和管理這些應用執行個體。 又比如說如果你采用了單獨的配置管理中心，那ConfigMap/Secret這些可能也不會出現在你的Kubernetes資源清單中。
又比如說，如果是一個面向使用者前端應用，在應用部署是除了Deployment執行個體以外，你還要關系如何将這個服務暴露給外部使用者，這是就需要相應的Ingress以及Service的資源來描述。
同時在單個應用在整個系統中所處的位置不同又會導緻我們對于釋出的驗證方式也會産生差異，比如一個後端微服務的釋出，我們可能隻需要確定釋出過程系統不中斷即可，而對于前端應用我們可能希望釋出能夠現在一小部分使用者上進行驗證，線上上流量充分測試後，再完成整個版本更新。
如上所示，對于應用而言采用的技術架構不同，提供的服務的方式不同，對釋出驗證方式要求的不同都會導緻Kubernetes的使用上産生各種各樣的差異，而雲效為了能夠支援這些不同的差異提供了多種多樣的釋出模式，接下來我們就來看看雲效下常用的這些釋出模式，以及他們所适用的場景。
Kubernetes釋出模式
最原生：YAML釋出
顧名思義，這是我們在使用Kubernetes時最直接的應用部署方式，而在持續傳遞流水線中我們一般将這些用于描述Kubernetes資源的YAML檔案通過Git進行統一版本管理，通過雲效CI/CD平台監聽代碼庫的變更事件，并通過流水線将這些YAML變更同步到叢集當中。這種方式也被稱為GitOps模式。
在
雲效當中，我們除了支援直接同步YAML到Kubernetes叢集以外，還擴充了基本的模闆能力，你可以通過在YAML檔案中定義變量占位符如${IMAGE}，通過流水線運作是通過Docker鏡像建構或者阿裡雲鏡像倉庫觸發器（幫助文檔：
阿裡雲鏡像倉庫觸發器觸發流水線），動态産生要釋出的鏡像版本
如下所示：
YAML釋出支援任意資源類型，是以适用于如下場景：
1、開發自運維，團隊并充分了解和掌握Kubernetes原生的釋出政策，希望通過YAML完成應用的更新與釋出以及復原，一般來說應用Git庫會包含應用源碼，Dockerfile以及部署應用所需的所有YAML檔案（在某些情況下，YAML可能是由單獨的Git倉庫進行管理，以進行細粒度的權限控制）。
2、基礎設施運維：運維團隊通過Git管理叢集的所有基礎設施配置，并通過流水線完成叢集的統一管理以及配置的同步
更多詳細使用介紹請參考：
雲效Kubernetes YAML釋出**最簡單：鏡像更新
**
在和一些
使用者的交流場景中，在也會有使用者希望開發團隊能夠盡可能少的了解Kubernetes相關概念，在這種情況下由專職的運維團隊負責完成應用環境的部署和初始化。而開發團隊隻負責完成代碼開發，并通過流水線自動化完成應用鏡像建構，并使用該鏡像對叢集中已有的應用進行更新。開發團隊隻關心應用的工作負載執行個體資源。
如下圖所示，在
雲效流水線中我們監聽應用代碼庫的變化，并建構出相應的Docker鏡像，而釋出階段隻需要指定對叢集中執行個體并關聯前序任務産生的鏡像即可完成應用的更新釋出：
如上所述，該場景适用于：
• 開發和運維分離：運維團隊充分了解Kubernetes的原生釋出政策，開發團隊隻負責産出代碼以及應用鏡像，由運維團隊負責叢集中應用的實際運維管理。
關于如何在
中使用鏡像更新能力，請參考：
雲效Kubernetes鏡像更新過程可控：分批釋出
在前面兩個小結中，我們都強調使用者需要充分了解Kubernetes的原生釋出政策，Kubernetes原生的釋出政策主要是指RollingUpdate模式，使用者通過聲明更新政策，如maxSurge和maxUnavailable控制Pod的啟動政策以及最大不可用Pod數，來確定即使應用釋出出現異常的情況，也能保證服務的基本可用。
除此，由于應用啟動往往有一定的耗時，如果使用了Kubernetes的服務發現機制，我們還需要配置如liveness以及readiness探針，來避免應用還在啟動過程中就有不在計劃内的流量進入到正在啟動的執行個體當中。同時整個釋出過程是不可逆的，假如認定目前釋出出現了異常我們隻能通過重新釋出的方式來使應用回到可用狀态。
而在
的分批釋出中，我們以Service為最小釋出單元，在釋出開始階段我們将基于新版鏡像建立出應用的版本V2，并根據目前應用的副本總數以及分批數量，對新舊兩個版本的應用執行個體分别進行縮容和擴容，來控制實際進入到新版應用的流量比例，進而可以實作小規模的釋出驗證，在對釋出進行充分驗證後再逐漸完全下線老版應用。
同時批次之間支援暫停和手動恢複讓使用者可以充分對針對釋出過程進行控制。
該模式适用于：采用Kubernetes原生的服務發現機制，并希望獲得相比于原生Kubernetes釋出更好過程控制性以及安全性的使用者。
更多詳細使用介紹，請參考幫助文檔：
雲效Kubernetes分批釋出外部流量可控：Ingress灰階釋出
相比于分批釋出灰階釋出更強調更加可控和安全的線上驗證。而灰階釋出在Kubernetes中由于應用的部署模式的不同大緻分為兩種，我們首先來說第一種，基于Ingress的灰階釋出，如下所示，我們通過Ingress将叢集内的服務暴露給外部使用者：
在釋出過程中我們希望能夠通過cookie或者header的方式使得特定的使用者或者開發人員，能夠線上上對新版本引用進行驗證，經過小部分可控的線上流量驗證後，我們的釋出可靠性更好，如果出現預期外的問題，也可以快速復原，并且整個灰階驗證過程對非灰階使用者完全不可感覺。
的Ingress灰階釋出中，我們以Ingress作為釋出單元，當觸發部署後，将會根據目前Ingress以及其關聯的Service/Deployment資源，基于新版鏡像建立出V2版本的Service/Deployment。 并通過Nginx Ingress的Annoation完成對流量規則聲明，進而確定隻有滿足特定特征的流量才能進入到V2版本中，當處于灰階狀态時，流水線将會等待人工驗證，以觸發釋出或者或者復原操作。
中使用灰階釋出請參考幫助文檔：
雲效Nginx Ingress灰階釋出該模式适用于：采用Ingress對外暴露應用服務，并且希望能夠通過灰階的方式對釋出進行驗證
内部流量可控：Istio/ASM灰階釋出
而在微服務的場景中，并不是所有的服務都需要直接暴露給外部使用者，如下所示：
當采用微服務架構，我們大部分的後端服務是隻暴露與叢集内，微服務之間通過Kubernetes Service進行互相通路，在這種情況下，當采用灰階釋出模式時，我們需要在Service級别進行流量控制，已確定指定的流量才進入到灰階的鍊路而不對正常使用者産生影響。
不過由于Kubernetes原生在Service級别并不支援任何的流量控制規則，是以我們需要在叢集中部署Istio或者采用阿裡雲ServiceMesh來對服務之間的流量進行細粒度的控制。
如下圖所示，當使用Kubernetes藍綠釋出模式時，可以設定灰階流量規則，進而隻有當請求中包含指定的Cookie配置的請求轉發到灰階版本當中：
該模式适用于：采用Istio或者阿裡雲ServiceMesh的Kubernetes使用者，并且希望能夠通過灰階的方式對釋出進行驗證。
更多使用介紹請參考：
雲效Kubernetes灰階釋出小結
在本文中，我們主要介紹了Kubernetes實際中的各種釋出模式以及相關的适用場景，希望能夠幫助使用者快速找到适合自己的釋出模式，當然如果你還有更多更好的傳遞實踐，也可以在留言中進行分享。
如果你對雲效流水線感興趣，前往
即可免費使用。