引言

面試的時候問到了很多次，但是回答的不是很全面，盡管有時候面試官聽著還可以，但是自己知道回答還不夠全面，所以我們就深入了解下。

如果文章哪里有問題，還望指出。

最后有相關的學習群，有興趣可以加入。

開始

Kubernetes的部署方式決定了集群的底層架構、可維護性及擴展能力。二進制部署與kubeadm的差異遠不止于“手動vs自動”，而是涉及架構設計、生命周期管理、安全模型等多個維度。本文將從技術本質出發，結合企業真實場景，解析兩者的核心區別與選型策略。

一、技術本質與核心差異

1. 組件交互與啟動流程

二進制部署

? 核心機制：每個Kubernetes組件（如kube-apiserver、kubelet）以獨立進程運行，直接通過本地systemd或自定義腳本管理。

? 關鍵步驟：

1） 證書手動生成：使用cfssl或openssl手動創建CA、服務端/客戶端證書，需精確配置SAN（Subject Alternative Name）。

2）組件參數配置：

? kube-apiserver需顯式指定--etcd-servers、--service-cluster-ip-range。

? kubelet需配置--kubeconfig、--pod-infra-container-image（如pause容器）。

3）依賴服務部署：

? 獨立部署etcd集群（3節點或5節點），配置TLS雙向認證。

? 手動安裝CNI插件（如Calico的calicoctl與calico-node）。

? 典型問題：

1）證書過期需手動輪換，否則導致集群不可用。

2）組件啟動順序錯誤（如etcd未就緒時啟動kube-apiserver）會引發雪崩故障。

kubeadm部署

? 核心機制：kubeadm通過 Phases（階段化流程） 自動化完成集群初始化，隱藏底層細節。

? 關鍵步驟：

1. 證書自動生成：

? kubeadm init自動創建CA及各類證書（有效期1年），存儲于/etc/kubernetes/pki。

? 支持kubeadm certs renew自動續期。

2. 組件容器化：

? 控制平面組件（如kube-apiserver）以靜態Pod形式運行，由kubelet托管。

? 配置文件統一存儲在/etc/kubernetes/manifests。

3. 依賴服務集成：

? 默認使用kubeadm內置的etcd靜態Pod（可通過--external-etcd覆蓋）。

? 通過kubeadm init --pod-network-cidr自動配置CNI插件（如Flannel）。

? 典型問題：

1）默認證書有效期可能導致生產環境安全隱患。

2）對非標準CNI插件（如Cilium+BGP）支持需手動干預。

2. 高可用架構實現對比

二進制部署

? 負載均衡設計：

API Server高可用：需部署外部負載均衡器（如HAProxy + Keepalived），配置TCP健康檢查。

etcd集群：手動部署跨機房的3/5節點集群，配置--initial-cluster參數與TLS證書。

? 故障恢復：

節點故障時需手動替換證書和配置，復雜度高。

支持精細化調優（如etcd的--heartbeat-interval和--election-timeout）。

kubeadm部署

? 高可用模式：

控制平面：通過kubeadm init --control-plane-endpoint <LB_IP>指定負載均衡器，多個Master節點通過kubeadm join加入。

etcd集群：默認使用Stacked etcd（每個Master節點運行etcd Pod），或通過--external-etcd連接獨立集群。

? 局限性：

Stacked etcd模式下，網絡分區可能導致控制平面與etcd同時不可用。

負載均衡器配置需企業自行維護（如AWS ELB、Nginx Ingress Controller）。

3. 升級與維護差異

二進制部署

? 升級流程：

1）從GitHub下載新版本二進制文件（如kube-apiserver-v1.28.0）。

2）逐個節點替換舊版本，滾動重啟組件。

3）驗證API兼容性（如kubectl convert檢查資源版本）。

? 挑戰：

跨大版本升級（如1.24→1.26）需處理廢棄API（如PodSecurityPolicy）。

需手動備份etcd數據（etcdctl snapshot save）。

kubeadm部署

? 升級流程：

1）執行kubeadm upgrade plan檢查可升級版本。

2）kubeadm upgrade apply v1.28.0更新控制平面。

3）工作節點通過kubeadm upgrade node完成升級。

? 優勢：

1）自動處理證書續期與配置文件更新。

2）支持kubeadm reset快速回滾（需配合etcd備份）。

4. 安全模型對比

二、企業選型策略：場景驅動的決策框架

1. 選擇二進制部署的典型場景

? 場景1：超大規模集群（>1000節點）

? 需求：極致性能調優，如：

1）修改kube-apiserver的--max-requests-inflight參數應對高并發。

2）調整etcd的--snapshot-count優化寫入性能。

? 案例：某頭部電商在黑色星期五期間通過二進制部署優化API Server的QPS從5k提升至20k。

? 場景2：混合云/邊緣計算

? 需求：異構硬件支持，如：

在ARM邊緣節點上編譯定制版kubelet以節省資源。

為邊緣環境優化kube-proxy的iptables規則生成邏輯。

? 案例：某智慧工廠在邊緣網關部署輕量化Kubernetes，二進制包體積減少40%。

? 場景3：強合規與審計要求

? 需求：

使用國密算法（SM2/SM3）替換默認TLS證書。

將審計日志直接寫入自研SIEM系統，繞過Kubernetes審計功能。

案例：某金融機構通過二進制部署實現等保三級合規。

2. 選擇kubeadm的典型場景

? 場景1：快速原型驗證與CI/CD集成

需求：在Pipeline中自動創建測試集群，如：

kubeadm init --config=kubeadm-config.yaml && \
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

? 優勢：通過Ansible或Terraform封裝kubeadm，實現集群即代碼（IaC）。

? 場景2：標準化多集群管理

? 需求：統一管理多個云廠商的集群，如：

使用Cluster API在AWS/GCP/Azure批量創建kubeadm集群。

通過Rancher Fleet同步集群配置。

? 案例：某SaaS公司管理200+個kubeadm集群，平均部署時間<10分鐘。

? 場景3：有限運維資源的中小團隊

? 需求：降低學習曲線，如：

依賴kubeadm upgrade自動化處理版本升級。

使用kubeadm certs renew all簡化證書管理。

案例：某初創企業僅1名運維人員管理50節點生產集群。

3. 混合架構：平衡靈活性與效率

? 模式1：核心+邊緣分層部署

設計：

核心Master節點：二進制部署，優化etcd與API Server性能。

邊緣Worker節點：kubeadm部署，通過kubeadm join批量接入。

優勢：核心層保障穩定性，邊緣層快速擴展。

? 模式2：漸進式遷移

步驟：

1. 初期使用kubeadm快速上線業務。

2. 隨著規模增長，逐步替換關鍵組件（如將kubeadm的etcd遷移至獨立二進制集群）。

3. 最終完全過渡到二進制部署，保留kubeadm作為災備方案。

三、企業選型的7個關鍵考量維度

1. 團隊技能儲備

? 二進制部署要求團隊熟悉：

Kubernetes組件通信協議（如API Server的REST API、etcd的gRPC）。

操作系統級調優（如systemd的CPUAccounting和MemoryLimit）。

2. 基礎設施規模

? 小規模（<50節點）：kubeadm性價比最高。

? 中大規模（50-500節點）：需評估是否需要定制調度器或網絡插件。

? 超大規模（>500節點）：二進制部署幾乎成為必選項。

3. 合規與安全要求

? 金融、政務等行業通常需要二進制部署以滿足審計顆粒度要求。

4. 生命周期管理

? 頻繁集群創建/銷毀（如測試環境）優先選擇kubeadm。

5. 云生態集成

? 若深度依賴云廠商托管服務（如AWS EKS Anywhere），kubeadm更易集成。

6. 成本模型

? 二進制部署的隱性成本：

人力成本：資深Kubernetes運維工程師薪資通常比普通運維高30%-50%。

時間成本：手動升級一個50節點集群可能需要2人天。

7. 災備與可恢復性

? 二進制部署需自定義備份方案（如etcd快照+組件二進制版本庫）。

? kubeadm可結合Velero實現標準化災備。

四、實戰建議：企業落地步驟

步驟1：明確需求與約束

? 制作檢查清單：

[ ] 是否需要定制Kubernetes組件？  
[ ] 集群規模預期增長曲線如何？  
[ ] 團隊是否有能力維護證書輪換？  
[ ] 是否需通過等保/PCI-DSS認證？

步驟2：技術驗證（PoC）

? 二進制部署PoC重點：

? 測試跨版本升級（如1.26→1.27）的兼容性。

? 模擬etcd節點故障，驗證恢復流程。

? kubeadm PoC重點：

? 驗證與CNI插件的兼容性（如Cilium Hubble是否正常）。

? 測試kubeadm upgrade的穩定性。

步驟3：制定標準化流程

? 二進制部署規范：

使用Ansible Role固化組件啟動參數。

建立證書輪換日歷（如每90天更新一次）。

? kubeadm部署規范：

? 通過kubeadm config文件統一配置模板。

? 集成Arkade或kurl實現離線部署。

步驟4：監控與優化

? 關鍵監控指標：

二進制部署：關注kube-apiserver的goroutine泄漏、etcd寫入延遲。

kubeadm部署：監控kubelet的容器啟動延遲、證書過期時間。

? 優化案例：某企業通過二進制部署調優kube-controller-manager的--concurrent-deployment-syncs，將部署回滾時間從5分鐘縮短至30秒。

五、總結：沒有“最佳方案”，只有“最適方案”

? 二進制部署是“手術刀”，適合需要精細控制的企業，但要求團隊具備極強的手術能力。

? kubeadm部署是“瑞士軍刀”，開箱即用但難以應對極端場景。

最終建議：

? 從kubeadm起步，隨著業務復雜度提升逐步引入二進制組件。

? 無論選擇哪種方式，必須建立完善的可觀測性體系與混沌工程驗證流程。

企業應根據實際場景動態調整——技術選型的終極目標不是追求“純粹性”，而是讓基礎設施成為業務創新的堅實底座。