在這篇文章中，我們將深入研究 Kubernetes 部署概念和一些常見策略，了解每種策略的優(yōu)缺點(diǎn)。合適的部署策略使我們能夠在發(fā)布應(yīng)用程序時(shí)最大限度地減少停機(jī)時(shí)間、增強(qiáng)客戶體驗(yàn)并提高可靠性。

什么是 Kubernetes 部署策略？

Kubernetes 部署是一種聲明性語(yǔ)句，通常在 YAML 文件中配置，用于定義應(yīng)用程序生命周期以及如何管理對(duì)該應(yīng)用程序的更新。

當(dāng)將應(yīng)用程序部署到 K8s 集群時(shí)，所選擇的部署策略將決定如何將應(yīng)用程序從舊版本更新到新版本。某些策略可能會(huì)導(dǎo)致停機(jī)時(shí)間，而其他策略則可能引入測(cè)試概念并允許用戶分析。本文將介紹兩種常用的基本 K8s 部署策略：

• 重新創(chuàng)建（Recreating）
• 滾動(dòng)更新（Rolling）

以下策略被認(rèn)為是“高級(jí)部署策略”，因?yàn)榭梢砸远喾N方式控制流量的流向：

• 藍(lán)/綠（Blue/Green）
• 金絲雀（Canary）
• A/B
• 影子部署（Shadow Deployment）

K8s 使用滾動(dòng)更新策略作為默認(rèn)策略，但在某些情況下可能不適用。讓我們?cè)敿?xì)討論每種策略！

1. 重新創(chuàng)建部署（Recreate Deployment）

重新創(chuàng)建部署會(huì)終止所有的 Pod，并用新版本的 Pod 替換它們。這在舊版本和新版本的應(yīng)用程序不能同時(shí)運(yùn)行的情況下很有用。使用此策略產(chǎn)生的停機(jī)時(shí)間取決于應(yīng)用程序關(guān)閉和啟動(dòng)所需的時(shí)間。由于完全替換，應(yīng)用程序狀態(tài)也會(huì)完全更新。

示例如下，type=Recreate表示為重新創(chuàng)建

spec:
  replicas: 10
  strategy:
    type: Recreate

2. 滾動(dòng)更新部署（Rolling Deployment）

滾動(dòng)更新是 K8s 的默認(rèn)部署方式，旨在減少集群的停機(jī)時(shí)間。滾動(dòng)更新會(huì)將運(yùn)行舊版本應(yīng)用程序的 Pod 逐步替換為新版本，而無(wú)需停機(jī)。

為了實(shí)現(xiàn)這一點(diǎn)，要使用就緒探針（Readiness probes）

就緒探針監(jiān)視應(yīng)用程序何時(shí)變?yōu)榭捎脿顟B(tài)。如果探針失敗，流量將不會(huì)發(fā)送到該 Pod。這些探針用于需要在就緒之前執(zhí)行部分初始化步驟的應(yīng)用程序，比如數(shù)據(jù)庫(kù)鏈接、緩存數(shù)據(jù)初始化，應(yīng)用的發(fā)布注冊(cè)等操作。

一旦就緒探針檢測(cè)到新版本應(yīng)用程序可用，舊版本應(yīng)用程序?qū)⒈粍h除。如果出現(xiàn)問(wèn)題，可以停止部署并回滾到上一個(gè)版本，避免整個(gè)集群的停機(jī)時(shí)間。由于每個(gè) Pod 逐個(gè)替換，對(duì)于較大的集群，部署需要一定的時(shí)間。如果在另一個(gè)部署完成之前觸發(fā)了新的部署，版本將更新為新部署中指定的版本，并且尚未部署成功的先前部署版本將被忽略。

觸發(fā)滾動(dòng)更新部署的條件是 Pod 規(guī)范中的某些更改，例如更新 Pod 的鏡像、環(huán)境變量或標(biāo)簽?？梢允褂妹?nbsp;kubectl set image 來(lái)更新 Pod 鏡像。

yaml文件的 Spec: -> strategy: 部分可以使用兩個(gè)參數(shù)來(lái)細(xì)化部署：maxSurge 和 maxUnavailable。這兩個(gè)參數(shù)可以指定為百分比或絕對(duì)數(shù)值。當(dāng)使用水平 Pod 自動(dòng)縮放時(shí)，應(yīng)使用百分比。

• maxSurge 指定部署允許同時(shí)創(chuàng)建的最大 Pod 數(shù)量。
• maxUnavailable 指定在部署期間允許不可用的最大 Pod 數(shù)量。

例如，下面的配置要求有 10 個(gè)副本，最多同時(shí)創(chuàng)建 3 個(gè)副本，允許在部署期間有 1 個(gè)副本不可用：

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 1

3.藍(lán)/綠部署（Blue/Green Deployment）

藍(lán)/綠部署涉及將新的應(yīng)用程序版本（綠色）與舊版本（藍(lán)色）一起部署。通過(guò)服務(wù)選擇器對(duì)象作為負(fù)載均衡器，當(dāng)新應(yīng)用程序（綠色）經(jīng)過(guò)測(cè)試和驗(yàn)證后，將流量引導(dǎo)到新應(yīng)用程序而不是舊應(yīng)用程序。藍(lán)/綠部署可能會(huì)造成成本增加，因?yàn)樵诓渴鹌陂g需要啟動(dòng)兩倍數(shù)量的應(yīng)用程序資源。

為了實(shí)現(xiàn)這一點(diǎn)，我們需要設(shè)置一個(gè)在部署之前的服務(wù)。例如，對(duì)于名為 web-app 的應(yīng)用程序的 v1.0.0 版本的藍(lán)色部署，yaml 文件中的服務(wù)選擇器部分可能如下所示：

kind: Service
metadata:
 name: web-app-01
 labels:
   app: web-app
selector:
   app: web-app
   version: v1.0.0

藍(lán)色 web-app 的部署如下：

kind: Deployment
metadata:
  name: web-app-01
spec:
  template:
        metadata:
           labels:
             app: web-app
             version: "v1.0.0"

當(dāng)我們想要將流量引導(dǎo)到應(yīng)用程序的新（綠色）版本時(shí)，我們更新 manifest 文件以指向新版本 v2.0.0。

kind: Service
metadata:
 name: web-app-02
 labels:
   app: web-app
selector:
   app: web-app
   version: v2.0.0

綠色應(yīng)用程序的部署如下：

kind: Deployment
metadata:
  name: web-app-02
spec:
  template:
        metadata:
           labels:
             app: web-app
             version: "v2.0.0"

4. 影子部署（Shadow Deployment）

金絲雀與“影子部署”一詞可以互換使用。

影子部署是一種策略，其中新版本的應(yīng)用程序與現(xiàn)有的生產(chǎn)版本一起部署，主要用于監(jiān)控和測(cè)試目的。在影子部署中，用戶流量不會(huì)主動(dòng)路由到新版本。這對(duì)于測(cè)試新功能的生產(chǎn)負(fù)載特別有用。

這種技術(shù)比較復(fù)雜，需要特殊要求，尤其是出口流量。例如，有一個(gè)商品，您想調(diào)用支付服務(wù)進(jìn)行影子測(cè)試，最終可能會(huì)讓客戶為他們的訂單支付兩次，所以復(fù)雜性比較高

5. 金絲雀部署（Canary Deployments）

金絲雀部署可用于讓一部分用戶測(cè)試應(yīng)用程序的新版本，或者在對(duì)新版本的功能性沒有完全信心時(shí)使用。新版本的一個(gè)副本與舊版本一起發(fā)布，其中舊版本應(yīng)用程序?yàn)榇蟛糠钟脩籼峁┓?wù)，而新版本應(yīng)用程序?yàn)橐恍〔糠譁y(cè)試用戶提供服務(wù)。如果新部署成功，則將其逐漸擴(kuò)展到更多用戶。

例如，在一個(gè)具有 100 個(gè)運(yùn)行的 Pod 的 K8s 集群中，有 95 個(gè)運(yùn)行著應(yīng)用程序的 v1.0.0 版本，而有 5 個(gè)運(yùn)行著新的 v2.0.0 版本。95% 的用戶將被路由到舊版本，而5% 的用戶將被路由到新版本。為此，我們使用并行的兩個(gè)部署，可以分別進(jìn)行擴(kuò)展。

舊應(yīng)用程序的 yaml 文件中的 spec 部分可能如下所示:

spec:
  replicas: 95

新應(yīng)用程序的 yaml 文件中的 spec 部分可能如下所示：

spec:
  replicas: 5

在上面的示例中，運(yùn)行 100 個(gè) Pod 可能是不切實(shí)際的。更好的方法是使用負(fù)載均衡器，如NGINX、HAProxy或Traefik，或者使用類似Istio、Hashicorp Consul或Linkrd的服務(wù)網(wǎng)格，他們可以提供對(duì)流量的更好控制。

6. A/B 部署

與金絲雀部署類似，使用 A/B 部署，我們可以基于一些目標(biāo)參數(shù)（通常是 HTTP 標(biāo)頭或 cookie等）定位給定的用戶，并根據(jù)權(quán)重在不同版本之間分配流量。這種技術(shù)被廣泛用于測(cè)試某個(gè)特定功能的轉(zhuǎn)化率，然后選擇轉(zhuǎn)化率最高的版本進(jìn)行最終部署。

這種方法通?；谑占挠脩粜袨閿?shù)據(jù)，并用于做出更好的業(yè)務(wù)決策。在 A/B 測(cè)試期間，用戶通常不會(huì)被告知新功能，以便進(jìn)行真實(shí)的測(cè)試，并可以比較使用舊版本和新版本的用戶之間的體驗(yàn)。由于額外的測(cè)試期和用戶體驗(yàn)分析，使用 A/B 部署進(jìn)行部署速度可能會(huì)較慢。

可以使用 Istio 和 Flagger 自動(dòng)化進(jìn)行 A/B 部署。

總結(jié)

在本文中，我們討論了6種常見的K8s部署策略。在決定如何部署或升級(jí)您的應(yīng)用程序時(shí)，如何使用這些策略，以及使用哪些工具來(lái)實(shí)現(xiàn)每種策略是非常重要的。