引言

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

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

最后有相關(guān)的學(xué)習(xí)群，有興趣可以加入。

開始

Kubernetes的部署方式?jīng)Q定了集群的底層架構(gòu)、可維護(hù)性及擴(kuò)展能力。二進(jìn)制部署與kubeadm的差異遠(yuǎn)不止于“手動(dòng)vs自動(dòng)”，而是涉及架構(gòu)設(shè)計(jì)、生命周期管理、安全模型等多個(gè)維度。本文將從技術(shù)本質(zhì)出發(fā)，結(jié)合企業(yè)真實(shí)場景，解析兩者的核心區(qū)別與選型策略。

一、技術(shù)本質(zhì)與核心差異

1. 組件交互與啟動(dòng)流程

二進(jìn)制部署

? 核心機(jī)制：每個(gè)Kubernetes組件（如kube-apiserver、kubelet）以獨(dú)立進(jìn)程運(yùn)行，直接通過本地systemd或自定義腳本管理。

? 關(guān)鍵步驟：

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

2）組件參數(shù)配置：

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

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

3）依賴服務(wù)部署：

? 獨(dú)立部署etcd集群（3節(jié)點(diǎn)或5節(jié)點(diǎn)），配置TLS雙向認(rèn)證。

? 手動(dòng)安裝CNI插件（如Calico的calicoctl與calico-node）。

? 典型問題：

1）證書過期需手動(dòng)輪換，否則導(dǎo)致集群不可用。

2）組件啟動(dòng)順序錯(cuò)誤（如etcd未就緒時(shí)啟動(dòng)kube-apiserver）會引發(fā)雪崩故障。

kubeadm部署

? 核心機(jī)制：kubeadm通過 Phases（階段化流程） 自動(dòng)化完成集群初始化，隱藏底層細(xì)節(jié)。

? 關(guān)鍵步驟：

1. 證書自動(dòng)生成：

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

? 支持kubeadm certs renew自動(dòng)續(xù)期。

2. 組件容器化：

? 控制平面組件（如kube-apiserver）以靜態(tài)Pod形式運(yùn)行，由kubelet托管。

? 配置文件統(tǒng)一存儲在/etc/kubernetes/manifests。

3. 依賴服務(wù)集成：

? 默認(rèn)使用kubeadm內(nèi)置的etcd靜態(tài)Pod（可通過--external-etcd覆蓋）。

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

? 典型問題：

1）默認(rèn)證書有效期可能導(dǎo)致生產(chǎn)環(huán)境安全隱患。

2）對非標(biāo)準(zhǔn)CNI插件（如Cilium+BGP）支持需手動(dòng)干預(yù)。

2. 高可用架構(gòu)實(shí)現(xiàn)對比

二進(jìn)制部署

? 負(fù)載均衡設(shè)計(jì)：

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

etcd集群：手動(dòng)部署跨機(jī)房的3/5節(jié)點(diǎn)集群，配置--initial-cluster參數(shù)與TLS證書。

? 故障恢復(fù)：

節(jié)點(diǎn)故障時(shí)需手動(dòng)替換證書和配置，復(fù)雜度高。

支持精細(xì)化調(diào)優(yōu)（如etcd的--heartbeat-interval和--election-timeout）。

kubeadm部署

? 高可用模式：

控制平面：通過kubeadm init --control-plane-endpoint <LB_IP>指定負(fù)載均衡器，多個(gè)Master節(jié)點(diǎn)通過kubeadm join加入。

etcd集群：默認(rèn)使用Stacked etcd（每個(gè)Master節(jié)點(diǎn)運(yùn)行etcd Pod），或通過--external-etcd連接獨(dú)立集群。

? 局限性：

Stacked etcd模式下，網(wǎng)絡(luò)分區(qū)可能導(dǎo)致控制平面與etcd同時(shí)不可用。

負(fù)載均衡器配置需企業(yè)自行維護(hù)（如AWS ELB、Nginx Ingress Controller）。

3. 升級與維護(hù)差異

二進(jìn)制部署

? 升級流程：

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

2）逐個(gè)節(jié)點(diǎn)替換舊版本，滾動(dòng)重啟組件。

3）驗(yàn)證API兼容性（如kubectl convert檢查資源版本）。

? 挑戰(zhàn)：

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

需手動(dòng)備份etcd數(shù)據(jù)（etcdctl snapshot save）。

kubeadm部署

? 升級流程：

1）執(zhí)行kubeadm upgrade plan檢查可升級版本。

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

3）工作節(jié)點(diǎn)通過kubeadm upgrade node完成升級。

? 優(yōu)勢：

1）自動(dòng)處理證書續(xù)期與配置文件更新。

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

4. 安全模型對比

二、企業(yè)選型策略：場景驅(qū)動(dòng)的決策框架

1. 選擇二進(jìn)制部署的典型場景

? 場景1：超大規(guī)模集群（>1000節(jié)點(diǎn)）

? 需求：極致性能調(diào)優(yōu)，如：

1）修改kube-apiserver的--max-requests-inflight參數(shù)應(yīng)對高并發(fā)。

2）調(diào)整etcd的--snapshot-count優(yōu)化寫入性能。

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

? 場景2：混合云/邊緣計(jì)算

? 需求：異構(gòu)硬件支持，如：

在ARM邊緣節(jié)點(diǎn)上編譯定制版kubelet以節(jié)省資源。

為邊緣環(huán)境優(yōu)化kube-proxy的iptables規(guī)則生成邏輯。

? 案例：某智慧工廠在邊緣網(wǎng)關(guān)部署輕量化Kubernetes，二進(jìn)制包體積減少40%。

? 場景3：強(qiáng)合規(guī)與審計(jì)要求

? 需求：

使用國密算法（SM2/SM3）替換默認(rèn)TLS證書。

將審計(jì)日志直接寫入自研SIEM系統(tǒng)，繞過Kubernetes審計(jì)功能。

案例：某金融機(jī)構(gòu)通過二進(jìn)制部署實(shí)現(xiàn)等保三級合規(guī)。

2. 選擇kubeadm的典型場景

? 場景1：快速原型驗(yàn)證與CI/CD集成

需求：在Pipeline中自動(dòng)創(chuàng)建測試集群，如：

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

? 優(yōu)勢：通過Ansible或Terraform封裝kubeadm，實(shí)現(xiàn)集群即代碼（IaC）。

? 場景2：標(biāo)準(zhǔn)化多集群管理

? 需求：統(tǒng)一管理多個(gè)云廠商的集群，如：

使用Cluster API在AWS/GCP/Azure批量創(chuàng)建kubeadm集群。

通過Rancher Fleet同步集群配置。

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

? 場景3：有限運(yùn)維資源的中小團(tuán)隊(duì)

? 需求：降低學(xué)習(xí)曲線，如：

依賴kubeadm upgrade自動(dòng)化處理版本升級。

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

案例：某初創(chuàng)企業(yè)僅1名運(yùn)維人員管理50節(jié)點(diǎn)生產(chǎn)集群。

3. 混合架構(gòu)：平衡靈活性與效率

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

設(shè)計(jì)：

核心Master節(jié)點(diǎn)：二進(jìn)制部署，優(yōu)化etcd與API Server性能。

邊緣Worker節(jié)點(diǎn)：kubeadm部署，通過kubeadm join批量接入。

優(yōu)勢：核心層保障穩(wěn)定性，邊緣層快速擴(kuò)展。

? 模式2：漸進(jìn)式遷移

步驟：

1. 初期使用kubeadm快速上線業(yè)務(wù)。

2. 隨著規(guī)模增長，逐步替換關(guān)鍵組件（如將kubeadm的etcd遷移至獨(dú)立二進(jìn)制集群）。

3. 最終完全過渡到二進(jìn)制部署，保留kubeadm作為災(zāi)備方案。

三、企業(yè)選型的7個(gè)關(guān)鍵考量維度

1. 團(tuán)隊(duì)技能儲備

? 二進(jìn)制部署要求團(tuán)隊(duì)熟悉：

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

操作系統(tǒng)級調(diào)優(yōu)（如systemd的CPUAccounting和MemoryLimit）。

2. 基礎(chǔ)設(shè)施規(guī)模

? 小規(guī)模（<50節(jié)點(diǎn)）：kubeadm性價(jià)比最高。

? 中大規(guī)模（50-500節(jié)點(diǎn)）：需評估是否需要定制調(diào)度器或網(wǎng)絡(luò)插件。

? 超大規(guī)模（>500節(jié)點(diǎn)）：二進(jìn)制部署幾乎成為必選項(xiàng)。

3. 合規(guī)與安全要求

? 金融、政務(wù)等行業(yè)通常需要二進(jìn)制部署以滿足審計(jì)顆粒度要求。

4. 生命周期管理

? 頻繁集群創(chuàng)建/銷毀（如測試環(huán)境）優(yōu)先選擇kubeadm。

5. 云生態(tài)集成

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

6. 成本模型

? 二進(jìn)制部署的隱性成本：

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

時(shí)間成本：手動(dòng)升級一個(gè)50節(jié)點(diǎn)集群可能需要2人天。

7. 災(zāi)備與可恢復(fù)性

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

? kubeadm可結(jié)合Velero實(shí)現(xiàn)標(biāo)準(zhǔn)化災(zāi)備。

四、實(shí)戰(zhàn)建議：企業(yè)落地步驟

步驟1：明確需求與約束

? 制作檢查清單：

[ ] 是否需要定制Kubernetes組件？  
[ ] 集群規(guī)模預(yù)期增長曲線如何？  
[ ] 團(tuán)隊(duì)是否有能力維護(hù)證書輪換？  
[ ] 是否需通過等保/PCI-DSS認(rèn)證？

步驟2：技術(shù)驗(yàn)證（PoC）

? 二進(jìn)制部署PoC重點(diǎn)：

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

? 模擬etcd節(jié)點(diǎn)故障，驗(yàn)證恢復(fù)流程。

? kubeadm PoC重點(diǎn)：

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

? 測試kubeadm upgrade的穩(wěn)定性。

步驟3：制定標(biāo)準(zhǔn)化流程

? 二進(jìn)制部署規(guī)范：

使用Ansible Role固化組件啟動(dòng)參數(shù)。

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

? kubeadm部署規(guī)范：

? 通過kubeadm config文件統(tǒng)一配置模板。

? 集成Arkade或kurl實(shí)現(xiàn)離線部署。

步驟4：監(jiān)控與優(yōu)化

? 關(guān)鍵監(jiān)控指標(biāo)：

二進(jìn)制部署：關(guān)注kube-apiserver的goroutine泄漏、etcd寫入延遲。

kubeadm部署：監(jiān)控kubelet的容器啟動(dòng)延遲、證書過期時(shí)間。

? 優(yōu)化案例：某企業(yè)通過二進(jìn)制部署調(diào)優(yōu)kube-controller-manager的--concurrent-deployment-syncs，將部署回滾時(shí)間從5分鐘縮短至30秒。

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

? 二進(jìn)制部署是“手術(shù)刀”，適合需要精細(xì)控制的企業(yè)，但要求團(tuán)隊(duì)具備極強(qiáng)的手術(shù)能力。

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

最終建議：

? 從kubeadm起步，隨著業(yè)務(wù)復(fù)雜度提升逐步引入二進(jìn)制組件。

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

企業(yè)應(yīng)根據(jù)實(shí)際場景動(dòng)態(tài)調(diào)整——技術(shù)選型的終極目標(biāo)不是追求“純粹性”，而是讓基礎(chǔ)設(shè)施成為業(yè)務(wù)創(chuàng)新的堅(jiān)實(shí)底座。