作者 | 郝樹偉（流生）阿里云高級研發(fā)工程師

前言

軟件技術更新?lián)Q代很快，但我們追求的目標是一直不變的，那就是在安全穩(wěn)定的前提下，增加應用的部署頻率，縮短產(chǎn)品功能的迭代周期，這樣的好處就是企業(yè)可以在更短的時間內(nèi)獲得產(chǎn)品的價值、更快地獲得客戶反饋和響應客戶需求，從而進一步提升產(chǎn)品的競爭力；除此之外，企業(yè)還可以釋放更多的資源投入到創(chuàng)新業(yè)務的研發(fā)上，創(chuàng)造更多的價值，這是一個良性循環(huán)的過程。

應用產(chǎn)品的快速迭代誠然能給我們帶來各種各樣的好處，但挑戰(zhàn)也與其并存。更高頻率的應用發(fā)布，意味著線上業(yè)務有不可預期故障的風險更大，除了產(chǎn)品上線之前在預發(fā)測試環(huán)境中充分測試驗證迭代功能之外，制定最合適的應用發(fā)布策略就是另外一個非常重要的話題，因為它可以最大限度的降低業(yè)務故障的風險以及帶來的損失。

云原生應用交付的關鍵點

我們說頻繁地進行產(chǎn)品迭代意味著更大的故障風險，傳統(tǒng)應用如此，云原生應用更是如此。因為云原生應用通常都是基于云的分布式部署模式，且每個應用可能是由多個功能組件互相調(diào)用來一起提供完整的服務的，每個組件都有自己獨立的迭代流程和計劃。在這種情況下，功能組件越多，意味著出錯的概率越大。那么如何在應用交付層面對上述這些痛點做出改進，我們總結(jié)出以下幾個云原生應用交付的關鍵點。

• 如何充分利用云原生架構基礎設施的優(yōu)勢。這個優(yōu)勢我們可以簡單總結(jié)為兩點：彈性和高可用；
• 如何具有跨平臺移植和交付的能力。基礎設施底層的計算、存儲、網(wǎng)絡資源有很大的差異化，在以前，基礎架構的不同是由上層應用決定的，而云原生應用的交付需要具有跨平臺移植和交付的能力；
• 如何實現(xiàn)應用運維自治化。自治化不等于自動化，自動化是指觸發(fā)一個流程，流程結(jié)束后能自動達到想要的一個預期結(jié)果，而自治化是指應用再高可用的運行態(tài)時，如果其中某個功能組件的某個副本出現(xiàn)故障，應用能自動移除故障副本并補充新的應用副本；
• 如何讓應用變得更具有可預測性。應用的交付終態(tài)，在我們編寫應用編排模板的時候就是可預測到的，如果應用的交付變得更有可預測性，那么風險也會最大程度地降低；
• 如何提高應用更快的平均恢復時間。如果應用有超出了應用自治的能力范疇之外的故障發(fā)生需要人工介入，那更快的平均恢復時間就意味著更低的業(yè)務損失。

Kubernetes 是一個可移植的，可擴展的開源平臺，用于管理容器化的工作負載和服務，可促進聲明式配置和自動化。它自身的平臺能力已經(jīng)滿足了我們前面提到的大部分需求。Kubernetes 使用容器技術部署應用，這樣的好處包括但不限于：

• 應用程序創(chuàng)建和部署更敏捷
• 可移植性
• 環(huán)境一致性
• 松耦合和分布式
• 資源隔離
• 高效率和高密度的資源利用

Kubernetes 還提供了應用管理、調(diào)度、監(jiān)控和運維的強大能力：

• 服務發(fā)現(xiàn)和負載均衡能力
• 應用的自動部署和回滾能力
• 應用的自治修復能力
• 存儲編排能力
• 密鑰和配置管理能力

但 Kubernetes 它也有很多功能是不提供但允許擴展的部分，比如日志采集、監(jiān)控報警等能力。下面這張圖就是阿里云容器服務是在支持標準 Kubernetes 的基礎上，對與用戶息息相關的能力做了增強和提升后的架構大圖，包括提供最大的彈性化與低廉成本的全球化接入能力，強大的安全架構支撐能力，深度整合阿里云基礎資源服務的能力，并經(jīng)過 雙11 驗證和沉淀了海量用戶經(jīng)驗，同時支持專有、托管、無服務化、邊緣和神龍裸金屬等多種產(chǎn)品形態(tài)，我們今天后面的所有演示就是在此平臺上做的。

應用交付的邊界

在 Kubernetes 中應用交付的邊界是什么？

從簡單處入手，我們可以認為應用的交付就是它的網(wǎng)絡服務模式，服務的的后端資源以及業(yè)務數(shù)據(jù)的持久化存儲，這些資源被分別抽象成 service、deployment/pod，volume 資源等。

以一個 wordpress 應用為例，它包括兩個功能組件：前端組件處理用戶請求，后端組件存儲數(shù)據(jù)。前端組件包括一個 frontend service 和 3 個 pod，后端組件包括一個 backend service 和一個 pod 組件，所以這個 wordpress 應用交付的資源就是 2 個 service 和總共 4 個后端 pod。這個后端的 pod 資源我們在 Kubernetes 中通過 deployment 來統(tǒng)一管理，service 資源相當于一個負載均衡器，把請求路由到后端 pod 上，它涉及集群內(nèi)各個組件之間調(diào)用以及外部用戶訪問集群內(nèi)服務，所以有不同的種類劃分。

根據(jù)服務暴露的方式不同，可以分為以下幾種：

ClusterIP

通過為 Kubernetes 的 Service 分配一個集群內(nèi)部可訪問的固定虛擬 IP（Cluster IP），實現(xiàn)集群內(nèi)的訪問。為最常見的方式。

apiVersion: v1 kind: Service metadata:name: wordpress spec:type: ClusterIP # 默認的service類型，服務僅暴露為集群內(nèi)部可訪問ports:- port: 80 # 暴露給集群內(nèi)部的服務端口targetPort: 80 # 容器監(jiān)聽的服務端口protocol: TCPselector:app: wordpress # 轉(zhuǎn)發(fā)請求到有相同標簽的后端pod

NodePort

NodePort 是把 service 的 port 映射到集群節(jié)點的一個端口上，如果你不指定這個端口，系統(tǒng)將選擇一個隨機端口。大多數(shù)時候我們應該讓 Kubernetes 來選擇端口，用戶自己來選擇可用端口代價太大。

apiVersion: v1 kind: Service metadata:name: wordpress spec:type: NodePort # NodePort service類型，服務暴露一個固定的靜態(tài)端口用于集群外部訪問ports:- port: 80 # 暴露給集群內(nèi)部的服務端口targetPort: 80 # 容器監(jiān)聽的服務端口protocol: TCPnodePort: 31570 # 集群外部可以通過此端口訪問服務selector:app: wordpress # 轉(zhuǎn)發(fā)請求到有相同標簽的后端pod

NodePort 的方式雖然可以把服務暴露給集群外訪問，但是也有很多缺點：

• 每個端口只能是一種服務
• 端口范圍有限制，一般是 30000-32767
• 如果節(jié)點的 IP 地址變化了的話，你需要做一些變更操作去適配

所以在生產(chǎn)中一般不推薦這種方式，但如果你的應用對成本比較敏感又能容忍服務有不可用窗口期的話，是可以使用這種方式的。

LoadBalancer

LoadBalancer 是服務暴露到集群外或者公網(wǎng)上的標準方式，但它依賴 cloud provider 提供的一個負載均衡器的能力，負載均衡器會單獨分配一個 ip 地址并監(jiān)聽后端服務的指定端口，請求的流量會通過指定的端口轉(zhuǎn)發(fā)到后端對應的服務。

apiVersion: v1 kind: Service metadata:name: wordpress spec:type: LoadBalancer # LoadBalancer service類型，一般依賴于公共云廠商供的負載均衡能力ports:- port: 80 # 暴露給集群內(nèi)部的服務端口targetPort: 80 # 容器監(jiān)聽的服務端口protocol: TCPselector:app: wordpress # 轉(zhuǎn)發(fā)請求到有相同標簽的后端pod

Ingress

ClusterIP 服務類型僅限集群內(nèi)通信，NodePort 可以實現(xiàn)暴露服務訪問入口，但每個節(jié)點都會占用一個端口，會增加端口管理的復雜性，LoadBalancer 通常需要第三方云提供商支持，有一定的約束性。而 Ingress 這個服務類型跟我們前面的三種服務類型不一樣，它實際上不是一種服務類型，而是類似一種集群服務入口的存在，它可以基于你配置的不同路徑或者子域名把流量路由到對應的后端服務，更像是一個“智能路由”服務。

前面介紹了一些應用發(fā)布涉及到的資源類型，以及 service 資源類型的幾種模式，那 service 如何找到對應的后端 pod 呢，這個就是標簽的作用，我們可以把每個應用的 pod 和 service 都打上同樣的標簽，這個標簽的機制就是我們后面要講的幾種應用發(fā)布策略的關鍵點了。

應用的發(fā)布策略

在 Kubernetes 集群中，除了根據(jù)業(yè)務需求選定服務暴露方式外，為了讓應用在升級期間依然平穩(wěn)提供服務，選擇一個正確的發(fā)布策略就非常重要了。

滾動發(fā)布

第一種應用發(fā)布策略就是滾動發(fā)布，這也是比較常見的策略。它是通過逐個替換實例來逐步部署新版本的應用，直到所有實例都被替換完成為止。

如下圖所示，當前我的應用提供的服務版本是 v1， 這個服務的后端有 3 個副本， 但我更新版本 v2 的時候，它是一個副本一個副本地開始替換，直到最終服務的后端全部替換成 v2 版本。

一個應用示例的編排文件如下所示：

• go-demo-v1.yaml

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo spec:replicas: 3selector:matchLabels:app: go-demotemplate:metadata:labels:app: go-demospec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1imagePullPolicy: Alwaysports:- containerPort: 8080 --- apiVersion: v1 kind: Service metadata:name: go-demo spec:ports:- port: 80targetPort: 8080name: go-demoselector:app: go-demotype: ClusterIP

• 部署版本 v1

$ kubectl apply -f go-demo-v1.yaml

• 查看 pod 運行狀態(tài)

$ kubectl get po NAME READY STATUS RESTARTS AGE go-demo-78bc65c564-2rhxp 1/1 Running 0 19s go-demo-78bc65c564-574z6 1/1 Running 0 19s go-demo-78bc65c564-sgl2s 1/1 Running 0 19s

• 訪問應用服務

$ while sleep 0.1; do curl http://172.19.15.25; done Version: v1 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1

• 更新 go-demo-v1.yaml 為 go-demo-v2.yaml 并更新鏡像 tag

... registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2 ...

• 部署版本 v2

$ kubectl apply -f go-demo-v2.yaml

• 可以查看 pod 會被新版本 pod 逐個替換

$kubectl get po -w NAME READY STATUS RESTARTS AGE application-demo-8594ff4967-85jsg 1/1 Running 0 3m24s application-demo-8594ff4967-d4sv8 1/1 Terminating 0 3m22s application-demo-8594ff4967-w6lpz 0/1 Terminating 0 3m20s application-demo-b98d94554-4mwqd 1/1 Running 0 3s application-demo-b98d94554-ng9wx 0/1 ContainerCreating 0 1s application-demo-b98d94554-pmc5g 1/1 Running 0 4s

• 訪問服務會發(fā)現(xiàn)在應用滾動升級過程中，版本 v1 和 v2 都會被訪問到，這個時間的長短取決于應用的啟動速度

$ while sleep 0.1; do curl http://172.19.15.25; done Version: v1 Version: v2 Version: v1 Version: v1 Version: v2 Version: v1 Version: v1 Version: v2

滾動發(fā)布優(yōu)點就是它比較簡單，而且不會占用太多的計算資源。缺點是：

• 版本在實例之間緩慢替換
• 這個滾動發(fā)布可能需要一定時間
• 無法控制流量

從應用在集群中的終態(tài)上來說，集群中要么只有版本 1 的應用后端，要么只有版本 2 的后端；如果版本 2 有缺陷，那么線上服務應用到的就是整體用戶， 雖然我們有機制可以快速回滾，但涉及到整體用戶使用故障的代價還是太大。

藍綠發(fā)布

第二種就是藍綠發(fā)布，藍/綠發(fā)布是應用版本 1 與版本 2 的后端 pod 都部署在環(huán)境中，通過控制流量切換來決定發(fā)布哪個版本。與滾動發(fā)布相比，藍綠發(fā)布策略下的應用終態(tài)，是可以同時存在版本 1 和版本 2 兩種 pod 的，我們可以通過 service 流量的切換來決定當前服務使用哪個版本的后端。

一個應用示例的編排文件如下所示。

• go-demo-v1.yaml

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo-v1 spec:replicas: 4selector:matchLabels:app: go-demoversion: v1template:metadata:labels:app: go-demoversion: v1spec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1imagePullPolicy: Alwaysports:- containerPort: 8080

• go-demo-v2.yaml

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo-v2 spec:replicas: 4selector:matchLabels:app: go-demoversion: v2template:metadata:labels:app: go-demoversion: v2spec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2imagePullPolicy: Alwaysports:- containerPort: 8080

• service.yaml

apiVersion: v1 kind: Service metadata:name: go-demo spec:ports:- port: 80targetPort: 8080name: go-demoselector:app: go-demoversion: v1type: ClusterIP

• 部署以上 3 個資源

$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml

• 訪問服務可以看到目前只訪問到版本 1 的服務

$ while sleep 0.1; do curl http://172.19.8.137; done Version: v1 Version: v1 Version: v1 Version: v1 Version: v1

• 修改 service.yaml 的 spec.selector 下 version=v2

apiVersion: v1 kind: Service metadata:name: go-demo spec:ports:- port: 80targetPort: 8080name: go-demoselector:app: go-demoversion: v2type: ClusterIP

• 重新部署

$ kubectl apply -f service.yaml

• 重新訪問服務可以看到很快切換到了版本 2 上

$ [root@iZbp13u3z7d2tqx0cs6ovqZ blue-green]# while sleep 0.1; do curl http://172.19.8.137; done Version: v2 Version: v2 Version: v2

我們剛才說到滾動升級有一個過程需要時間，即使回滾，它也需要一定的時間才能回滾完畢，在新版本應用有缺陷的情況下，藍綠發(fā)布的策略可以快速在 v1 和 v2 兩個版本之前切流量，所以這個切換流量的時間跟滾動升級相比就縮短了很多了，但藍綠發(fā)布的缺點跟滾動發(fā)布相同的就是這個缺陷會影響到整體用戶，服務要么百分百切換到版本 2 上，要么百分百切換到版本 1 上，這是個非 0 即 100 的操作，即使藍綠發(fā)布策略可以大大縮短故障恢復時間，但在某些場景下也是不可接受的。 而且集群環(huán)境中同時存在兩個版本的 pod 副本，資源占用的話相比滾動發(fā)布是 2 倍的。

金絲雀發(fā)布（灰度發(fā)布）

第三種要介紹的發(fā)布策略是金絲雀發(fā)布，金絲雀部署是應用版本 1 和版本 2 同時部署在環(huán)境中，并且用戶請求有可能會路由到版本 1 的后端，也可能會路由到版本 2 的后端，從而達到讓一部分新用戶訪問到版本 2 的應用。 這種發(fā)布策略下，我們可以通過調(diào)整流量百分比來逐步控制應用向新的版本切換，它與藍綠部署相比，不僅繼承了藍綠部署的優(yōu)點，而且占用資源優(yōu)于藍綠部署所需要的 2 倍資源，在新版本有缺陷的情況下只影響少部分用戶，把損失降到最低。

對于灰度發(fā)布的概念來說，有人認為它跟金絲雀發(fā)布講的是一個東西，有人認為它們不同。它跟金絲雀發(fā)布的過程是相同的，但目的有所不同：

• 金絲雀發(fā)布更傾向于能快速獲取用戶的一些反饋，比如我可能不確定我的這個新版本功能的用戶體驗是否能被大眾很好的接受，我期望能得到線上用戶的一些及時反饋，在產(chǎn)品側(cè)做功能體驗調(diào)整之后再迭代 v3 版本；
• 而灰度發(fā)布則是我的產(chǎn)品功能已經(jīng)設計并開發(fā)的很完善了，現(xiàn)在就是要逐步替換線上的舊版本，但是要控制發(fā)布可能帶來的風險，所以要灰度發(fā)布。

示例應用 1 如下， 這個示例中我們通過 pod 的數(shù)量來控制流量比例。

• go-demo-v1.yaml 設定副本數(shù)為 9

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo-v1 spec:replicas: 9selector:matchLabels:app: go-demoversion: v1template:metadata:labels:app: go-demoversion: v1spec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1imagePullPolicy: Alwaysports:- containerPort: 8080

• go-demo-v2.yaml 設定副本數(shù)為 1

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo-v2 spec:replicas: 1selector:matchLabels:app: go-demoversion: v2template:metadata:labels:app: go-demoversion: v2spec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2imagePullPolicy: Alwaysports:- containerPort: 8080

• service.yaml

apiVersion: v1 kind: Service metadata:name: go-demo spec:ports:- port: 80targetPort: 8080name: go-demoselector:app: go-demotype: ClusterIP

• 部署以上 3 個資源

$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service.yaml

• 訪問服務可以看到基本上是 10% 的流量切換到版本 2 上

$ while sleep 0.1; do curl http://172.19.8.248; done Version: v1 Version: v2 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1

另外我們可以使用 nginx ingress controller 來控制流量切換，這個方式要更精準。

• go-demo-v1.yaml

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo-v1 spec:replicas: 3selector:matchLabels:app: go-demoversion: v1template:metadata:labels:app: go-demoversion: v1spec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v1imagePullPolicy: Alwaysports:- containerPort: 8080

• go-demo-v2.yaml

apiVersion: apps/v1 kind: Deployment metadata:name: go-demo-v2 spec:replicas: 1selector:matchLabels:app: go-demoversion: v2template:metadata:labels:app: go-demoversion: v2spec:containers:- name: go-demoimage: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/go-demo:v2imagePullPolicy: Alwaysports:- containerPort: 8080

• service-v1.yaml

apiVersion: v1 kind: Service metadata:name: go-demo-v1 spec:ports:- port: 80targetPort: 8080name: go-demoselector:app: go-demoversion: v1type: ClusterIP

• service-v2.yaml

apiVersion: v1 kind: Service metadata:name: go-demo-v2 spec:ports:- port: 80targetPort: 8080name: go-demoselector:app: go-demoversion: v2type: ClusterIP

• ingress.yaml， 設置 nginx.ingress.kubernetes.io/service-weight: | go-demo-v1: 100, go-demo-v2: 0， 版本1 - 100% 流量， 版本2 - 0% 流量

apiVersion: extensions/v1beta1 kind: Ingress metadata:annotations:nginx.ingress.kubernetes.io/service-weight: |go-demo-v1: 100, go-demo-v2: 0name: go-demolabels:app: go-demo spec:rules:- host: go-demo.example.comhttp:paths:- path: /backend:serviceName: go-demo-v1servicePort: 80- path: /backend:serviceName: go-demo-v2servicePort: 80

• 部署以上 4 個資源

$ kubectl apply -f go-demo-v1.yaml -f go-demo-v2.yaml -f service-v1.yaml -f service-v2.yaml -f nginx.yaml

• 訪問服務可以看到流量 100% 到版本 1 上

$ while sleep 0.1; do curl http://go-demo.example.com; done Version: v1 Version: v1 Version: v1 Version: v1 Version: v1 Version: v1

• 更新 ingress.yaml， 設置流量比為 50:50

apiVersion: extensions/v1beta1 kind: Ingress metadata:annotations:nginx.ingress.kubernetes.io/service-weight: |go-demo-v1: 50, go-demo-v2: 50name: go-demolabels:app: go-demo spec:rules:- host: go-demo.example.comhttp:paths:- path: /backend:serviceName: go-demo-v1servicePort: 80- path: /backend:serviceName: go-demo-v2servicePort: 80

• 訪問服務可以看到流量 50% 到版本 1 上， 50% 到版本 2 上

$ while sleep 0.1; do curl http://go-demo.example.com; done Version: v2 Version: v1 Version: v1 Version: v1 Version: v2 Version: v2 Version: v1 Version: v1 Version: v2 Version: v2

• 更新 ingress.yaml， 設置流量比為 0:100

apiVersion: extensions/v1beta1 kind: Ingress metadata:annotations:nginx.ingress.kubernetes.io/service-weight: |go-demo-v1: 0, go-demo-v2: 100name: go-demolabels:app: go-demo spec:rules:- host: go-demo.example.comhttp:paths:- path: /backend:serviceName: go-demo-v1servicePort: 80- path: /backend:serviceName: go-demo-v2servicePort: 80

• 訪問服務可以看到流量 100% 到版本 2 上

$ while sleep 0.1; do curl http://go-demo.example.com; done Version: v2 Version: v2 Version: v2 Version: v2 Version: v2 Version: v2 Version: v2 Version: v2 Version: v2 Version: v2

不管是金絲雀發(fā)布還是灰度發(fā)布，缺點就是發(fā)布周期相對來說要慢很多。

在這些發(fā)布策略當中，

• 當你在開發(fā)測試環(huán)境中對應用做更新發(fā)布的話，用滾動發(fā)布；
• 在生產(chǎn)環(huán)境，滾動更新或者藍綠發(fā)布在新版本已經(jīng)提前測試充分的情況下可以用；
• 如果對新版本的應用的更新需要最大限度地控制風險，降低故障對用戶的影響的話，那就使用金絲雀發(fā)布或灰度發(fā)布。

以上就是我們在 Kubernetes 當中常用的幾種發(fā)布策略的介紹。

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術圈。”

《新程序員》：云原生和全面數(shù)字化實踐50位技術專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的3 种发布策略，解决 K8s 中快速交付应用的难题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。