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

什么是 Kubernetes 部署策略？

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

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

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

以下策略被認(rèn)為是“高級部署策略”，因為可以以多種方式控制流量的流向：

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

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

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

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

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

spec:
  replicas: 10
  strategy:
    type: Recreate

2. 滾動更新部署（Rolling Deployment）

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

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

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

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

觸發(fā)滾動更新部署的條件是 Pod 規(guī)范中的某些更改，例如更新 Pod 的鏡像、環(huán)境變量或標(biāo)簽。可以使用命令 kubectl set image 來更新 Pod 鏡像。

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

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

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

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

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

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

為了實現(xiàn)這一點，我們需要設(shè)置一個在部署之前的服務(wù)。例如，對于名為 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)用程序的新（綠色）版本時，我們更新 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)控和測試目的。在影子部署中，用戶流量不會主動路由到新版本。這對于測試新功能的生產(chǎn)負(fù)載特別有用。

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

5. 金絲雀部署（Canary Deployments）

金絲雀部署可用于讓一部分用戶測試應(yīng)用程序的新版本，或者在對新版本的功能性沒有完全信心時使用。新版本的一個副本與舊版本一起發(fā)布，其中舊版本應(yīng)用程序為大部分用戶提供服務(wù)，而新版本應(yīng)用程序為一小部分測試用戶提供服務(wù)。如果新部署成功，則將其逐漸擴(kuò)展到更多用戶。

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

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

spec:
  replicas: 95

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

spec:
  replicas: 5

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

6. A/B 部署

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

這種方法通常基于收集的用戶行為數(shù)據(jù)，并用于做出更好的業(yè)務(wù)決策。在 A/B 測試期間，用戶通常不會被告知新功能，以便進(jìn)行真實的測試，并可以比較使用舊版本和新版本的用戶之間的體驗。由于額外的測試期和用戶體驗分析，使用 A/B 部署進(jìn)行部署速度可能會較慢。

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

總結(jié)

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