前言

還記得 Day 01 我們用 kubeadm 建立了 Kubernetes v1.34 叢集嗎？

當時特別保留了一個 minor version 的升級空間，就是為了在系列最後實際走一次 Kubernetes 的升級流程。

Kubernetes 大約每年會釋出三個 minor version，因此叢集版本也需要持續維護。

當某個版本進入 EOL 之後，就不再獲得官方的 Security Update 與 Bug Fix。因此，叢集升級不是單純為了追求新功能，更重要的是維持安全性、穩定性與版本支援。

今天我們會使用 kubeadm，將目前的 Kubernetes v1.34 叢集升級到 v1.35，完整走過 Control Plane 與 Worker Node 的升級流程。

今天內容涵蓋：

1. 升級前你必須知道的事 — 先確認版本、升級順序與叢集健康狀態
2. 升級 Control Plane Node — 使用 kubeadm 升級 Control Plane 與 kubelet
3. 升級 Worker 節點 — Drain 後逐一升級每台 Worker Node
4. 升級流程全覽 — 用流程圖整理整個 kubeadm 升級順序
5. 升級常見問題 — 整理 drain、kubelet、CNI 與版本相關問題

本篇延續 Day 01 的環境（1 Master + 2 Worker，Debian，v1.34.0），升級目標為 v1.35.0。

一、升級前你必須知道的事

升級順序

⚠️ 升級順序要先 Control Plane，再 Worker

kubeadm 升級時，應先升級 Control Plane Node，再逐一升級 Worker Node。

其中 kubelet 的版本不應高於 kube-apiserver，否則會超出 Kubernetes 支援的版本偏差範圍。

版本跨度限制

• kubeadm 一次只能升級 一個 minor version
• 例如：
  • v1.34 → v1.35 ✅
  • v1.34 → v1.36 ❌
• 如果需要跨多個 minor version，必須逐版升級

升級前檢查清單

升級前先確認目前叢集狀態：

• 確認目前 Kubernetes 與 kubeadm 版本
• 閱讀目標版本的 Release Notes 與 Changelog
• 注意 Deprecated API、Breaking Change 與元件相容性
• 備份 etcd（生產環境尤其重要）
• 確認所有 Node 狀態正常
• 確認 kube-system 內的重要 Pod 正常運行

# 確認目前版本
kubectl version
kubeadm version

# 確認所有 Node 狀態
kubectl get nodes

# 確認系統 Pod
kubectl get pods -n kube-system

二、升級 Control Plane Node

執行節點：僅在 master 上執行

Step 1：切換 apt Repository 到 v1.35

Day 01 使用的是 Kubernetes v1.34 Repository，現在要把套件來源切換到 v1.35：

# 更新 GPG 金鑰
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# 更新 Repository
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list

# 更新套件索引
sudo apt-get update

Step 2：升級 kubeadm

先解除 kubeadm 的版本鎖定：

sudo apt-mark unhold kubeadm

查看目前 Repository 中可以安裝的版本：

apt-cache madison kubeadm

確認目標版本後再安裝：

sudo apt-get install -y kubeadm=1.35.0-1.1

重新鎖定 kubeadm：

sudo apt-mark hold kubeadm

最後確認版本：

kubeadm version

應該會看到：

GitVersion:"v1.35.0"

💡 本篇先將 kubeadm 升級到 v1.35.0。同一個 v1.35 minor version 之後仍可能有更新的 Patch Release，實際可用版本請以 apt-cache madison kubeadm 與後續的 kubeadm upgrade plan 結果為準。

Step 3：確認升級計畫

在真正修改 Control Plane 之前，先讓 kubeadm 檢查目前叢集是否符合升級條件：

sudo kubeadm upgrade plan

💡 kubeadm upgrade plan 做了什麼？

它會檢查目前叢集狀態，並列出：

• 可以升級的 Kubernetes 版本
• Control Plane 元件的目前版本與目標版本
• kubelet 等需要後續手動升級的元件
• 升級前需要處理的問題

upgrade plan 只會進行檢查，不會真正修改叢集。

你應該會看到類似下面的結果：

從這次輸出可以看到，目前 v1.35 系列可用的升級目標已經到：

v1.35.2

💡 為什麼前面 kubeadm 是 v1.35.0，這裡卻顯示 v1.35.2？

v1.35.0 和 v1.35.2 都屬於 Kubernetes v1.35 minor version，只是 Patch Version 不同。

kubeadm upgrade plan 會依目前可用的版本資訊，顯示同一個 minor version 中可升級的 Patch Version。

因此看到 v1.35.2 並不代表前面的 v1.35.0 安裝有問題，而是代表 v1.35 系列已經有更新的 Patch Release 可用。

⚠️ 遇到 CoreDNS Migration 檢查錯誤

如果出現：

[ERROR CoreDNSUnsupportedPlugins]
[ERROR CoreDNSMigration]

代表 kubeadm 無法正常完成 CoreDNS 的升級相容性檢查。

建議先確認目前的 CoreDNS Image 與 Corefile 設定，而不是直接忽略錯誤。

如果只是 Lab 環境，並且已經了解可能的影響，可以將指定的 Preflight Error 降為 Warning：

sudo kubeadm upgrade plan \
  --ignore-preflight-errors=CoreDNSUnsupportedPlugins,CoreDNSMigration

後續執行 kubeadm upgrade apply 時，如果仍出現相同檢查，也需要加入相同參數。

Step 4：執行升級

確認升級計畫沒有問題後，就可以正式升級 Control Plane。

如果 Step 3 沒有遇到 CoreDNS 相關錯誤：

sudo kubeadm upgrade apply v1.35.0

如果前面的 upgrade plan 因 CoreDNS Migration 檢查失敗，而你已經確認要在 Lab 環境中略過：

sudo kubeadm upgrade apply v1.35.0 \
  --ignore-preflight-errors=CoreDNSUnsupportedPlugins,CoreDNSMigration

⚠️ Preflight 設定要保持一致

kubeadm upgrade apply 也會再次執行升級前檢查。

如果 Step 3 是使用 --ignore-preflight-errors 才通過，這裡也需要帶上相同的參數。

執行後，kubeadm 會升級 Control Plane 相關元件，例如：

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kube-proxy
• CoreDNS（如果此次升級包含對應版本更新）
• etcd（如果升級計畫包含 etcd 版本更新）

💡 升級過程中會發生什麼？

kubeadm 會更新 Control Plane 的設定與 Static Pod Manifest。

當 /etc/kubernetes/manifests/ 中的檔案發生變化後，kubelet 會偵測並重新建立對應的 Control Plane Pod。

看到類似下面的訊息：

[upgrade] SUCCESS! A control plane node of your cluster was upgraded to "v1.35.0".

就代表這台 Control Plane Node 已成功完成升級。

💡 本篇實作與截圖固定使用 v1.35.0。前一步 kubeadm upgrade plan 顯示的 v1.35.2，代表同一個 v1.35 minor version 中已有較新的 Patch Release 可用。

Step 5：升級 kubelet 和 kubectl

⚠️ 注意

kubeadm upgrade apply 會升級 Control Plane 相關元件，但 kubelet 和 kubectl 仍需要另外升級。

先解除版本鎖定：

sudo apt-mark unhold kubelet kubectl

升級到 v1.35.0：

sudo apt-get install -y \
  kubelet=1.35.0-1.1 \
  kubectl=1.35.0-1.1

重新鎖定版本：

sudo apt-mark hold kubelet kubectl

重新載入 systemd 設定並重啟 kubelet：

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Step 6：驗證 Control Plane Node

先確認 Node 版本：

kubectl get nodes

再確認 kube-system 內的 Pod 是否正常：

kubectl get pods -n kube-system

此時應該會看到：

這是正常的。

目前只有 Control Plane Node 完成升級，Worker Node 還維持在 v1.34.0，接下來再逐一升級 Worker Node。

三、升級 Worker 節點

⚙️ 執行方式：逐一升級每個 Worker Node

Worker Node 的升級流程需要在 Control Plane Node 與 Worker Node 之間交替操作，請注意每個步驟的執行位置。

每個 Worker Node 重複以下流程（以 node1 為例）

Step 7：排空節點（在 Control Plane Node 上執行）

# 在 master 上執行
kubectl drain node1 \
  --ignore-daemonsets \
  --delete-emptydir-data

💡 kubectl drain 做了什麼？

1. 將 Node 標記為 SchedulingDisabled，避免新的 Pod 被排程到這台 Node
2. 驅逐可以被驅逐的 Pod
3. 由 Deployment、ReplicaSet、StatefulSet 等 Controller 管理的工作負載，會依照期望狀態在其他可用 Node 上重新建立

參數說明：

• --ignore-daemonsets：略過 DaemonSet 管理的 Pod，例如 calico-node、kube-proxy
• --delete-emptydir-data：允許刪除使用 emptyDir 的 Pod；其中的暫存資料會一起消失

確認 node1 已停止接收新的 Pod：

kubectl get nodes

此時 node1 應該會顯示：

Step 8：升級 kubeadm（在 Worker Node 上執行）

SSH 到 node1 後，先把 Kubernetes Package Repository 切換到 v1.35：

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update

接著升級 kubeadm：

sudo apt-mark unhold kubeadm
sudo apt-get install -y kubeadm=1.35.0-1.1
sudo apt-mark hold kubeadm

Step 9：升級節點設定（在 Worker Node 上執行）

在 node1 上執行：

sudo kubeadm upgrade node

💡 upgrade apply 和 upgrade node 有什麼差別？

• kubeadm upgrade apply：用於第一台 Control Plane Node，負責升級整個叢集的 Control Plane 設定與相關元件
• kubeadm upgrade node：用於其他節點

對 Worker Node 來說，kubeadm upgrade node 主要會讀取叢集設定，並更新這台 Node 的 kubelet configuration。

如果是在額外的 Control Plane Node 上執行，則還會更新該節點的 Control Plane Static Pod Manifest。

Step 10：升級 kubelet 和 kubectl（在 Worker Node 上執行）

解除版本鎖定：

sudo apt-mark unhold kubelet kubectl

升級 kubelet 和 kubectl：

sudo apt-get install -y \
  kubelet=1.35.0-1.1 \
  kubectl=1.35.0-1.1

重新鎖定版本：

sudo apt-mark hold kubelet kubectl

重新載入 systemd 並重啟 kubelet：

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Step 11：恢復節點排程（在 Control Plane Node 上執行）

在 master 上執行，讓 node1 重新接受 Pod 排程：

kubectl uncordon node1

接著確認節點狀態與版本：

kubectl get nodes

node1 的 VERSION 應該已經變成 v1.35.0，STATUS 則恢復為 Ready。

接著對 node2 重複 Step 7～11，直到所有 Worker Node 都完成升級。

四、升級流程全覽

五、升級常見問題

⚠️ 如果遇到 CoreDNSUnsupportedPlugins 或 CoreDNSMigration，建議先確認 CoreDNS Image 與 Corefile 設定。只有在 Lab 環境、且已了解影響時，再考慮使用 --ignore-preflight-errors。

小結

今天完成了 Kubernetes 叢集從 v1.34 升級到 v1.35 的完整流程，回顧幾個重點：

💡 實務小提醒

在生產環境中，升級前應先備份 etcd、確認 PodDisruptionBudget 與工作負載副本配置，並盡量安排在低流量時段執行。

如果是多 Control Plane 的 HA 架構，第一台 Control Plane 使用 kubeadm upgrade apply，其餘 Control Plane Node 則使用 kubeadm upgrade node。

參考資源

• Kubernetes 官方文件 — 升級 kubeadm 叢集
• Kubernetes 版本偏差政策
• Kubernetes Release Notes
• kubeadm upgrade 指令參考