在K8S中，Deployment 升級過程有哪些?

黄嘉波發表於2024-10-09
K8S

在Kubernetes（K8s）中，Deployment的升級過程是一個受控且平滑的過程，用於將應用的新版本無縫地替換舊版本。以下是Deployment升級過程的詳細步驟：

1. 更新Deployment配置
  1. 準備新版本映象或配置：
    • 確定新版本的應用程式映象或需要更改的配置。
    • 更新Deployment的YAML配置檔案，例如更改映象標籤到新版本的應用程式映象，或修改應用配置（如環境變數、命令引數等）。
  2. 應用更改：
    • 透過kubectl apply命令或API呼叫將新的配置應用到叢集中。例如，kubectl apply -f my-deployment.yaml。
2. Deployment控制器檢測到配置變化
  1. 開始執行滾動更新策略：
    • Kubernetes Deployment控制器檢測到配置變化後，會開始執行滾動更新（Rolling Update）策略。這是Deployment的預設升級策略。
3. 滾動更新過程
  1. 建立新的ReplicaSet：
    • Deployment控制器根據新的Pod模板建立一個新的ReplicaSet。
    • 新的ReplicaSet開始建立並啟動指定數量的新Pod，同時確保任何時候叢集中至少有一部分舊Pod仍在提供服務。
  2. 逐步替換舊Pod：
    • 滾動更新策略會按照ReplicaSet中的Pod副本數量和指定的.spec.strategy.rollingUpdate.maxUnavailable和.spec.strategy.rollingUpdate.maxSurge引數來逐步建立新版本Pod，並同時刪除舊版本Pod。
    • maxUnavailable定義了可以有多少個Pod不可用（未就緒）而不會影響服務的整體可用性。
    • maxSurge則指定了可以比期望副本數多建立多少個Pod，以加速升級過程。
  3. 健康檢查：
    • 在每個新Pod被建立之後，Kubernetes會根據定義的livenessProbe（存活探針）和readinessProbe（就緒探針）來檢查新Pod是否已經啟動並準備好接收流量。
    • 當新Pod透過健康檢查並標記為“就緒”時，Service會逐漸將流量從舊Pod轉移到新Pod。
  4. 完成替換：
    • 一旦所有舊Pod都被新Pod替換並且新版本的所有Pod都已準備就緒，則升級過程結束。
4. 監控與回滾
  1. 監控狀態：
    • 在升級過程中，可以透過kubectl或Kubernetes Dashboard監控Deployment的狀態以及Pod的健康狀況。
  2. 回滾操作：
    • 如果在升級過程中發現問題，可以立即執行回滾操作回到上一個已知穩定版本。
    • Kubernetes自動維護著每個Deployment的歷史記錄，允許使用者輕鬆地基於修訂歷史（revision history）回滾到之前任何一個版本。
5. 清理與驗證
  1. 清理舊資源：
    • 一旦驗證新版本的應用程式正常工作，可以考慮清理舊的ReplicaSet和Pod副本，以釋放資源。不過通常這些舊的ReplicaSet會被保留一段時間，以備回滾之需。
  2. 驗證新版本：
    • 測試新版本應用程式的功能，確保一切正常。
6. 其他操作
  1. 暫停與恢復更新：
    • 在滾動更新過程中，如果需要暫停更新過程，可以使用kubectl rollout pause deployment命令。這會阻止新的Pod建立，但不會影響現有Pod的執行。
    • 當準備好繼續時，可以使用kubectl rollout resume deployment命令繼續滾動更新。
  2. 檢查更新狀態：
    • 使用kubectl rollout status deployment命令來檢查滾動更新的狀態。

綜上所述，Kubernetes中的Deployment升級過程旨在實現最小的服務中斷和最大程度的可恢復性。透過滾動更新策略、健康檢查、監控與回滾機制等，可以確保應用程式在升級過程中的穩定性和可靠性。

相關文章