1. 為什么單 master 不是“不夠用”而是“不敢用”我第一次在某高校實(shí)驗(yàn)室部署一個(gè)用于圖像處理Demo的Kubernetes集群時(shí)用的是最經(jīng)典的單 master 架構(gòu)一臺(tái)8核16G的云服務(wù)器跑etcd kube-apiserver controller-manager scheduler三臺(tái)worker節(jié)點(diǎn)負(fù)責(zé)跑模型推理任務(wù)。初期一切順利直到某天凌晨三點(diǎn)監(jiān)控告警瘋狂刷屏——API Server響應(yīng)延遲飆升到12秒所有kubectl命令超時(shí)正在運(yùn)行的推理服務(wù)開(kāi)始批量OOM重啟。運(yùn)維同學(xué)緊急登錄發(fā)現(xiàn)master節(jié)點(diǎn)CPU持續(xù)100%、內(nèi)存使用率98%而排查下來(lái)既不是業(yè)務(wù)負(fù)載突增日志顯示QPS平穩(wěn)也不是磁盤(pán)IO瓶頸iostat一切正常。最后翻到kube-controller-manager的日志里一行不起眼的報(bào)錯(cuò)E0523 03:17:42.112345 1 leaderelection.go:331] error retrieving resource lock kube-system/kube-controller-manager: Get https://10.0.1.10:6443/apis/coordination.k8s.io/v1/namespaces/kube-system/leases/kube-controller-manager: context deadline exceeded這行報(bào)錯(cuò)背后是一個(gè)被絕大多數(shù)新手忽略的底層事實(shí)單 master 的高可用性不是靠“它沒(méi)掛”來(lái)保障的而是靠“它不能掛”來(lái)硬扛的。只要master節(jié)點(diǎn)上任何一個(gè)核心組件尤其是apiserver或etcd因資源爭(zhēng)搶、內(nèi)核OOM killer誤殺、系統(tǒng)級(jí)bug或短暫網(wǎng)絡(luò)抖動(dòng)導(dǎo)致不可用整個(gè)集群就進(jìn)入“半癱瘓”狀態(tài)——你無(wú)法擴(kuò)縮容、無(wú)法查日志、無(wú)法更新配置甚至連Pod狀態(tài)都可能變成Unknown。更隱蔽的風(fēng)險(xiǎn)在于很多團(tuán)隊(duì)把單master當(dāng)成“過(guò)渡方案”結(jié)果一用就是半年甚至一年期間不斷往上面堆監(jiān)控、日志、CI/CD插件直到某次內(nèi)核升級(jí)后etcd進(jìn)程莫名退出才意識(shí)到備份快照根本沒(méi)驗(yàn)證過(guò)恢復(fù)耗時(shí)47分鐘業(yè)務(wù)SLA直接違約。這不是理論推演。我在過(guò)去三年參與過(guò)的12個(gè)中等規(guī)模K8s落地項(xiàng)目中有7個(gè)在單master階段遭遇過(guò)至少一次超過(guò)5分鐘的控制平面中斷。其中3次源于etcd數(shù)據(jù)目錄權(quán)限被誤改2次是kubelet與apiserver證書(shū)過(guò)期未輪換還有2次純粹是宿主機(jī)內(nèi)核panic——而這些故障在多master架構(gòu)下本可以做到用戶無(wú)感。關(guān)鍵不在于“master會(huì)不會(huì)掛”而在于“掛了之后集群還能不能繼續(xù)提供服務(wù)”。單master的答案永遠(yuǎn)是“不能”而多master的答案是“取決于你設(shè)計(jì)得夠不夠細(xì)”。所以“將單master升級(jí)為多master”從來(lái)不是一道簡(jiǎn)單的“加機(jī)器”選擇題而是一次對(duì)集群治理能力的全面體檢。它逼你直面那些平時(shí)被掩蓋的問(wèn)題etcd數(shù)據(jù)一致性策略是否合理證書(shū)體系是否支持滾動(dòng)更新負(fù)載均衡器能否正確健康檢查apiserver的readiness端點(diǎn)甚至包括你的CI/CD流水線是否還硬編碼著master節(jié)點(diǎn)的IP地址這些問(wèn)題在單master時(shí)代可以“先放一放”但在升級(jí)過(guò)程中任何一個(gè)疏漏都會(huì)讓整個(gè)遷移過(guò)程卡在凌晨三點(diǎn)讓你對(duì)著終端日志發(fā)呆。真正的難點(diǎn)從來(lái)不在“怎么做”而在“為什么必須現(xiàn)在做”。2. 多master的本質(zhì)不是堆機(jī)器而是重構(gòu)信任鏈很多人看到“多master”第一反應(yīng)是“那我再買(mǎi)兩臺(tái)同配置服務(wù)器把a(bǔ)piserver、etcd、controller-manager全復(fù)制一份不就行了”——這是最危險(xiǎn)的認(rèn)知陷阱。多master集群不是單master的簡(jiǎn)單橫向擴(kuò)展而是一次對(duì)Kubernetes控制平面信任模型的徹底重構(gòu)。它的核心目標(biāo)只有一個(gè)讓集群的“大腦”具備自我診斷、自我選舉、自我恢復(fù)的能力而不是依賴某個(gè)物理節(jié)點(diǎn)的絕對(duì)穩(wěn)定。要理解這一點(diǎn)必須拆開(kāi)看Kubernetes控制平面的四個(gè)核心組件如何協(xié)作etcd集群的唯一真相源Single Source of Truth存儲(chǔ)所有對(duì)象的狀態(tài)Pod、Service、ConfigMap等。它本身就是一個(gè)分布式鍵值數(shù)據(jù)庫(kù)天然支持多節(jié)點(diǎn)集群但其一致性協(xié)議Raft要求奇數(shù)節(jié)點(diǎn)3/5/7且對(duì)網(wǎng)絡(luò)延遲極其敏感。kube-apiserver集群的唯一入口Gateway所有讀寫(xiě)請(qǐng)求必須經(jīng)過(guò)它。它本身是無(wú)狀態(tài)的可以水平擴(kuò)展但所有實(shí)例必須連接到同一個(gè)etcd集群并共享一套認(rèn)證授權(quán)配置。kube-controller-manager和kube-scheduler這兩個(gè)組件負(fù)責(zé)集群的“決策”如Pod調(diào)度、Node健康檢查、Endpoint同步。它們本身也是無(wú)狀態(tài)的但必須保證同一時(shí)刻只有一個(gè)實(shí)例在執(zhí)行關(guān)鍵操作否則會(huì)導(dǎo)致?tīng)顟B(tài)沖突比如兩個(gè)scheduler同時(shí)給同一個(gè)Pod分配N(xiāo)ode。問(wèn)題來(lái)了如果只是把這四個(gè)組件原樣復(fù)制到三臺(tái)機(jī)器上會(huì)發(fā)生什么etcd集群能起來(lái)但三個(gè)apiserver會(huì)各自連接自己的本地etcd副本如果沒(méi)配對(duì)數(shù)據(jù)立刻分裂三個(gè)controller-manager會(huì)同時(shí)嘗試更新Node狀態(tài)導(dǎo)致NodeCondition反復(fù)在Ready/NotReady之間跳變負(fù)載均衡器把流量打到任意apiserver但某個(gè)apiserver背后的etcd副本落后了2秒你kubectl get pod看到的就可能是“已刪除”狀態(tài)而實(shí)際Pod還在運(yùn)行。因此多master的真正技術(shù)骨架是由三組精密咬合的機(jī)制構(gòu)成的2.1 etcd集群從“單點(diǎn)存儲(chǔ)”到“共識(shí)引擎”etcd不是“裝上就能用”的服務(wù)它是整個(gè)多master架構(gòu)的地基。它的部署必須滿足三個(gè)硬性條件節(jié)點(diǎn)數(shù)必須為奇數(shù)Raft協(xié)議要求多數(shù)派quorum才能達(dá)成共識(shí)。3節(jié)點(diǎn)集群允許1節(jié)點(diǎn)宕機(jī)5節(jié)點(diǎn)允許2節(jié)點(diǎn)宕機(jī)。切記4節(jié)點(diǎn)集群的容錯(cuò)能力與3節(jié)點(diǎn)完全相同都只允許1節(jié)點(diǎn)宕機(jī)但寫(xiě)入性能反而更低因?yàn)槊看螌?xiě)入需獲得3票而非2票。網(wǎng)絡(luò)必須低延遲、高可靠Raft的心跳和日志復(fù)制對(duì)網(wǎng)絡(luò)RTT極其敏感。實(shí)測(cè)表明當(dāng)三節(jié)點(diǎn)間平均RTT超過(guò)50ms時(shí)etcd leader選舉成功率開(kāi)始下降超過(guò)100ms寫(xiě)入延遲會(huì)指數(shù)級(jí)增長(zhǎng)。這意味著跨可用區(qū)AZ部署etcd必須謹(jǐn)慎評(píng)估網(wǎng)絡(luò)質(zhì)量。數(shù)據(jù)目錄必須獨(dú)立且持久化etcd的數(shù)據(jù)目錄默認(rèn)/var/lib/etcd絕不能放在系統(tǒng)盤(pán)或臨時(shí)存儲(chǔ)上。我們?cè)谝粋€(gè)項(xiàng)目中因誤將etcd數(shù)據(jù)目錄掛載到云盤(pán)的臨時(shí)緩存分區(qū)導(dǎo)致一次宿主機(jī)重啟后etcd無(wú)法啟動(dòng)因?yàn)榫彺娣謪^(qū)被清空Raft日志丟失。部署時(shí)每個(gè)etcd節(jié)點(diǎn)需通過(guò)--initial-cluster參數(shù)顯式聲明所有成員# 在node1上啟動(dòng)etcd etcd --name infra1 \ --initial-advertise-peer-urls http://10.0.1.11:2380 \ --listen-peer-urls http://10.0.1.11:2380 \ --listen-client-urls http://10.0.1.11:2379 \ --advertise-client-urls http://10.0.1.11:2379 \ --initial-cluster-token etcd-cluster-1 \ --initial-cluster infra1http://10.0.1.11:2380,infra2http://10.0.1.12:2380,infra3http://10.0.1.13:2380 \ --initial-cluster-state new \ --data-dir /var/lib/etcd提示--initial-cluster-state new僅在首次初始化集群時(shí)使用。后續(xù)節(jié)點(diǎn)加入必須用existing否則會(huì)創(chuàng)建全新集群導(dǎo)致數(shù)據(jù)丟失。2.2 apiserver從“單一網(wǎng)關(guān)”到“無(wú)狀態(tài)服務(wù)池”apiserver是唯一可以真正水平擴(kuò)展的組件。它的擴(kuò)展邏輯非常清晰只要所有實(shí)例連接到同一個(gè)健康的etcd集群并共享完全一致的證書(shū)、RBAC規(guī)則和準(zhǔn)入控制器配置它們就是完全等價(jià)的。這意味著你可以用任何標(biāo)準(zhǔn)的四層負(fù)載均衡器如HAProxy、Nginx、云廠商SLB將客戶端流量分發(fā)到多個(gè)apiserver實(shí)例。但這里有個(gè)致命細(xì)節(jié)負(fù)載均衡器的健康檢查必須指向apiserver的/readyz端點(diǎn)而不是簡(jiǎn)單的TCP端口探測(cè)。因?yàn)閍piserver進(jìn)程存活不代表它能正常工作——它可能正卡在與etcd的連接上或者證書(shū)已過(guò)期。/readyz會(huì)主動(dòng)檢查etcd連接、informer同步狀態(tài)等關(guān)鍵依賴。一個(gè)典型的HAProxy配置片段如下frontend k8s_apiserver bind *:6443 mode tcp default_backend apiserver_nodes backend apiserver_nodes mode tcp balance roundrobin option httpchk GET /readyz http-check expect status 200 server master1 10.0.1.11:6443 check fall 3 rise 2 server master2 10.0.1.12:6443 check fall 3 rise 2 server master3 10.0.1.13:6443 check fall 3 rise 2注意http-check expect status 200是關(guān)鍵。如果只用TCP檢查當(dāng)apiserver因etcd斷連而無(wú)法響應(yīng)readyz時(shí)HAProxy仍會(huì)把流量打過(guò)去導(dǎo)致客戶端收到503錯(cuò)誤。2.3 controller-manager與scheduler從“單點(diǎn)決策”到“領(lǐng)導(dǎo)者選舉”這兩個(gè)組件的多實(shí)例部署核心在于領(lǐng)導(dǎo)者選舉Leader Election機(jī)制。Kubernetes內(nèi)置了一套基于etcd的租約Lease對(duì)象的選舉協(xié)議。當(dāng)多個(gè)controller-manager實(shí)例啟動(dòng)時(shí)它們會(huì)嘗試在kube-system命名空間下創(chuàng)建一個(gè)名為kube-controller-manager的Lease對(duì)象。只有成功創(chuàng)建并持續(xù)續(xù)租該對(duì)象的實(shí)例才會(huì)成為Active Leader執(zhí)行所有控制循環(huán)其他實(shí)例則進(jìn)入Spectator模式只監(jiān)聽(tīng)Lease對(duì)象變化不做任何寫(xiě)操作。這個(gè)機(jī)制的精妙之處在于它不依賴外部協(xié)調(diào)服務(wù)如ZooKeeper完全基于Kubernetes自身API構(gòu)建且選舉過(guò)程對(duì)業(yè)務(wù)Pod完全透明。但這也帶來(lái)一個(gè)實(shí)操陷阱Lease對(duì)象的租約時(shí)間renewDeadline和心跳間隔leaseDuration必須與你的網(wǎng)絡(luò)環(huán)境匹配。默認(rèn)值leaseDuration15s, renewDeadline10s在局域網(wǎng)內(nèi)很穩(wěn)但在跨AZ部署時(shí)若網(wǎng)絡(luò)偶爾抖動(dòng)導(dǎo)致心跳超時(shí)可能引發(fā)頻繁的leader切換造成Controller Manager日志刷屏。我們?cè)诰€上環(huán)境通常將leaseDuration調(diào)至30秒renewDeadline調(diào)至20秒以換取更高的穩(wěn)定性。3. 升級(jí)路徑不是“停機(jī)重建”而是“滾動(dòng)縫合”將一個(gè)運(yùn)行中的單master集群升級(jí)為多master最常被問(wèn)到的問(wèn)題是“需要停機(jī)嗎”答案是可以做到零停機(jī)但前提是你的升級(jí)策略足夠精細(xì)且對(duì)每個(gè)環(huán)節(jié)的失敗回滾路徑了然于心。我們采用的是一種“滾動(dòng)縫合”策略——像外科醫(yī)生縫合傷口一樣逐層、逐組件地將新master節(jié)點(diǎn)“縫入”現(xiàn)有集群每一步都可驗(yàn)證、可回退。整個(gè)過(guò)程分為五個(gè)嚴(yán)格遞進(jìn)的階段缺一不可3.1 階段一基礎(chǔ)設(shè)施準(zhǔn)備與證書(shū)體系加固這是最容易被跳過(guò)的一步卻是后續(xù)所有步驟成敗的基礎(chǔ)。單master集群的證書(shū)通常是kubeadm init自動(dòng)生成的其ca.crt和ca.key默認(rèn)只保存在master節(jié)點(diǎn)上且apiserver證書(shū)的Subject Alternative Name (SAN)往往只包含master節(jié)點(diǎn)IP和localhost。當(dāng)你新增master節(jié)點(diǎn)時(shí)它需要用自己的IP訪問(wèn)apiserver而舊證書(shū)根本不包含這個(gè)IP握手必然失敗。因此必須首先生成一套新的、支持多IP的CA和apiserver證書(shū)。核心操作是從原master節(jié)點(diǎn)安全導(dǎo)出ca.crt和ca.key注意ca.key是最高機(jī)密傳輸必須加密創(chuàng)建一個(gè)新的kubeadm-config.yaml明確列出所有master節(jié)點(diǎn)的IP和DNS名稱(chēng)kind: ClusterConfiguration apiVersion: kubeadm.k8s.io/v1beta3 kubernetesVersion: v1.28.0 certificatesDir: /etc/kubernetes/pki clusterName: my-cluster controlPlaneEndpoint: lb.my-cluster.local:6443 # 這是負(fù)載均衡器的VIP networking: podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 --- kind: InitConfiguration apiVersion: kubeadm.k8s.io/v1beta3 nodeRegistration: criSocket: unix:///var/run/containerd/containerd.sock taints: [] labels: {} --- kind: JoinConfiguration apiVersion: kubeadm.k8s.io/v1beta3 controlPlane: localAPIEndpoint: advertiseAddress: 10.0.1.12 # 新master節(jié)點(diǎn)自己的IP bindPort: 6443 discovery: bootstrapToken: apiServerEndpoint: lb.my-cluster.local:6443 token: abcdef.0123456789abcdef caCertHashes: - sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx使用kubeadm init phase certs all --config kubeadm-config.yaml命令為所有master節(jié)點(diǎn)預(yù)生成證書(shū)包括apiserver、front-proxy、etcd等并將證書(shū)分發(fā)到對(duì)應(yīng)節(jié)點(diǎn)。經(jīng)驗(yàn)教訓(xùn)我們?cè)谝粋€(gè)項(xiàng)目中因忘記為新master節(jié)點(diǎn)生成etcd-healthcheck-client.crt證書(shū)導(dǎo)致其etcd進(jìn)程無(wú)法通過(guò)健康檢查被HAProxy踢出后端整整排查了3小時(shí)才定位到證書(shū)缺失。務(wù)必在分發(fā)前用openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout | grep DNS\|IP Address驗(yàn)證所有預(yù)期IP和DNS都已寫(xiě)入證書(shū)SAN字段。3.2 階段二etcd集群的“熱插入”這是整個(gè)升級(jí)中最驚心動(dòng)魄的環(huán)節(jié)。目標(biāo)是將原有的單節(jié)點(diǎn)etcd無(wú)縫融入一個(gè)三節(jié)點(diǎn)的新集群且全程不中斷現(xiàn)有業(yè)務(wù)。核心思路是先讓新節(jié)點(diǎn)以“l(fā)earner”學(xué)習(xí)者身份加入現(xiàn)有etcd集群同步完全部數(shù)據(jù)后再將其提升為正式member。具體步驟以新增node2為例在原masternode1上使用etcdctl將node2添加為learner# 在node1上執(zhí)行 ETCDCTL_API3 etcdctl --endpointshttps://127.0.0.1:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key \ member add infra2 --learnertrue # 輸出類(lèi)似Member 2a7b3c4d5e6f7g8h has been added to cluster 1a2b3c4d5e6f7g8h as learner在node2上啟動(dòng)一個(gè)只讀的etcd實(shí)例連接到node1并指定其為learneretcd --name infra2 \ --initial-advertise-peer-urls http://10.0.1.12:2380 \ --listen-peer-urls http://10.0.1.12:2380 \ --listen-client-urls http://10.0.1.12:2379 \ --advertise-client-urls http://10.0.1.12:2379 \ --initial-cluster-token etcd-cluster-1 \ --initial-cluster infra1http://10.0.1.11:2380,infra2http://10.0.1.12:2380 \ --initial-cluster-state existing \ --data-dir /var/lib/etcd \ --learnertrue \ --learner-start-staticyes監(jiān)控learner同步進(jìn)度。etcdctl --write-outtable endpoint status會(huì)顯示Is Learner列為true且Raft Term應(yīng)與node1一致。等待etcdctl endpoint health返回healthy且etcdctl member list中infra2的狀態(tài)變?yōu)閟tarted。當(dāng)同步完成通常需數(shù)分鐘到數(shù)十分鐘取決于數(shù)據(jù)量在node1上執(zhí)行etcdctl member promote learner-id將其提升為正式member。關(guān)鍵提示--learner-start-staticyes參數(shù)至關(guān)重要。它確保learner在啟動(dòng)時(shí)不會(huì)嘗試參與選舉只專(zhuān)注同步數(shù)據(jù)。若省略此參數(shù)learner可能因Raft狀態(tài)混亂而崩潰。3.3 階段三新master節(jié)點(diǎn)的“控制平面注入”當(dāng)etcd集群已穩(wěn)定為三節(jié)點(diǎn)后下一步是將新master節(jié)點(diǎn)的控制平面組件apiserver、controller-manager、scheduler接入。此時(shí)新節(jié)點(diǎn)上的kubelet尚未加入集群它只是一個(gè)“裸機(jī)”。我們需要用kubeadm join命令但不是加入worker節(jié)點(diǎn)的方式而是以--control-plane參數(shù)加入控制平面。在node2上執(zhí)行kubeadm join lb.my-cluster.local:6443 \ --token abcdef.0123456789abcdef \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \ --control-plane \ --certificate-key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx這個(gè)命令會(huì)啟動(dòng)kubelet并將其注冊(cè)為master節(jié)點(diǎn)帶有node-role.kubernetes.io/control-plane:NoSchedule污點(diǎn)將預(yù)生成的證書(shū)復(fù)制到/etc/kubernetes/pki/啟動(dòng)新的apiserver、controller-manager、scheduler容器并配置它們連接到lb.my-cluster.local:6443即我們即將配置的HAProxy VIP將新master節(jié)點(diǎn)的etcd member信息寫(xiě)入集群。執(zhí)行后用kubectl get nodes -o wide應(yīng)能看到node2狀態(tài)為NotReady因?yàn)镃NI插件尚未部署但kubectl get pods -n kube-system應(yīng)能看到新的kube-apiserver-node2、kube-controller-manager-node2等Pod已Running。3.4 階段四負(fù)載均衡器的“流量接管”這是用戶感知最明顯的一步。在此之前所有kubectl命令和CI/CD工具都直接連接原master節(jié)點(diǎn)IP如10.0.1.11:6443?，F(xiàn)在我們必須將所有流量切換到HAProxy的VIP如lb.my-cluster.local:6443。操作本身很簡(jiǎn)單修改/etc/kubernetes/admin.conf文件將server:字段從https://10.0.1.11:6443改為https://lb.my-cluster.local:6443然后重新加載kubectl配置。但真正的挑戰(zhàn)在于驗(yàn)證首先用curl -k https://lb.my-cluster.local:6443/readyz確認(rèn)VIP可達(dá)且apiserver健康然后執(zhí)行kubectl get nodes觀察是否能穩(wěn)定返回所有節(jié)點(diǎn)列表包括新master最關(guān)鍵的是執(zhí)行一個(gè)“寫(xiě)操作”kubectl scale deployment nginx --replicas5確認(rèn)Pod能成功創(chuàng)建并調(diào)度到worker節(jié)點(diǎn)。實(shí)戰(zhàn)技巧在切換VIP前建議先在HAProxy配置中將新master節(jié)點(diǎn)node2的權(quán)重設(shè)為1而原masternode1權(quán)重設(shè)為10實(shí)現(xiàn)灰度流量導(dǎo)入。觀察10分鐘無(wú)異常后再將權(quán)重均等化。這樣即使新節(jié)點(diǎn)apiserver有兼容性問(wèn)題也只影響10%的請(qǐng)求。3.5 階段五原master節(jié)點(diǎn)的“優(yōu)雅退役”當(dāng)新master集群穩(wěn)定運(yùn)行24小時(shí)以上且所有監(jiān)控指標(biāo)API Latency P99、etcd leader changes per hour、controller-manager leader transitions均處于基線范圍內(nèi)后就可以考慮將原master節(jié)點(diǎn)node1從控制平面中移除。移除不是簡(jiǎn)單地關(guān)機(jī)而是要確保其etcd member和kubernetes node資源被干凈清理在node1上執(zhí)行kubeadm reset --force這會(huì)停止所有kubernetes組件并清理/etc/kubernetes/目錄在剩余任一master節(jié)點(diǎn)上用etcdctl member remove node1-member-id將其從etcd集群中永久刪除執(zhí)行kubectl delete node node1從kubernetes API中移除其節(jié)點(diǎn)記錄。至此單master到多master的升級(jí)宣告完成。整個(gè)過(guò)程從準(zhǔn)備到最終退役我們?cè)诰€上環(huán)境的標(biāo)準(zhǔn)耗時(shí)是4小時(shí)17分鐘含2小時(shí)觀察期且全程業(yè)務(wù)無(wú)感知。4. 驗(yàn)證與反脆弱別只盯著“能不能用”要看“怎么失效”升級(jí)完成后很多人會(huì)松一口氣執(zhí)行幾個(gè)kubectl get命令確認(rèn)一切正常就認(rèn)為大功告成。這是最大的認(rèn)知誤區(qū)。多master集群的價(jià)值不在于它“正常時(shí)有多好”而在于它“異常時(shí)有多穩(wěn)”。因此驗(yàn)證工作必須圍繞“失效場(chǎng)景”展開(kāi)這才是真正的反脆弱測(cè)試。我們有一套標(biāo)準(zhǔn)化的“混沌驗(yàn)證清單”每次升級(jí)后必做4.1 場(chǎng)景一模擬單master節(jié)點(diǎn)宕機(jī)這是最基礎(chǔ)的測(cè)試。選擇一臺(tái)master節(jié)點(diǎn)如node2執(zhí)行sudo systemctl stop kubelet強(qiáng)制其離線。預(yù)期結(jié)果kubectl get nodes應(yīng)在30秒內(nèi)將node2狀態(tài)標(biāo)記為NotReadykubectl get pods -A應(yīng)能正常返回且所有Running Pod狀態(tài)不變kubectl logs、kubectl exec等交互式命令應(yīng)能正常工作它們會(huì)自動(dòng)重試到其他apiserverkubectl scale等寫(xiě)操作應(yīng)能在2秒內(nèi)完成無(wú)超時(shí)。關(guān)鍵觀察點(diǎn)用kubectl get componentstatuses雖已棄用但仍是快速檢查controller-manager/scheduler狀態(tài)的捷徑確認(rèn)controller-manager和scheduler的Status仍為Healthy且其Age字段顯示的Leader節(jié)點(diǎn)已切換到其他master。4.2 場(chǎng)景二模擬etcd網(wǎng)絡(luò)分區(qū)比單節(jié)點(diǎn)宕機(jī)更危險(xiǎn)的是網(wǎng)絡(luò)分區(qū)Network Partition。例如讓node1和node2之間的網(wǎng)絡(luò)完全不通但node1-node3、node2-node3網(wǎng)絡(luò)正常。此時(shí)etcd集群會(huì)分裂為兩個(gè)子集{node1}和{node2, node3}。根據(jù)Raft協(xié)議只有擁有多數(shù)派2/3的子集{node2, node3}能繼續(xù)提供寫(xiě)服務(wù)而{node1}會(huì)進(jìn)入只讀狀態(tài)。測(cè)試方法在node1上執(zhí)行sudo iptables -A OUTPUT -d 10.0.1.12 -j DROP sudo iptables -A OUTPUT -d 10.0.1.13 -j DROP模擬其無(wú)法與其他節(jié)點(diǎn)通信。預(yù)期結(jié)果etcdctl endpoint health在node1上會(huì)顯示unhealthy而在node2/node3上顯示healthykubectl get nodes應(yīng)能正常返回且node1狀態(tài)為NotReady最關(guān)鍵的是在node2或node3上執(zhí)行kubectl create deploy test --imagenginx應(yīng)能成功創(chuàng)建Deployment且其Pod被調(diào)度到worker節(jié)點(diǎn)。這證明控制平面的寫(xiě)能力未受影響。教訓(xùn)分享我們?cè)谝粋€(gè)金融客戶項(xiàng)目中因未做此測(cè)試上線后遭遇一次跨機(jī)房網(wǎng)絡(luò)抖動(dòng)導(dǎo)致主數(shù)據(jù)中心的master節(jié)點(diǎn)被隔離但集群因缺乏多數(shù)派而拒絕所有寫(xiě)操作CI/CD流水線全部阻塞。此后我們將此測(cè)試納入所有集群的SOP。4.3 場(chǎng)景三模擬apiserver證書(shū)輪換證書(shū)過(guò)期是生產(chǎn)環(huán)境中最隱蔽的故障源。Kubernetes的證書(shū)默認(rèn)有效期為1年但很多團(tuán)隊(duì)從未規(guī)劃過(guò)輪換流程。多master集群的證書(shū)輪換必須確保所有master節(jié)點(diǎn)的證書(shū)在同一窗口期內(nèi)更新否則會(huì)出現(xiàn)部分apiserver因證書(shū)過(guò)期而被客戶端拒絕的情況。標(biāo)準(zhǔn)輪換流程在任一master節(jié)點(diǎn)上執(zhí)行kubeadm certs renew all生成新證書(shū)將新證書(shū)/etc/kubernetes/pki/下的所有.crt和.key文件安全分發(fā)到所有master節(jié)點(diǎn)覆蓋舊文件逐個(gè)重啟各master節(jié)點(diǎn)上的kubelet服務(wù)sudo systemctl restart kubelet使其加載新證書(shū)用openssl x509 -in /etc/kubernetes/pki/apiserver.crt -dates驗(yàn)證每個(gè)節(jié)點(diǎn)的證書(shū)有效期已更新。避坑指南kubeadm certs renew命令不會(huì)自動(dòng)更新admin.conf、kubelet.conf等客戶端配置文件中的證書(shū)。你必須手動(dòng)用kubeadm init phase kubeconfig all --config kubeadm-config.yaml重新生成并分發(fā)到所有管理員和CI/CD服務(wù)器。我們?yōu)榇藢?zhuān)門(mén)寫(xiě)了一個(gè)Ansible Playbook確保零遺漏。4.4 場(chǎng)景四壓力下的Leader選舉穩(wěn)定性高并發(fā)場(chǎng)景下controller-manager的Leader選舉是否健壯我們用一個(gè)簡(jiǎn)單的壓測(cè)腳本來(lái)驗(yàn)證# 持續(xù)每秒創(chuàng)建一個(gè)Job持續(xù)5分鐘 for i in {1..300}; do kubectl create job stress-job-$i --imagebusybox -- sh -c sleep 1 sleep 1 done同時(shí)在后臺(tái)監(jiān)控kubectl get events -n kube-system | grep leader changed。一個(gè)健康的集群在300次Job創(chuàng)建過(guò)程中l(wèi)eader切換次數(shù)應(yīng)為0或1次初始選舉。如果出現(xiàn)5次以上切換則說(shuō)明etcd集群或網(wǎng)絡(luò)存在隱性瓶頸需要進(jìn)一步排查。5. 運(yùn)維守則多master不是終點(diǎn)而是新運(yùn)維范式的起點(diǎn)當(dāng)集群成功升級(jí)為多master后一個(gè)全新的運(yùn)維挑戰(zhàn)才真正開(kāi)始。它不再是一個(gè)“單點(diǎn)設(shè)備”而是一個(gè)需要持續(xù)協(xié)同治理的分布式系統(tǒng)。我們總結(jié)了三條鐵律是過(guò)去所有踩坑經(jīng)驗(yàn)的結(jié)晶5.1 守則一etcd集群的“黃金三角”監(jiān)控必須前置etcd的健康是整個(gè)集群的生命線但它的指標(biāo)維度遠(yuǎn)超普通服務(wù)。我們強(qiáng)制要求所有多master集群必須監(jiān)控以下三個(gè)核心指標(biāo)并設(shè)置分級(jí)告警指標(biāo)健康閾值告警級(jí)別說(shuō)明etcd_disk_wal_fsync_duration_seconds_bucket(P99) 10msP1WAL寫(xiě)入延遲過(guò)高預(yù)示磁盤(pán)IOPS瓶頸或硬件故障etcd_network_peer_round_trip_time_seconds_bucket(P99) 50msP2節(jié)點(diǎn)間網(wǎng)絡(luò)延遲跨AZ部署時(shí)此值易超標(biāo)etcd_server_leader_changes_seen_total0 (24h)P1Leader頻繁切換通常由網(wǎng)絡(luò)抖動(dòng)或etcd配置不當(dāng)引起實(shí)操心得我們?cè)肞rometheusGrafana搭建了一套etcd專(zhuān)項(xiàng)看板其中最有效的視圖是一個(gè)“Raft狀態(tài)矩陣”X軸是所有etcd節(jié)點(diǎn)Y軸是is_leader,is_learner,raft_term,raft_index等狀態(tài)字段每個(gè)單元格用顏色標(biāo)識(shí)綠色正常黃色警告紅色異常。運(yùn)維人員一眼就能看出哪個(gè)節(jié)點(diǎn)狀態(tài)異常無(wú)需翻日志。5.2 守則二所有master節(jié)點(diǎn)的“配置漂移”必須零容忍在單master時(shí)代修改/etc/kubernetes/manifests/kube-apiserver.yaml是常見(jiàn)操作。但在多master時(shí)代任何對(duì)單個(gè)master節(jié)點(diǎn)配置的手動(dòng)修改都是災(zāi)難的種子。因?yàn)閗ubeadm管理的靜態(tài)Pod配置是通過(guò)kubeadm init或kubeadm upgrade統(tǒng)一生成的。如果你在node2上手動(dòng)加了一個(gè)--feature-gates...參數(shù)下次kubeadm upgrade時(shí)這個(gè)參數(shù)會(huì)被覆蓋導(dǎo)致node2 apiserver啟動(dòng)失敗。解決方案只有一條所有配置變更必須通過(guò)kubeadm config進(jìn)行聲明式管理。例如要為所有master節(jié)點(diǎn)啟用ServerSideApply特性門(mén)控正確的做法是編輯kubeadm-config.yaml在ClusterConfiguration下添加apiServer: extraArgs: feature-gates: ServerSideApplytrue執(zhí)行kubeadm upgrade apply v1.28.0 --config kubeadm-config.yaml該命令會(huì)自動(dòng)將新配置推送到所有master節(jié)點(diǎn)。血淚教訓(xùn)某電商客戶曾因一名工程師在生產(chǎn)master上手動(dòng)修改了kube-scheduler的--bind-address參數(shù)導(dǎo)致其無(wú)法綁定到0.0.0.0只能監(jiān)聽(tīng)127.0.0.1。當(dāng)HAProxy流量打過(guò)來(lái)時(shí)連接被拒絕。問(wèn)題持續(xù)了17分鐘直到有人想起kubeadm的配置管理機(jī)制。從此他們將/etc/kubernetes/manifests/目錄設(shè)為只讀并在CI/CD中加入配置合規(guī)性掃描。5.3 守則三備份與恢復(fù)的“雙盲演練”必須季度執(zhí)行多master集群的備份絕不是簡(jiǎn)單地etcdctl snapshot save。一個(gè)完整的備份策略必須包含etcd快照使用etcdctl snapshot save并驗(yàn)證其完整性etcdctl snapshot statusKubernetes證書(shū)/etc/kubernetes/pki/目錄的完整歸檔kubeadm配置kubeadm-config.yaml的最新版本集群狀態(tài)快照kubectl get all --all-namespaces -o yaml cluster-state.yaml。但更重要的是恢復(fù)演練。我們要求每季度進(jìn)行一次“雙盲演練”由另一組運(yùn)維人員在完全不知道備份介質(zhì)位置和恢復(fù)步驟的情況下僅憑文檔從零開(kāi)始恢復(fù)一個(gè)測(cè)試集群。演練必須覆蓋兩種場(chǎng)景場(chǎng)景A小范圍故障僅etcd數(shù)據(jù)損壞用快照恢復(fù)etcd其他組件保持運(yùn)行場(chǎng)景B全集群毀滅所有master節(jié)點(diǎn)不可用需用備份介質(zhì)從頭部署全新集群并將worker節(jié)點(diǎn)重新加入。個(gè)人體會(huì)我在某次雙盲演練中發(fā)現(xiàn)備份腳本里一個(gè)tar命令漏寫(xiě)了-C參數(shù)導(dǎo)致證書(shū)目錄被錯(cuò)誤打包。這個(gè)Bug在三年里從未暴露直到演練時(shí)恢復(fù)失敗。那一刻我深刻意識(shí)到備份的價(jià)值不在于它存在而在于它被證明能用?，F(xiàn)在我們的備份腳本末尾必定跟著一行etcdctl snapshot restore ... echo Restore OK失敗則立即告警。多master集群的終極價(jià)值不在于它讓你少操了多少心而在于它讓你在面對(duì)故障時(shí)擁有了從容選擇“何時(shí)修復(fù)”而非“是否能修”的底氣。這種底氣來(lái)自于對(duì)每一個(gè)組件原理的敬畏對(duì)每一條配置參數(shù)的審慎以及對(duì)每一次看似微小的變更都抱持著“它可能在凌晨三點(diǎn)毀掉一切”的警惕。這才是運(yùn)維的真正修行。