在這篇文章中，我們將深入研究 Kube.NETes 部署概念和一些常見策略，了解每種策略的優(yōu)缺點。合適的部署策略使我們能夠在發(fā)布應用程序時最大限度地減少停機時間、增強客戶體驗并提高可靠性。
什么是 Kubernetes 部署策略？
Kubernetes 部署是一種聲明性語句，通常在 YAML 文件中配置，用于定義應用程序生命周期以及如何管理對該應用程序的更新。
當將應用程序部署到 K8s 集群時，所選擇的部署策略將決定如何將應用程序從舊版本更新到新版本。某些策略可能會導致停機時間，而其他策略則可能引入測試概念并允許用戶分析。本文將介紹兩種常用的基本 K8s 部署策略：
- 重新創(chuàng)建（Recreating）
- 滾動更新（Rolling）
以下策略被認為是“高級部署策略”，因為可以以多種方式控制流量的流向：
- 藍/綠（Blue/Green）
- 金絲雀（Canary）
- A/B
- 影子部署（Shadow Deployment）
K8s 使用滾動更新策略作為默認策略，但在某些情況下可能不適用。讓我們詳細討論每種策略！
1. 重新創(chuàng)建部署（Recreate Deployment）
重新創(chuàng)建部署會終止所有的 Pod，并用新版本的 Pod 替換它們。這在舊版本和新版本的應用程序不能同時運行的情況下很有用。使用此策略產生的停機時間取決于應用程序關閉和啟動所需的時間。由于完全替換，應用程序狀態(tài)也會完全更新。
示例如下，type=Recreate表示為重新創(chuàng)建
spec:
replicas: 10
strategy:
type: Recreate
2. 滾動更新部署（Rolling Deployment）
滾動更新是 K8s 的默認部署方式，旨在減少集群的停機時間。滾動更新會將運行舊版本應用程序的 Pod 逐步替換為新版本，而無需停機。
為了實現(xiàn)這一點，要使用就緒探針（Readiness probes）
就緒探針監(jiān)視應用程序何時變?yōu)榭捎脿顟B(tài)。如果探針失敗，流量將不會發(fā)送到該 Pod。這些探針用于需要在就緒之前執(zhí)行部分初始化步驟的應用程序，比如數(shù)據(jù)庫鏈接、緩存數(shù)據(jù)初始化，應用的發(fā)布注冊等操作。
一旦就緒探針檢測到新版本應用程序可用，舊版本應用程序將被刪除。如果出現(xiàn)問題，可以停止部署并回滾到上一個版本，避免整個集群的停機時間。由于每個 Pod 逐個替換，對于較大的集群，部署需要一定的時間。如果在另一個部署完成之前觸發(fā)了新的部署，版本將更新為新部署中指定的版本，并且尚未部署成功的先前部署版本將被忽略。
觸發(fā)滾動更新部署的條件是 Pod 規(guī)范中的某些更改，例如更新 Pod 的鏡像、環(huán)境變量或標簽。可以使用命令 kubectl set image 來更新 Pod 鏡像。
yaml文件的 Spec: -> strategy: 部分可以使用兩個參數(shù)來細化部署：maxSurge 和 maxUnavailable。這兩個參數(shù)可以指定為百分比或絕對數(shù)值。當使用水平 Pod 自動縮放時，應使用百分比。
- 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.藍/綠部署（Blue/Green Deployment）
藍/綠部署涉及將新的應用程序版本（綠色）與舊版本（藍色）一起部署。通過服務選擇器對象作為負載均衡器，當新應用程序（綠色）經過測試和驗證后，將流量引導到新應用程序而不是舊應用程序。藍/綠部署可能會造成成本增加，因為在部署期間需要啟動兩倍數(shù)量的應用程序資源。
為了實現(xiàn)這一點，我們需要設置一個在部署之前的服務。例如，對于名為 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）
金絲雀與“影子部署”一詞可以互換使用。
影子部署是一種策略，其中新版本的應用程序與現(xiàn)有的生產版本一起部署，主要用于監(jiān)控和測試目的。在影子部署中，用戶流量不會主動路由到新版本。這對于測試新功能的生產負載特別有用。
這種技術比較復雜，需要特殊要求，尤其是出口流量。例如，有一個商品，您想調用支付服務進行影子測試，最終可能會讓客戶為他們的訂單支付兩次，所以復雜性比較高
5. 金絲雀部署（Canary Deployments）
金絲雀部署可用于讓一部分用戶測試應用程序的新版本，或者在對新版本的功能性沒有完全信心時使用。新版本的一個副本與舊版本一起發(fā)布，其中舊版本應用程序為大部分用戶提供服務，而新版本應用程序為一小部分測試用戶提供服務。如果新部署成功，則將其逐漸擴展到更多用戶。
例如，在一個具有 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 部署，我們可以基于一些目標參數(shù)（通常是 HTTP 標頭或 cookie等）定位給定的用戶，并根據(jù)權重在不同版本之間分配流量。這種技術被廣泛用于測試某個特定功能的轉化率，然后選擇轉化率最高的版本進行最終部署。
這種方法通常基于收集的用戶行為數(shù)據(jù)，并用于做出更好的業(yè)務決策。在 A/B 測試期間，用戶通常不會被告知新功能，以便進行真實的測試，并可以比較使用舊版本和新版本的用戶之間的體驗。由于額外的測試期和用戶體驗分析，使用 A/B 部署進行部署速度可能會較慢。
可以使用 Istio 和 Flagger 自動化進行 A/B 部署。
總結
在本文中，我們討論了6種常見的K8s部署策略。在決定如何部署或升級您的應用程序時，如何使用這些策略，以及使用哪些工具來實現(xiàn)每種策略是非常重要的。
