Kubernetes的高級部署策略集
譯文在現(xiàn)代化應(yīng)用技術(shù)領(lǐng)域中，容器編排平臺簡化了針對基于微服務(wù)應(yīng)用的基礎(chǔ)架構(gòu)配置，并通過模塊化實現(xiàn)了高效的工作負載的管理。而作為一個被廣泛采用的、能夠支持多種部署資源的平臺，Kubernetes更是方便了企業(yè)大規(guī)模地以CI/CD管道的方式，部署和管理各類應(yīng)用程序。雖然Kubernetes提供了滾動更新(rolling updates)作為默認的部署策略，但是某些用例則需要使用非常規(guī)的方法，來部署或更新集群中的各項服務(wù)。下面，我們將在回顧Kubernetes基本部署概念的基礎(chǔ)上，深入探討各種高級的Kubernetes部署策略、它們的優(yōu)缺點、及其用例。
Kubernetes的部署概念
在部署過程中，集群管理員可以自定義應(yīng)用程序的生命周期，以及執(zhí)行更新的方式。而Kubernetes通常會使用部署資源，并以聲明的方式去更新各類應(yīng)用程序。它的這種自動化部署方式，實現(xiàn)并維護了各個集群對象及應(yīng)用程序的所需狀態(tài)。而且，其后端無需人工干預(yù)，即可以一種安全且可重復(fù)的方式，來執(zhí)行應(yīng)用程序的更新。也就是說，Kubernetes的部署可以協(xié)助集群管理員實現(xiàn)：
- 部署單個pod或副本集
- 更新一組pod或副本集
- 回滾到早期的版本
- 暫?；蚶^續(xù)部署
- 擴展各種部署
下面，我們將探討Kubernetes是如何簡化容器化應(yīng)用的更新過程，以及它將如何應(yīng)對持續(xù)交付的挑戰(zhàn)。
Kubernetes對象
雖然Kubernetes可以利用許多種工作負載資源對象，作為持久實體，去管理集群的狀態(tài)，但Kubernetes API通常會使用Deployment(部署)、ReplicaSet(副本集)、StatefulSet(有狀態(tài)集)和DaemonSet(守護程序集)四種資源，對應(yīng)用程序進行聲明式更新。下面我們來具體看看這四種資源的特點：
??Deployment??
作為一種Kubernetes資源，Deployment可用于定義和識別應(yīng)用程序所需的狀態(tài)。集群管理員在Deployment的YAML文件中通過描述預(yù)期的狀態(tài)，以便部署控制器，并據(jù)此將實際狀態(tài)逐漸更改為預(yù)期的狀態(tài)。而為了確保高可用性，部署控制器還會通過持續(xù)監(jiān)控，按需將健康的集群節(jié)點和pod，去替換那些失敗的集群節(jié)點和pod。
??ReplicaSet??
ReplicaSet可用于維護特定數(shù)量的pod，以確保其高可用性。ReplicaSet的清單文件會包括如下字段：
- 用于識別隸屬于某個集合的pod選擇器
- 通過副本數(shù)，來表示集合中應(yīng)該有多少個pod
- 通過一個pod模板，來顯示新的pod應(yīng)創(chuàng)建哪些數(shù)據(jù)，以滿足副本集的標(biāo)準(zhǔn)
??StatefulSet??
StatefulSet對象可以管理某個有狀態(tài)的應(yīng)用程序中的pod部署與擴展。該資源會基于相同的容器規(guī)范，去管理pod，并確保整組pod的唯一性、以及排列有序。StatefulSet的持久性pod標(biāo)識符，能夠方便集群管理員將其工作負載連接到具有高可用性的持久性存儲卷上。
??DaemonSet??
DaemonSet通過確保一組節(jié)點運行在某個pod的副本上，來協(xié)助維護應(yīng)用程序的部署。DaemonSet資源主要被用于管理各種代理的部署和生命周期中，例如：
- 每個節(jié)點上的各個集群存儲代理
- 日志收集的守護進程
- 節(jié)點監(jiān)控的守護進程
您也可以通過鏈接--https://kubernetes.io/docs/concepts/workloads/controllers/，查看更多有關(guān)各種Kubernetes工作負載資源的列表，及其詳細信息。
使用部署更新
Kubernetes的部署提供了一種可預(yù)測的方法，來啟動和停止pod。有了這些資源，我們可以輕松地實施部署、回滾更改、以及以自主迭代式管理軟件的發(fā)布周期。目前，Kubernetes通過提供各種部署策略，來實現(xiàn)更小、更頻繁的更新，并為應(yīng)用提供如下優(yōu)勢：
- 通過更快的客戶反饋，以獲得更好的功能性優(yōu)化
- 縮短面市時間
- 提高DevOps團隊的生產(chǎn)力
默認情況下，由Kubernetes提供的滾動式更新，可作為其標(biāo)準(zhǔn)的部署策略，實現(xiàn)一次性將新的版本去替換某個舊的pod，以避免集群的停機。此外，根據(jù)功能性的目標(biāo)和類型的不同，Kubernetes還支持包括藍綠、金絲雀和A/B部署在內(nèi)，各種高級部署策略。下面，讓我們來詳細討論這些策略的特點，及其優(yōu)缺點。
Kubernetes部署的高級策略
部署配置與路由功能的結(jié)合使用，能夠方便發(fā)布團隊在提交完整版本之前，在實時的生產(chǎn)環(huán)境中，測試新功能的有效性。為此，開發(fā)人員可以利用Kubernetes所支持的高級部署策略，來精確地控制特定版本的質(zhì)量。當(dāng)然，具體應(yīng)當(dāng)采取何種Kubernetes的部署方式，去發(fā)布應(yīng)用程序的更新和新功能，則取決于實際用例和工作負載。
藍綠部署
在藍綠策略中，應(yīng)用程序的新舊實例會被同時部署。在用戶可以持續(xù)訪問現(xiàn)有版本(藍色)的同時，具有相同數(shù)量的??新版本(綠色)實例可供站點可靠性工程師??(site reliability engineering，SRE)和QA團隊使用。一旦QA團隊確認了綠色版本已通過所有測試要求，用戶就會被重定向到新的版本上。這往往是通過更新負載均衡服務(wù)上selector字段中的version標(biāo)簽來實現(xiàn)的。通常，當(dāng)開發(fā)人員想要避免出現(xiàn)版本控制問題時，藍綠部署就非常適用。
使用藍綠部署策略
讓我們假設(shè)某個應(yīng)用程序的第一個版為v1.0.0，而可用的第二個版是v2.0.0。那么如下代碼段便是指向第一個版本的服務(wù)：
apiVersion: v1
kind: Service
metadata:
name: darwin-service-a
spec:
type: LoadBalancer
selector:
app: nginx
version: v1.0.0
ports:
- name: http
port: 80
targetPort: 80
而下面是指向第二個版本的服務(wù)：
apiVersion: v1
kind: Service
metadata:
name: darwin-service-b
spec:
type: LoadBalancer
selector:
app: nginx
version: v2.0.0
ports:
- name: http
port: 80
targetPort: http
一旦我們完成了必要的測試，并批準(zhǔn)了第二個版本，那么指向第一個服務(wù)的selector就需要更改為v2.0.0：
apiVersion: v1
kind: Service
metadata:
name: darwin-service-a
spec:
type: LoadBalancer
selector:
app: nginx
version: v2.0.0
ports:
- name: http
port: 80
targetPort: http
如果新版本的應(yīng)用程序能夠按預(yù)期運行，那么v1.0.0版就可以“下線”了。
金絲雀部署
在金絲雀策略中，一部分用戶會被路由到承載了新版本的pod上。該用戶群會逐漸增加，而連接到舊版本的群體則會相應(yīng)減少。該策略可用于比較使用著兩個版本的用戶集合的體驗。如果未檢測到錯誤，我們則可以將新版本推送給遺留在舊版本上的用戶。
使用金絲雀部署策略
原生的Kubernetes金絲雀部署的過程包含如下步驟：
1. 通過以下方式部署運行版本1所需的副本：
部署第一個應(yīng)用程序：
$ kubectl apply -f darwin-v1.yaml
將其擴展至所需的副本數(shù)量：
$ kubectl scale --replicas=9 deploy darwin-v1
2.部署版本2的實例：
$ kubectl apply -f darwin-v2.yaml
3.測試版本2是否已部署成功：
$ service=$(minikube service darwin --url)
$ while sleep 0.1; do curl "$service"; done
4.如果部署成功，則擴展版本2的實例數(shù)量：
$ kubectl scale --replicas=10 deploy darwin-v2
5.一旦所有副本都上線，您就可以“優(yōu)雅地”刪除版本1了：
$ kubectl delete deploy darwin-v1
A/B部署
通過A/B部署，管理員可以將特定的用戶子集，路由到具有某些限制和/或條件的新版本上。此類部署主要被用于評估用戶群對某些新功能的反響。由于用戶在測試期間并不知曉自己已被呈現(xiàn)了新的功能，因此A/B部署有時也被稱為“暗啟動”。
使用A/B部署策略
以下是對??Istio服務(wù)網(wǎng)格??執(zhí)行A/B測試的方法示例。它將有助于使用流量權(quán)重(traffic weight)來推出不同的版本：
1.假設(shè)集群上已經(jīng)安裝了??Istio??，那么我們首先需要部署兩個版本的應(yīng)用：
$ kubectl apply -f darwin-v1.yaml -f darwin-v2.yaml
2. 然后，我們可以通過Istio網(wǎng)關(guān)去發(fā)布兩個版本，并使用如下命令，將請求匹配到第一個服務(wù)上：
$ kubectl apply -f ./gateway.yaml -f ./virtualservice.yaml
3.接著，我們可以使用如下命令，根據(jù)權(quán)重來應(yīng)用Istio的VirtualService規(guī)則：
$ kubectl apply -f ./virtualservice-weight.yaml
它會以1:10的比例，在版本之間分配流量的權(quán)重。為了轉(zhuǎn)移流量的權(quán)重，我們可以編輯每個服務(wù)的權(quán)重，然后通過Kubernetes CLI去更新VirtualService規(guī)則。
每種高級部署策略的適用場景
由于Kubernetes用例會因可用性要求、預(yù)算限制、可用資源和其他考慮因素而異，因此目前并不存在一種萬能的部署策略。您在選擇部署策略時，需要考慮以下表格：
Kubernetes部署策略比較
小結(jié)
借助各種部署資源，Kubernetes管理員可以通過建立高效的版本控制系統(tǒng)，來更新pod，回滾到早期版本、或擴展基礎(chǔ)架構(gòu)，以滿足不斷增長的工作負載，并通過管理應(yīng)用的不同版本，來最小化停機時間。
上文介紹的各種Kubernetes高級部署策略，能夠在一定程度上方便管理員將流量和請求路由到特定的版本上，從而在真實的測試環(huán)境中處理各種錯誤。同時，這些策略也常被用于，在管理員和開發(fā)人員完全提交更改之前，檢驗新的功能是否能夠按照原定計劃運行，以及通過充分的回滾選項，實現(xiàn)多種松散的耦合服務(wù)，進而實現(xiàn)應(yīng)用更新和功能上的快速交付。當(dāng)然，具體該如何選擇，還需要您根據(jù)實際的應(yīng)用環(huán)境，參照上述比較表，做出選擇。
其他可參考資源
譯者介紹
陳峻 (Julian Chen)，51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗;持續(xù)以博文、專題和譯文等形式，分享前沿技術(shù)與新知;經(jīng)常以線上、線下等方式，開展信息安全類培訓(xùn)與授課。
原文標(biāo)題：Advanced Kubernetes Deployment Strategies，作者：Sudip Sengupta
