隨著應用程式不斷迭代，如何保證在升級過程中不影響用戶體驗是一大挑戰。今天，我們將深入探討 Kubernetes 的 滾動更新 (Rolling Update) 和 回復 (Rollback) 策略。這些功能能夠幫助我們在應用更新時保持服務的穩定運行，並且在出現問題時迅速回復到先前的版本。在文章最後，會列出幾個常見的使用情境，說明如何在實際操作中靈活應用滾動更新與回復功能~

什麼是滾動更新 (Rolling Update)？

滾動更新 是 Kubernetes 提供的一種應用更新策略，允許我們在不中斷服務的情況下逐步更新應用的 Pod。這樣的更新方式確保了應用在更新過程中的可用性，並且只會在新的 Pod 正常運行後才替換舊的 Pod。滾動更新的主要好處包括：

1. 不中斷服務：在更新過程中，新的 Pod 啟動後才逐步替換舊的 Pod，確保應用的可用性。
2. 可控更新速率：可以設定每次更新的 Pod 數量，與最大不可用和最小可用的 Pod 數。
3. 容錯機制：如果在更新過程中出現問題，更新會自動停止，避免系統完全失效。

圖片來源

如何做到滾動更新(Rolling Update)？

編寫 Deployment 配置檔

首先，我們需要定義一個 Kubernetes Deployment 配置，並指定滾動更新的策略。以下是一個帶有滾動更新策略的 Deployment 範例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myregistry.azurecr.io/myapp:v1
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # 在更新期間允許不可用的最大 Pod 數
      maxSurge: 1        # 在更新期間允許的最大 Pod 數量增長

在這個配置中，我們設置了滾動更新策略：

• maxUnavailable：定義在更新過程中允許最多有幾個 Pod 不可用。這裡設置為 1，表示最多只能有一個 Pod 在更新期間處於不可用狀態。
• maxSurge：定義更新期間允許的最大 Pod 數量增長。這裡也設置為 1，表示更新期間最多多出一個 Pod。

應用滾動更新

當我們需要更新應用的版本時，可以修改 Deployment 配置中的映像(Image)，並重新套用配置：

spec:
  containers:
  - name: myapp-container
    image: myregistry.azurecr.io/myapp:v2  # 更新映像版本為 v2

更新後，我們可以使用以下命令應用更改：

kubectl apply -f deployment.yaml

此時，Kubernetes 將按照滾動更新的策略逐步替換現有的 Pod，並確保應用的可用性。

查看滾動更新的進度

我們可以使用以下命令來查看滾動更新的進度：

kubectl rollout status deployment/myapp-deployment

這條命令將顯示佈署的更新狀態，讓我們了解新的 Pod 是否已經成功運行，以及更新過程中是否遇到問題。

如何做到回復(Rollback)？

在某些情況下，應用更新後可能會出現問題。此時，Kubernetes 提供了**回復(Rollback)**功能，讓我們能夠快速回到先前的版本，確保應用恢復穩定。

執行回復命令

當我們發現應用更新出現問題時，可以使用以下命令快速回復到上一個穩定版本：

kubectl rollout undo deployment/myapp-deployment

這條命令將自動將應用恢復到上一個版本。

查看回復狀態

在執行回復後，可以使用以下命令來確認回復是否成功：

kubectl rollout status deployment/myapp-deployment

這條命令將顯示回復過程的進度與狀態，確保應用已恢復到預期的穩定狀態。

使用情境

滾動更新 (Rolling Update)

1. 平滑更新
   • 當應用程式需要升級版本或佈署新功能時，滾動更新能確保系統在不中斷服務的情況下完成更新。這在線上服務或關鍵系統中尤為重要，因為應用的可用性對使用者來說非常重要，若要停機才能進行更新，服務中斷造成的影響重大。
   • 情境：一個持續提供 API 服務的應用，需要升級其 API 結構，但不希望在更新期間中斷使用者的請求。
2. 佈署新版本的應用或修復 Bug
   • 當應用中發現問題需要迅速修正時，滾動更新能確保修正程序被逐步應用，並在新版本 Pod 正常運行後才替換舊版本，避免將未經驗證的版本一次性佈署至所有節點。
   • 情境：一個存在安全漏洞的應用，需要緊急佈署已修復的版本，但系統必須保持可用，因此透過滾動更新來替換受影響的 Pod。
3. 控制更新速率與影響範圍
   • 透過滾動更新的 maxUnavailable 與 maxSurge 參數，可以靈活控制更新過程中允許的不可用 Pod 數量，這對於高流量應用尤為重要，可以將影響降到最低。
   • 情境：一家電子商務平台的應用在大促銷期間需要升級，系統流量高峰時，需確保更新對用戶的影響最小。

回復 (Rollback)

1. 更新失敗
   • 在進行應用更新後，發現新的版本導致系統故障或性能問題，此時可以通過回復快速恢復到上一個穩定版本，確保業務不受影響。
   • 情境：佈署新版本後發現應用錯誤，導致系統崩潰或流量無法正常處理，這時可以立即回復到上一個版本。
2. 應用 Bug 或相容性問題
   • 當新版本佈署後發現存在與其他服務的相容性問題或 Bug，這時可以選擇回復至先前版本，並重新分析問題原因。
   • 情境：新功能上線後，與依賴的外部服務或內部模組不相容，導致應用無法正常工作，回復是最簡單且快速的解決方案。
3. 避免影響用戶體驗
   • 當新的應用版本影響到用戶體驗，例如性能下降、頁面加載時間變長等，為了確保用戶體驗不受影響，選擇快速回復到上一版本是最安全的做法。
   • 情境：升級後，應用性能明顯下降，用戶反映使用體驗變差，為了迅速恢復服務質量，可以選擇回復至上一版本。

滾動更新與回復的結合

• 漸進式更新策略 (Canary Deployment)：先將新版本只佈署給部分用戶，並監控系統狀態。如果出現問題，可以及時回復，而不會影響到所有使用者。
• 階段性回復 (Phased Rollback)：當發現更新中只有部分節點出現問題時，可以針對特定節點或 Pod 進行回復，控制影響範圍。

結語

今天我們深入探討了 Kubernetes 中滾動更新與回復的策略。在 DevOps 團隊的日常操作中，何時選擇進行滾動更新或進行回復是非常重要的。如果應用需要不間斷地提供服務，那麼可選擇滾動更新；而當遇到嚴重問題且需要立即恢復服務時，回復則是最有效的應急方案。透過滾動更新和回復，DevOps 團隊可以確保應用更新過程中服務的穩定性，並在遇到問題時快速恢復到先前的穩定版本，避免長時間停機。這樣的更新策略極大地提升了應用的高可用性與可維護性，讓線上的應用能夠提供穩定的服務！

參考文件

• Kubernetes 滾動更新
• Kubernetes 回復機制
• Kubectl Commands