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

什么是 Kubernetes 部署策略？

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

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

• 重新創建（Recreating）
• 滾動更新（Rolling）

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

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

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

1. 重新創建部署（Recreate Deployment）

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

示例如下，type=Recreate表示為重新創建

spec:
  replicas: 10
  strategy:
    type: Recreate

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

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

為了實現這一點，要使用就緒探針（Readiness probes）

就緒探針監視應用程序何時變為可用狀態。如果探針失敗，流量將不會發送到該 Pod。這些探針用于需要在就緒之前執行部分初始化步驟的應用程序，比如數據庫鏈接、緩存數據初始化，應用的發布注冊等操作。

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

觸發滾動更新部署的條件是 Pod 規范中的某些更改，例如更新 Pod 的鏡像、環境變量或標簽。可以使用命令 kubectl set image 來更新 Pod 鏡像。

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

• maxSurge 指定部署允許同時創建的最大 Pod 數量。
• maxUnavailable 指定在部署期間允許不可用的最大 Pod 數量。

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

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

3.藍/綠部署（Blue/Green Deployment）

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

為了實現這一點，我們需要設置一個在部署之前的服務。例如，對于名為 web-app 的應用程序的 v1.0.0 版本的藍色部署，yaml 文件中的服務選擇器部分可能如下所示：

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

藍色 web-app 的部署如下：

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

當我們想要將流量引導到應用程序的新（綠色）版本時，我們更新 manifest 文件以指向新版本 v2.0.0。

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

綠色應用程序的部署如下：

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

4. 影子部署（Shadow Deployment）

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

影子部署是一種策略，其中新版本的應用程序與現有的生產版本一起部署，主要用于監控和測試目的。在影子部署中，用戶流量不會主動路由到新版本。這對于測試新功能的生產負載特別有用。

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

5. 金絲雀部署（Canary Deployments）

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

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

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

spec:
  replicas: 95

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

spec:
  replicas: 5

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

6. A/B 部署

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

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

可以使用 Istio 和 Flagger 自動化進行 A/B 部署。

總結

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