作者：尹珉，KubeSphere Ambaasador&Contributor，KubeSphere 社區用戶委員會杭州站站長。
引言
隨着 Kubernetes 社區的不斷髮展，即將迎來 Kubernetes 1.30 版本的迭代。在早先的 1.24 版本中，社區作出一個重要決策：不再默認集成 Docker 作爲容器運行時，即取消了對 Docker 的默認支持。這就像咱們家廚房換了個新竈頭，雖然廚藝的本質沒變，但用起來感覺肯定不一樣。這篇文章就帶你摸透這個變化，直擊 Kubernetes 1.24+ 版本拋棄 Docker 後的影響，同時手把手教你如何藉助 KubeKey 這個神器，讓你在給 Kubernetes “裝修升級”的過程中既穩又順，還能把 Docker 那些貼心好用的功能保留下來。
Docker 移除帶來的潛在風險分析
工具鏈與生態兼容性
- 對於大量使用 Jenkins 等 CI/CD 工具的企業而言，原先基於 Docker 的鏡像構建、推送和拉取流程可能需要重構。Jenkinsfile 中的 Docker 構建步驟需調整爲兼容 containerd 的方式進行，否則可能造成流水線中斷。
- 監控系統和其他依賴於 Docker API 的周邊工具需要進行改造或更換，以適應新的容器運行時環境，這涉及到了大量的驗證工作和可能的二次開發成本。
開發環境一致性
開發者們習慣了在本地使用 Docker 進行快速迭代和測試，移除 Docker 後，需要重新適應 containerd 或尋找兼容 Docker API 的替代方案，以保持開發環境與生產環境的一致性。
現有運維腳本失效
許多自動化腳本、運維命令和 Helm Chart 等資源文件可能直接引用了 Docker 命令或依賴於 Docker 的特定行爲，這些都需要逐步審查和適配。
升集羣時手動保留 Docker 特性的成本分析
運維複雜度增加
- 需要在 Kubernetes 集羣中手動集成第三方插件或其他兼容方案以模擬 Docker 的運行時環境，這要求運維團隊具備更高的技術水平和對 Kubernetes 內部機制的深入瞭解。
- 需要密切關注 Kubernetes 更新與 Docker 兼容性之間的差異，每次升級 Kubernetes 都可能導致與 Docker 集成的部分出現問題，需要額外的時間和精力進行維護和調試。
集羣規模操作成本劇增
- 假設面臨如 100 個節點的集羣時，每個節點上的容器運行時切換都需要單獨進行，這意味着至少需要分別在 100 個節點上執行啓停容器運行時的操作，耗費巨大的人力和時間成本。
- 對於大型集羣，這種逐一操作的管理模式極其低效且容易出錯，可能需要編寫複雜的腳本或者使用批量管理工具，進一步增加實施難度。
測試驗證與恢復預案
若操作過程中遇到問題，需要有完備的回滾策略和恢復預案，準備應對可能發生的各類異常狀況，以防業務長時間受到影響。
總結： 因此，在 Kubernetes 1.24 之後，手動保留 Docker 特性並進行大規模節點運行時切換是一項極具挑戰的任務，不僅會導致高昂的操作成本，還可能帶來較大的業務風險。相比之下，尋求平滑過渡和兼容方案（如 KubeKey）成爲更具性價比的選擇。
什麼是 Kubekey
KubeKey 是一個開源的輕量級工具，用於部署 Kubernetes 集羣。它提供了一種靈活、快速、方便的方式來安裝 Kubernetes/K3s、Kubernetes/K3s 和 KubeSphere，以及相關的雲原生附加組件。它也是擴展和升級集羣的有效工具。此外，KubeKey 還支持定製離線包（artifact），方便用戶在離線環境下快速部署集羣。
爲什麼選擇 Kubekey？
KubeKey 由 Go 語言開發，使用便捷、輕量，支持多種主流 Linux 發行版。KubeKey 支持多種集羣部署模式，例如 All-in-One、多節點、高可用以及離線集羣部署。KubeKey 也支持支持快速構建離線安裝包，加速離線交付場景下的集羣交付效率。KubeKey 實現多節點並行安裝，且利用 Kubeadm 對集羣和節點進行初始化，極大地節省了集羣部署時間，同時也遵循了 Kubernetes 社區主流集羣部署方法。KubeKey 提供內置高可用模式，支持一鍵部署高可用 Kubernetes 集羣。
升級實操
etcd 數據備份
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
snapshot save <backup-file-location>
下載 Kubekey 工具
版本：v3.1.0-rc.2 （這個版本當前是穩定已測，即將發佈 v3.1.0）。
export KKZONE=cn
支持手動下載：https://github.com/kubesphere/kubekey/releases。
curl -sfL https://get-kk.kubesphere.io | sh -
檢查當前集羣狀態
kubectl get node -o wide
準備集羣配置文件
如果創建集羣時的配置文件存在，本步驟可跳過。
- 創建當前集羣配置
./kk create config [--with-kubernetes version] [(-f | --filename) path]
- 填入真實集羣信息
修改 configmap
- 修改 kubeadm-config
注意：確保配置中的 featuregate 在新版本中沒有被移除。
kubectl -n kube-system edit cm kubeadm-config
- 修改 kubelet-config-1.23
注意：確保配置中的 featuregate 在新版本中沒有被移除。
kubectl -n kube-system edit cm kubelet-config-1.23
開始升級
./kk upgrade -f sample.yaml --with-kubernetes v1.24.17 --skip-dependency-check
驗證集羣版本
kubectl get node -A -o wide
驗證容器運行時
kubectl get nodes -o json | jq '.items[].status.nodeInfo.containerRuntimeVersion'
結尾彩蛋
正如我們在這篇文章中所揭示的，Kubernetes 1.24 版本及其後續迭代雖逐步摒棄了對 Docker 的直接依賴，但這並不意味着我們必須捨棄熟悉的 Docker 工作流。通過 KubeKey 這樣的強大工具，我們可以享受到 Kubernetes 最新版本的種種改進，同時還能優雅地保留 Docker 的某些關鍵特性，讓升級之路變得更爲順暢。勇敢擁抱變化，善用工具的力量，每一次的技術升級都將成爲我們打造高效、穩定、可擴展基礎設施的寶貴經驗。
本文由博客一文多發平臺 OpenWrite 發佈！