KubeClipper 1.5.0 發布實戰：地端多集群管理工具補上工作負載 UI、追上 K8s 1.35

地端要管多套 K8s 集群有兩條老路：一條是把 Rancher 整套搬上來，吃資源、吃學習曲線；另一條是 kubeadm + kubespray + 自寫 Ansible，有彈性但每次升級都像在拆炸彈。中間有沒有「不複雜、能多集群、有 Web UI、能離線部署」的選擇？這就是 KubeClipper 想填的縫。

KubeClipper 是 CNCF 沙盒等級的輕量化 K8s 多集群全生命週期管理工具，2026-03 釋出 1.5.0，這一版補了過去最常被抱怨的兩塊：沒有工作負載 UI、版本支援老。下面拆解 1.5.0 的更新重點、5 分鐘快速試裝步驟，以及選 KubeClipper 之前該先想清楚的事情。

一、KubeClipper 是什麼，為什麼值得關注

KubeClipper 把自己定位在「比 kubeadm 友善、比 Rancher 輕」的位置。和常見的 K8s 安裝/管理工具相比：

關鍵差異是「離線部署友善」。對台灣很多政府/金融/製造業內網環境，外網連不出去是常態，KubeClipper 直接把離線當作一級公民支援，這點比 Rancher 在內網場景順手很多。

它的核心元件分兩塊：kc-server（管控面，提供 API + Web UI）+ kc-agent（裝在每個目標節點上）。集群建立流程是 server 透過 agent 在節點上跑 step pipeline（installRuntime → nodeEnvSetup → installPackages → initControlPlane → cniImageLoader → ...），可即時查每一步的 log。

二、1.5.0 四大重點更新

2.1 工作負載 UI（最大亮點）

過去版本只能管「集群本身」，要看 Pod / Deployment / StatefulSet 還是得 kubectl。1.5.0 在 Web UI 加了完整的工作負載介面，支援：

• Workload 管理：Deployment / StatefulSet / DaemonSet 的建立、編輯、擴縮容、滾動更新
• 狀態檢視：Pod 即時狀態、事件日誌、容器 stdout
• 快速操作：重啟、回滾到上一版、刪除

對「會 kubectl 但維運單位裡有不會 K8s 的同事」是大利多——以前還要包一層 Argo CD 或 Lens 給他們，現在一個 Web UI 解決。

2.2 追上 K8s 1.35

組件版本同步升級：

K8s 1.35 帶來的能力（如新版本的 in-place pod resize、structured authorization config）終於能用了。Go 從 1.19 跳到 1.23 也意味著 KubeClipper 自身收編了過去 4 年的安全 patch。

2.3 證書有效期延長到 10 年

K8s 預設證書 1 年到期，標準 kubeadm 集群每年都要 kubeadm certs renew 一次，忘了續期就直接整個集群失聯。1.5.0 把這個改成 10 年，等同你部完直接用到下次集群換代。對 lab / 內部測試環境很實用，生產環境還是建議自己評估安全策略，10 年放著不換不見得是對的。

2.4 安全 & 穩定性收尾

零碎但實用的修補：

• CRI registry 認證：私有 registry 帶帳密 pull image，過去要手動 patch containerd config，現在 UI 直接設
• 競態條件修復：多節點併行加入時的 race condition
• systemctl 工具類：統一容器運行時和 kubelet 的服務管理邏輯
• 節點健康檢查改用 kube clientset：取代過去的 process probe，更接近 K8s 原生語意

三、5 分鐘快速上手

3.1 環境需求

3.2 安裝 kcctl

# 國內鏡像（推薦台灣使用，從阿里雲拉，比較快）
curl -sfL https://oss.kubeclipper.io/get-kubeclipper.sh | KC_REGION=cn bash -

# 驗證
kcctl version

正常會輸出類似：

kcctl version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.0",
  GitCommit:"0930af19...", BuildDate:"2026-02-26T05:25:31Z",
  GoVersion:"go1.23.0", Compiler:"gc", Platform:"linux/amd64"}

3.3 部署 KubeClipper（aio 單機模式）

# 全 in one：server + agent 都裝在當前節點
kcctl deploy

aio 模式拉完離線包大約 1 分鐘。要多節點分離部署：

kcctl deploy \
  --server $IP_SERVER \
  --agent $IP_AGENT1,$IP_AGENT2 \
  --pk-file ~/.ssh/id_rsa \
  --pkg /path/to/offline.tgz \
  --ip-detect=interface=ens3 \
  --v 5

--pkg 指定離線包路徑，這就是內網環境的關鍵——預先把 tgz 拷進去，後面整個流程不需要外網。

3.4 建立第一個 K8s 集群

# 看可用節點
kcctl get node

# 建一個叫 demo 的集群（單 master，--untaint-master 讓 master 也能跑 workload）
kcctl create cluster --name demo \
  --master 172.16.131.134 \
  --untaint-master

預設行為：

• containerd 1.7.29
• Calico v3.29.6
• K8s v1.35.0

兩分鐘左右 Status 從 Installing 跳到 Running，就能 kubectl get nodes 了。即時看每一步在做什麼：

kcctl logs $OPERATION_ID --summary --follow

輸出長這樣：

===== Step: [2026-03-02 06:33:45] installRuntime [successful] [4s]
===== Step: [2026-03-02 06:33:49] nodeEnvSetup [successful] [1s]
===== Step: [2026-03-02 06:33:49] installExtension [successful] [34s]
===== Step: [2026-03-02 06:34:23] installPackages [successful] [41s]
===== Step: [2026-03-02 06:35:04] renderKubeadmConfig [successful] [1s]
===== Step: [2026-03-02 06:35:04] initControlPlane [successful] [14s]
===== Step: [2026-03-02 06:35:18] cniImageLoader [successful] [44s]
...

每一步都是獨立 step，錯了可以單獨重跑，比 kubespray 整套 Ansible 重來方便。

3.5 訪問 Web UI

部署完 http://$KC_SERVER_IP 直接打開，預設帳密 admin / Thinkbig1——這組密碼有點太弱，第一件事就是改掉，順便建一個專用維運帳號。

四、工作負載 UI 實測（從文件推斷）

依照官方 release note 描述，工作負載介面分三塊：

對日常維運來說，常見三件事可以脫離 kubectl：

1. 臨時擴一倍 replica 撐流量：UI 滑桿拉高 → 套用，幾秒內生效
2. 看為什麼 Pod CrashLoopBackOff：UI 點 Pod → events tab 看完整事件鏈，不用 kubectl describe
3. 回滾錯版本的 deployment：UI 點回滾 → 選版本，不用記 kubectl rollout undo 語法

要強調一點：這不是 Argo CD 的替代品。它沒做 GitOps、沒做應用發佈策略；定位上比較像「一個內建 dashboard」。如果你的團隊用 Argo CD/Flux 走 GitOps，KubeClipper 的 UI 是給維運臨時排錯用，發佈流程不該變動。

五、踩雷與該注意的事

從官方文件 + 常見 K8s 多集群部署經驗，以下幾點要在上線前想清楚：

1. 預設密碼一定要改：admin/Thinkbig1 不能保留，UI 第一次登入後立刻換
2. 離線包要自己備份：1.5.0 預設從阿里雲拉，從台灣連阿里雲偶爾會慢/不通；裝完之後把 /var/lib/kubeclipper/ 底下的離線 tgz 備份起來，避免下次重裝又要重抓
3. 單 master 不是高可用：--master 只給一個 IP 是 lab 配置，正式環境要 3 master + 外部 LB（haproxy / kube-vip），這部分 KubeClipper 不會自動幫你做
4. 證書 10 年要看清楚：是 K8s 內部簽的證書（apiserver、kubelet 等），不是對外 ingress TLS 證書；對外證書還是要走 cert-manager
5. kc-server 本身的備份：metadata 存在 server 節點的 etcd 或 sqlite，單 server 掛了 → 集群清單沒了（K8s 本身還活著，只是 KubeClipper 看不到了）；正式部署要 server 也做高可用或定期備份
6. kcctl 和 UI 的差異：有些參數 UI 沒暴露（例如 --ip-detect=interface=ens3 這類），多網卡環境一律 kcctl 部署比較安全

六、什麼情況該用、什麼情況不該用

適合的場景：

• 地端多集群：同公司多個機房或多個業務線各自一套 K8s，需要統一檢視
• 離線/內網環境：政府、金融、製造業；對外網有嚴格管控
• 混合式維運團隊：既有寫 IaC 的 SRE，也有純維運的同事；後者需要 UI
• 小型 PoC / lab：5 分鐘起一個集群跑驗證，比 minikube 真實，比 kubespray 快

不太適合的場景：

• 純公有雲（AWS EKS / GCP GKE / Azure AKS）：那些 Managed K8s 已經有自己的 console，KubeClipper 是多餘的
• 追求 GitOps 全自動化：用 Argo CD + Crossplane 直接接 cloud provider 比較對口
• 超大規模（100+ 集群）：這個量級要看 Cluster API + Karmada 之類的 fleet 管理，KubeClipper 的定位偏中小規模

七、與相近工具的對比

簡單說：地端 + 離線 + 中小規模 三點全中就選 KubeClipper；只要其中一項不成立，就回頭評估其他工具。

八、小結

KubeClipper 1.5.0 補上工作負載 UI 之後，從「集群安裝工具」進化到「集群管理工具」，這對地端多集群場景是合理且必要的演進。Go 1.23 + K8s 1.35 + 證書 10 年三件套，也讓它在維運成本上更有競爭力。

但要注意它不是萬用解——在公有雲、超大規模、純 GitOps 場景都不是首選。它最強的場景就是台灣很多公司會碰到的「地端多套 K8s + 離線環境 + 維運團隊技術光譜廣」這種狀況，這時候 KubeClipper 提供的「低門檻、能多集群、能離線」三角剛好補了 Rancher 太重、kubespray 太硬的縫。

建議的流程：先在 lab 跑 aio 單機模式試一輪 → 驗證工作負載 UI 是否符合維運同事的期待 → 再評估要不要拉到正式環境。

參考資料

• KubeClipper 官方網站
• KubeClipper GitHub
• KubeClipper 1.5.0 Release（CNCF 公眾號原文）
• Kubernetes 1.35 Release Notes
• Calico v3.29 Release Notes