簡介：Kubernetes下5場場景應用發布方式的選擇，每種發布模式適合什么樣的場景，以及如何在阿里云云效上高效落地。

作者：鄭云龍，阿里云云效技術專家

Kubernetes面向通用場景提供了非常靈活的應用管理和運維方式，而作為云效CI/CD平臺的開發同學，在日常和用戶交流過程中，我們經常會被用戶問到關于發布的問題，比如不同職能團隊之間應該如何配合、發布的最佳實踐應該是什么樣子的等等。

今天我們就來聊聊Kubernetes下應用發布方式的選擇，每種發布模式適合什么樣的場景，以及如何在云效上高效落地。

Kubernetes應用

首先我們來看看一般情況下Kubernetes是如何管理應用的。 Kubernetes通過聲明式的API，并提供了一系列的資源來滿足各種各樣的應用運維場景：

? 從應用的角度我們會關注應用容器（Pod），應用配置（ConfigMap/Secret），應用需要持久化的信息（Volume），應用與應用之間的服務發現（Service），以及如何將應用服務暴露給集群外的用戶（Ingress）等。

? 從集群運維的角度看，由于應用運行在集群中我們需要控制應用在集群中的權限（ServiceAccount/ClusterRole/Role）使得應用能夠以最小所需權限原則在集群中運行，同時運維要管理和配置集群的存儲資源(PV/PVC)，同時對于資源有限的情況我們還需要管理和控制應用本身的資源暫用以及配額（quata）等等等。

而在實際場景中由于應用使用的框架（Doubbo/Spring Cloud）的不同，應用對外提供的服務場景不同（后端或者前端），不同的應用可能只需要關注其中的一小部分資源
比如當你采用了像Spring Cloud或者Doubbo這類自帶了服務發現的應用開發框架，你可能并不關心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實際中的各種發布模式以及相關的適用場景，希望能夠幫助用戶快速找到適合自己的發布模式，當然如果你還有更多更好的交付實踐，也可以在留言中進行分享。

如果你對云效流水線感興趣，前往 云效流水線 即可免費使用。

原文鏈接：https://developer.aliyun.com/article/780988?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的阿里云云效技术专家：一文详解kubernetes下5种常见发布模式如何选择的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。