牧場主今日工作

身為負責任的數位牧場主，今天我們要建立完整的叢集升級指南！這不是紙上談兵的理論課，而是基於實戰經驗的實用指南。我們會深入分析升級的各種影響、建立有效的備份策略，並制定適合不同規模的升級流程。讓各位牧場主在面對升級時有明確的行動方案！

升級影響評估：你必須知道的事

升級後主要會造成的影響

1. YAML 格式變更
最典型的是 Ingress API 版本變更。系統會自動協助調整叢集內現有的服務，但你下一次部署時才會面對錯誤。這是個隱藏炸彈！

2. API Objects 被廢棄
像 PodSecurityPolicy 在 v1.25 被完全移除。原本依賴這些 objects 的服務會立即缺少部分功能，沒有緩衝期。

3. 重大架構變更

• v1.24 從 Docker 轉向 containerd
• cgroup v2 的改變
• 這些都是底層的重大變革

4. 第三方服務相容性
各種 Operator 透過 API Server 管理服務，如果升級後找不到該 API 端點，就會無法正常運作。這就是為什麼第三方服務對 Kubernetes 版本有嚴格相依性。

5. 資訊收集建議
推薦關注 GKE 網站的 API 相關變更，他們整理得很完整，會主動警示重要變化。各種變更需要自行蒐集資料準備。

為什麼要升級？

1. 資安漏洞修補 - 最重要的驅動因素
2. 優化現有功能 - 改善穩定性和效能
3. 推出新功能 - 解決現有問題的新方案

Rancher 平台升級相依性

升級相依性層級

OS 版本
├── Linux Kernel 版本
    ├── RKE2/K8s 版本
        ├── Rancher 版本  
            └── Components (Cilium CNI 等)

重要提醒：

• 一些 components 會限制 Linux kernel 版本（如 Cilium CNI）
• Kernel 版本與 OS 版本綁定，雖然可以獨立升級，但不建議
• 每層都有自己的升級時程，不能隨意跳版本

必備參考文件

升級前務必檢查相容性：

• Rancher Support Matrix
• RKE2 Support Matrix

升級前備份策略

備份重要性排序

1. ETCD 備份（最關鍵）

• Rancher 的 Custom Cluster 會自動備份 ETCD
• 備份檔會存在 master 節點上，也可以設定到其他位置
• 透過 Rancher UI：叢集管理 → Snapshots → Take Snapshot

2. Rancher 備份

• 可以備份到 NFS 或 S3
• 透過 Rancher UI：Apps → 安裝 Rancher Backup Chart
• 建立備份：Backup & Restore → Create Backup

3. Control Plane 節點備份
建議直接對 Control Plane 節點做機器快照，避免系統損壞後修不好。根據你的虛擬化平台操作。

4. PVC 備份
可以考慮，但通常沒必要，除非有重要資料。

5. 整個叢集備份
成本很高，看風險承受程度決定。

6. Worker 節點備份
不建議備份。Worker 節點應該設計為可以隨時被替換，如果出問題就把服務搬走後重建節點。

升級方法指南

OS 升級

執行 OS 的原地升級步驟，但建立新節點來替換舊的更好。現實考量可能包括 IP 綁定等問題。

RKE2 升級

Custom Cluster：

• Rancher 有自動升級功能，但過程可能卡住
• 需要檢查錯誤原因：
  • journalctl -xef -u rke2-server 查看 rke2-server 日誌
  • journalctl -xef -u rancher-system-agent 查看 agent 日誌
• drain 節點時卡住：把踢不走的 Pod 強制刪除

Import 的 Clusters：

• 公有雲有自己的升級流程
• RKE2 叢集需要到各節點手動替換 rke2-server/agent

Rancher 升級

使用 helm upgrade 指令升級 Rancher。

Kernel 升級

盡量避免，風險較高。

升級執行流程

升級前準備工作

1. 通知使用者（絕對必須）
不通知就升級，發現服務掛掉怎麼辦？升級過程也可能造成服務斷線。

2. 要求使用者預先處理
請他們先修改各種 deprecated API、YAML、Objects，避免升級後才發現問題。

升級執行策略

少量節點環境：

1. 升級叢集前，先 drain 節點
2. 確保有設定：
   • PodAntiAffinity
   • Replicas 數量 > 一次升級的節點數量
   • 在 Replicas > 1 時設定 PDB (PodDisruptionBudget)
3. 這樣就不會受到太大影響

大量節點環境（上百台）：
不可能手動處理，這樣維護窗口要多長？所以服務設計必須能承受自動化升級，這點非常重要。

升級後驗證

1. 功能測試 - 確認各項服務運作正常
2. 問題排查 - 檢查是否有異常狀況
3. 備份清理 - 確認無誤後考慮是否刪除備份

相容性檢查工具

kubent 工具使用

kubent (Kubernetes No Trouble) 可以快速找出現有平台是否使用即將被廢棄的 objects 與 API。

限制：

• 只能檢查你直接部署的資源
• 第三方服務對 API Server 的存取需要自己分析 API Server log
• GKE 會自動整理這些資訊並在頁面警示，很方便

檢查方法

升級前務必執行 kubent 掃描，找出需要修改的資源：

# 安裝 kubent
curl -L "https://github.com/doitintl/kube-no-trouble/releases/latest/download/kubent-$(uname -s)-amd64.tar.gz" | tar xz

# 執行檢查
./kubent

會列出即將在新版本中被移除的 API 和 objects。

不同規模的升級策略

小規模叢集（< 10 節點）

• 手動逐一處理每個節點
• 仔細 drain 和驗證每個步驟
• 可以承受較長的維護窗口

中規模叢集（10-50 節點）

• 批次處理節點升級
• 平衡手動控制與自動化
• 需要更精確的時間規劃

大規模叢集（> 100 節點）

• 必須自動化處理
• 服務架構必須支援 rolling upgrade
• 維護窗口限制迫使架構改進

核心觀念：叢集規模決定升級策略，而升級策略反過來影響服務架構設計。

常見問題與解決方案

Drain 節點卡住

某些 Pod 可能無法正常搬移，需要：

1. 檢查 Pod 的 PodDisruptionBudget 設定
2. 確認是否有 local storage 綁定
3. 必要時強制刪除頑固的 Pod

升級後服務異常

1. 檢查 API 版本相容性
2. 確認 Operator 版本支援
3. 查看事件日誌找出問題根因

回滾策略

1. 從 ETCD 備份恢復
2. 節點快照還原
3. 重新部署舊版本應用

今日總結與明日預告

今天我們建立了完整的叢集升級與備份指南，涵蓋影響評估、備份策略、升級流程到常見問題解決。這些都是基於實際運維經驗的實用指導。

今日重點：

• ✅ 全面的升級影響分析與準備工作
• ✅ 分層級的備份策略與執行方法
• ✅ 不同規模環境的升級策略
• ✅ 實用的工具與檢查方法
• ✅ 常見問題的解決方案

明天我們將學習 Day 29：故障排除與診斷工具箱 - 牧場主的急救包！深入各種診斷技巧和故障排除方法，建立完整的問題解決能力。

💡 牧場主小提示：升級不是技術操作，而是風險管理。充分的準備工作比技術技巧更重要。記住：最好的升級是讓使用者感覺不到升級正在進行。做好規劃、分批執行、隨時準備回滾，這就是專業牧場主的升級之道！