1. 集群節(jié)點(diǎn)IP變更這件事遠(yuǎn)比想象中麻煩做過OpenShift運(yùn)維的人都有一個(gè)共識(shí)集群裝好之后最怕動(dòng)的就是底層網(wǎng)絡(luò)。但現(xiàn)實(shí)往往不給你選擇——機(jī)房搬遷、網(wǎng)段重新規(guī)劃、VLAN調(diào)整、硬件替換任何一個(gè)理由都可能導(dǎo)致你不得不面對(duì)一個(gè)棘手的問題節(jié)點(diǎn)IP地址要改而且改完之后集群還得能正常跑起來。這件事在單機(jī)上可能只是改個(gè)配置文件重啟網(wǎng)卡的事但在OpenShift集群里節(jié)點(diǎn)IP遠(yuǎn)不止是一個(gè)網(wǎng)絡(luò)接口地址那么簡(jiǎn)單。它滲透在證書SAN列表、etcd成員列表、kubelet注冊(cè)信息、API Server端點(diǎn)、SDN/OVN隧道地址、內(nèi)部DNS記錄等幾乎所有核心組件的配置中。你改了一個(gè)IP等于在集群的神經(jīng)系統(tǒng)里動(dòng)了一刀牽一發(fā)而動(dòng)全身。這篇文章要聊的就是當(dāng)你不得不修改OpenShift集群中某個(gè)或某幾個(gè)節(jié)點(diǎn)的IP地址時(shí)到底有哪些配置需要同步修改修改的順序是什么哪些地方最容易踩坑以及如何驗(yàn)證集群是否真正恢復(fù)了健康狀態(tài)。適合有一定OpenShift運(yùn)維基礎(chǔ)的讀者也適合正在做集群遷移規(guī)劃、想提前了解風(fēng)險(xiǎn)點(diǎn)的同行參考。需要提前說明的是不同OpenShift版本4.x的不同小版本之間在細(xì)節(jié)上會(huì)有差異本文以O(shè)penShift 4.x以4.12-4.14為主要參考為基準(zhǔn)展開涉及具體路徑和命令時(shí)我會(huì)標(biāo)注版本適用范圍。另外集群的部署方式UPI還是IPI、網(wǎng)絡(luò)插件OVN-Kubernetes還是OpenShift SDN也會(huì)影響具體操作文中會(huì)分別說明。2. 先搞清楚改IP到底動(dòng)了哪些東西2.1 OpenShift里IP地址的“存在感”為什么這么強(qiáng)很多人第一次做這個(gè)操作時(shí)會(huì)低估復(fù)雜度覺得不就是把舊IP換成新IP嘛。但OpenShift的設(shè)計(jì)哲學(xué)是“聲明式自愈”這意味著集群里到處都存著對(duì)節(jié)點(diǎn)IP的引用而且這些引用分布在不同的層級(jí)和組件中。打個(gè)比方OpenShift集群就像一棟大樓節(jié)點(diǎn)IP是每個(gè)房間的門牌號(hào)。門牌號(hào)變了不只是門口那塊牌子要換——快遞系統(tǒng)DNS、消防系統(tǒng)證書、物業(yè)管理系統(tǒng)etcd、內(nèi)部通訊錄kubelet注冊(cè)、監(jiān)控系統(tǒng)Prometheus target里存的地址全都要更新。漏掉任何一個(gè)那個(gè)環(huán)節(jié)就會(huì)出問題。具體來說一個(gè)節(jié)點(diǎn)IP地址在以下位置有引用etcd集群成員列表每個(gè)etcd成員的peer URL和client URL都綁定了IPKubernetes證書API Server證書、etcd證書、kubelet證書等的SAN列表中包含節(jié)點(diǎn)IPkubelet配置文件/var/lib/kubelet/kubeconfig和/etc/kubernetes/kubelet.conf中的地址引用Node對(duì)象kubectl get node -o yaml中status.addresses字段API Server的--advertise-address控制平面節(jié)點(diǎn)上這個(gè)參數(shù)綁定了IPSDN/OVN隧道端點(diǎn)OVN-Kubernetes的ovn-k8s-mp0接口、Geneve隧道端點(diǎn)地址內(nèi)部DNS集群內(nèi)DNS解析中節(jié)點(diǎn)相關(guān)的A記錄Machine Config PoolMachineConfig中可能包含與IP相關(guān)的配置監(jiān)控棧Prometheus的target列表、Alertmanager配置Operator配置部分Operator的CR中可能硬編碼了節(jié)點(diǎn)地址2.2 哪些場(chǎng)景需要改IP哪些場(chǎng)景可以繞開在動(dòng)手之前先評(píng)估一下是否真的必須改IP。有些場(chǎng)景其實(shí)有更省事的替代方案場(chǎng)景是否必須改IP替代方案機(jī)房整體搬遷網(wǎng)段不變否保持IP不變只改物理位置網(wǎng)段重新規(guī)劃舊網(wǎng)段不可用是無替代必須改單節(jié)點(diǎn)硬件故障替換否新節(jié)點(diǎn)用相同IP接入VLAN調(diào)整導(dǎo)致IP必須變是無替代必須改節(jié)點(diǎn)擴(kuò)容到新網(wǎng)段部分新節(jié)點(diǎn)用新網(wǎng)段舊節(jié)點(diǎn)不動(dòng)如果確認(rèn)必須改那就要做好“這不是十分鐘能搞定的事”的心理準(zhǔn)備。根據(jù)集群規(guī)模和節(jié)點(diǎn)角色不同整個(gè)操作可能需要2-6小時(shí)而且過程中集群會(huì)有短暫不可用。2.3 控制平面節(jié)點(diǎn)和工作節(jié)點(diǎn)改IP的難度完全不同這是必須先分清楚的事工作節(jié)點(diǎn)Worker/Compute改IP相對(duì)簡(jiǎn)單。工作節(jié)點(diǎn)不參與etcd quorum不承載API Server改IP主要影響kubelet注冊(cè)、SDN隧道和證書。操作得當(dāng)?shù)脑拰?duì)集群整體可用性影響較小。控制平面節(jié)點(diǎn)Master/Control Plane改IP復(fù)雜得多。控制平面節(jié)點(diǎn)承載etcd、API Server、Controller Manager、Scheduler等核心組件改IP涉及etcd集群成員變更、API Server證書重新簽發(fā)、端點(diǎn)重新配置等。操作不當(dāng)可能導(dǎo)致集群直接不可用甚至etcd數(shù)據(jù)丟失。注意如果你的集群只有一個(gè)控制平面節(jié)點(diǎn)單Master改IP的風(fēng)險(xiǎn)極高建議在操作前做好etcd快照備份并準(zhǔn)備好回滾方案。三Master的高可用集群相對(duì)安全一些但也要逐個(gè)節(jié)點(diǎn)操作不能同時(shí)改。2.4 操作前的必備檢查清單在開始任何操作之前先把這些信息收集齊# 記錄當(dāng)前集群節(jié)點(diǎn)列表和IP oc get nodes -o wide # 記錄etcd成員列表 oc exec -n openshift-etcd etcd-node-name -- etcdctl member list -w table # 記錄當(dāng)前證書SAN oc get secret -n openshift-kube-apiserver loadbalancer-serving-certkey -o jsonpath{.data.tls\.crt} | base64 -d | openssl x509 -text | grep -A1 Subject Alternative Name # 記錄集群版本 oc version # 記錄網(wǎng)絡(luò)插件類型 oc get network.operator cluster -o jsonpath{.spec.defaultNetwork.type} # 備份etcd oc exec -n openshift-etcd etcd-node-name -- etcdctl snapshot save /var/lib/etcd/backup-$(date %Y%m%d).db這些信息在后續(xù)操作和排查問題時(shí)都會(huì)用到。特別是etcd快照這是你最后的救命稻草。3. 核心操作全流程從改IP到集群恢復(fù)3.1 整體操作順序與邏輯改IP的操作順序不能亂亂了就會(huì)陷入“改了A導(dǎo)致B不可用修了B發(fā)現(xiàn)C又?jǐn)嗔恕钡乃姥h(huán)。正確的順序應(yīng)該是準(zhǔn)備工作備份etcd、記錄當(dāng)前狀態(tài)、通知相關(guān)人員將節(jié)點(diǎn)從集群中優(yōu)雅移除工作節(jié)點(diǎn)或做好etcd成員變更準(zhǔn)備控制平面節(jié)點(diǎn)在操作系統(tǒng)層面修改IP地址更新節(jié)點(diǎn)上的Kubernetes/OpenShift配置文件重新將節(jié)點(diǎn)加入集群或恢復(fù)etcd成員更新集群級(jí)別的配置證書、DNS、監(jiān)控等驗(yàn)證集群健康狀態(tài)這個(gè)順序的核心邏輯是先讓集群“忘記”舊IP的節(jié)點(diǎn)再讓節(jié)點(diǎn)以新IP“重新報(bào)到”最后修復(fù)集群層面的引用。如果反過來先改IP再處理集群配置集群會(huì)因?yàn)檎也坏焦?jié)點(diǎn)而進(jìn)入異常狀態(tài)增加排查難度。3.2 工作節(jié)點(diǎn)改IP的詳細(xì)步驟3.2.1 驅(qū)逐節(jié)點(diǎn)上的工作負(fù)載# 標(biāo)記節(jié)點(diǎn)為不可調(diào)度 oc adm cordon node-name # 驅(qū)逐節(jié)點(diǎn)上的PodDaemonSet管理的Pod不會(huì)被驅(qū)逐這是正常的 oc adm drain node-name --ignore-daemonsets --delete-emptydir-data --force # 確認(rèn)節(jié)點(diǎn)上業(yè)務(wù)Pod已遷移 oc get pods --all-namespaces --field-selector spec.nodeNamenode-name驅(qū)逐完成后節(jié)點(diǎn)上應(yīng)該只剩下DaemonSet管理的Pod如OVN、監(jiān)控agent等。這些Pod在節(jié)點(diǎn)重啟后會(huì)自動(dòng)恢復(fù)。3.2.2 從集群中刪除節(jié)點(diǎn)# 刪除Node對(duì)象 oc delete node node-name # 如果是IPI集群還需要?jiǎng)h除對(duì)應(yīng)的Machine對(duì)象 oc get machines -n openshift-machine-api | grep node-name oc delete machine -n openshift-machine-api machine-name注意如果是IPI集群刪除Machine對(duì)象會(huì)觸發(fā)MachineSet自動(dòng)創(chuàng)建新節(jié)點(diǎn)。如果你不想讓它自動(dòng)創(chuàng)建需要先scale down對(duì)應(yīng)的MachineSet或者直接修改MachineSet的副本數(shù)。3.2.3 操作系統(tǒng)層面修改IP這一步根據(jù)你的操作系統(tǒng)和網(wǎng)絡(luò)管理方式不同而不同。以RHCOSOpenShift默認(rèn)節(jié)點(diǎn)OS為例# 查看當(dāng)前網(wǎng)絡(luò)配置 nmcli connection show # 修改IP地址假設(shè)連接名為ens3 nmcli connection modify ens3 ipv4.addresses new-ip/prefix nmcli connection modify ens3 ipv4.gateway new-gateway nmcli connection modify ens3 ipv4.dns new-dns # 應(yīng)用配置 nmcli connection up ens3 # 驗(yàn)證 ip addr show ens3 ping new-gateway如果是RHEL節(jié)點(diǎn)可能還需要更新/etc/hosts文件中的IP映射。3.2.4 清理節(jié)點(diǎn)上的舊配置節(jié)點(diǎn)上有些配置文件會(huì)緩存舊IP需要手動(dòng)清理或更新# 清理kubelet的舊注冊(cè)信息 rm -f /var/lib/kubelet/kubeconfig rm -f /etc/kubernetes/kubelet.conf # 清理CNI配置中的舊IP引用 rm -rf /var/lib/cni/networks/ovn-k8s-cni-overlay/* rm -rf /var/lib/cni/networks/default/* # 清理OVN相關(guān)狀態(tài) rm -rf /var/run/ovn-kubernetes/* rm -rf /var/lib/ovn-kubernetes/*實(shí)操心得清理CNI和OVN狀態(tài)這一步很多人會(huì)忽略結(jié)果節(jié)點(diǎn)重新加入后Pod網(wǎng)絡(luò)不通。原因是OVN的隧道端點(diǎn)還指向舊IP清理后讓OVN重新初始化才能綁定新IP。3.2.5 重新加入集群對(duì)于IPI集群最簡(jiǎn)單的辦法是讓MachineSet自動(dòng)創(chuàng)建新節(jié)點(diǎn)新節(jié)點(diǎn)會(huì)使用新IP。但如果是UPI集群或者你想保留原節(jié)點(diǎn)需要手動(dòng)觸發(fā)節(jié)點(diǎn)重新注冊(cè)# 重啟kubelet服務(wù) systemctl restart kubelet # 重啟CRI-O systemctl restart crio # 等待節(jié)點(diǎn)重新注冊(cè) watch oc get nodes節(jié)點(diǎn)重新注冊(cè)后檢查Node對(duì)象的IP地址是否已更新oc get node node-name -o jsonpath{.status.addresses}3.2.6 更新集群級(jí)別配置節(jié)點(diǎn)重新加入后還需要更新以下集群級(jí)別配置# 更新DNS Operator的配置如果節(jié)點(diǎn)IP在DNS記錄中 oc get dns.operator default -o yaml dns-operator-backup.yaml # 編輯并更新相關(guān)IP oc apply -f dns-operator-updated.yaml # 更新監(jiān)控棧的target配置通常會(huì)自動(dòng)發(fā)現(xiàn)但可能需要手動(dòng)觸發(fā) oc rollout restart deployment -n openshift-monitoring prometheus-k8s # 更新證書如果新IP不在證書SAN中 # 這通常需要重新簽發(fā)證書具體操作見下一節(jié)3.3 控制平面節(jié)點(diǎn)改IP的詳細(xì)步驟控制平面節(jié)點(diǎn)改IP是整個(gè)操作中最復(fù)雜的部分因?yàn)樯婕癳tcd集群成員變更。這里以三Master集群中修改其中一個(gè)Master節(jié)點(diǎn)IP為例。3.3.1 準(zhǔn)備工作etcd快照與成員信息記錄# 在健康的etcd節(jié)點(diǎn)上執(zhí)行快照 oc exec -n openshift-etcd etcd-healthy-node -- etcdctl snapshot save /var/lib/etcd/pre-ip-change.db # 將快照復(fù)制到安全位置 oc cp openshift-etcd/etcd-healthy-node:/var/lib/etcd/pre-ip-change.db ./etcd-backup.db # 記錄當(dāng)前etcd成員列表 oc exec -n openshift-etcd etcd-healthy-node -- etcdctl member list -w table3.3.2 從etcd集群中移除目標(biāo)節(jié)點(diǎn)# 獲取目標(biāo)節(jié)點(diǎn)的etcd成員ID oc exec -n openshift-etcd etcd-healthy-node -- etcdctl member list -w table | grep target-node-ip # 移除該成員 oc exec -n openshift-etcd etcd-healthy-node -- etcdctl member remove member-id # 驗(yàn)證移除成功 oc exec -n openshift-etcd etcd-healthy-node -- etcdctl member list -w table注意移除etcd成員后集群的quorum會(huì)暫時(shí)降低。三Master集群移除一個(gè)后還剩兩個(gè)仍然滿足quorum2/3。但如果是兩Master集群不推薦移除一個(gè)后只剩一個(gè)quorum變?yōu)?/2此時(shí)如果剩下的節(jié)點(diǎn)出問題集群就掛了。所以操作期間要確保剩余節(jié)點(diǎn)健康。3.3.3 修改操作系統(tǒng)IP并清理配置與控制平面節(jié)點(diǎn)類似但需要額外清理etcd相關(guān)狀態(tài)# 修改IP同工作節(jié)點(diǎn)步驟 nmcli connection modify ens3 ipv4.addresses new-ip/prefix nmcli connection up ens3 # 清理etcd數(shù)據(jù)目錄重要 # 因?yàn)閑tcd成員已被移除舊數(shù)據(jù)不再需要保留反而會(huì)導(dǎo)致沖突 rm -rf /var/lib/etcd/member/* # 清理kubelet和靜態(tài)Pod配置 rm -f /var/lib/kubelet/kubeconfig rm -f /etc/kubernetes/kubelet.conf rm -rf /etc/kubernetes/manifests/*3.3.4 重新加入etcd集群這一步需要借助OpenShift的etcd Operator來重新部署etcd靜態(tài)Pod# 重啟kubelet讓靜態(tài)Pod重新部署 systemctl restart kubelet # 等待etcd Pod重新創(chuàng)建 oc get pods -n openshift-etcd -w # 檢查etcd成員是否自動(dòng)重新加入 oc exec -n openshift-etcd etcd-healthy-node -- etcdctl member list -w table如果etcd成員沒有自動(dòng)重新加入可能需要手動(dòng)干預(yù)# 獲取etcd Pod名稱 oc get pods -n openshift-etcd | grep target-node # 進(jìn)入etcd Pod手動(dòng)添加成員 oc exec -it -n openshift-etcd etcd-pod -- etcdctl member add new-member-name --peer-urlshttps://new-ip:23803.3.5 更新API Server證書和端點(diǎn)控制平面節(jié)點(diǎn)IP變更后API Server的證書SAN需要包含新IP否則客戶端連接會(huì)報(bào)證書錯(cuò)誤。# 查看當(dāng)前API Server證書SAN oc get secret -n openshift-kube-apiserver loadbalancer-serving-certkey -o jsonpath{.data.tls\.crt} | base64 -d | openssl x509 -text | grep -A1 Subject Alternative Name # 更新API Server的advertise-address # 這通常通過修改對(duì)應(yīng)的ConfigMap或Operator配置實(shí)現(xiàn) oc edit configmap -n openshift-kube-apiserver configmap-name實(shí)操心得OpenShift 4.x的證書管理由Operator自動(dòng)處理但節(jié)點(diǎn)IP變更后Operator可能不會(huì)立即感知?？梢試L試刪除對(duì)應(yīng)的證書Secret讓Operator重新簽發(fā)。但這一步風(fēng)險(xiǎn)較高建議先在測(cè)試環(huán)境驗(yàn)證。3.3.6 更新etcd端點(diǎn)配置# 更新etcd endpoints ConfigMap oc edit configmap -n openshift-etcd etcd-endpoints # 更新etcd serving certs oc get secret -n openshift-etcd etcd-serving-cert -o yaml etcd-cert-backup.yaml # 編輯并更新IP oc apply -f etcd-cert-updated.yaml3.4 證書更新最容易被忽略的關(guān)鍵環(huán)節(jié)OpenShift集群中大量證書的SAN列表中包含節(jié)點(diǎn)IP。改IP后如果證書沒有同步更新會(huì)出現(xiàn)各種TLS握手失敗。需要檢查的證書包括證書名稱所在Namespace用途loadbalancer-serving-certkeyopenshift-kube-apiserverAPI Server負(fù)載均衡etcd-serving-certopenshift-etcdetcd服務(wù)端證書etcd-peer-certopenshift-etcdetcd peer通信kubelet-serving-certopenshift-kubeletkubelet服務(wù)端ovn-certopenshift-ovn-kubernetesOVN組件通信更新證書的通用思路是刪除舊Secret讓Operator重新簽發(fā)。但不同證書的重新簽發(fā)機(jī)制不同有些需要重啟對(duì)應(yīng)組件有些會(huì)自動(dòng)更新。# 以etcd證書為例 oc delete secret -n openshift-etcd etcd-serving-cert oc delete secret -n openshift-etcd etcd-peer-cert # 等待Operator重新簽發(fā) oc get secret -n openshift-etcd -w # 驗(yàn)證新證書SAN oc get secret -n openshift-etcd etcd-serving-cert -o jsonpath{.data.tls\.crt} | base64 -d | openssl x509 -text | grep -A1 Subject Alternative Name4. 驗(yàn)證與排查怎么確認(rèn)集群真的恢復(fù)了4.1 集群健康狀態(tài)全面檢查改完IP后不要急著宣布成功。按以下清單逐項(xiàng)驗(yàn)證# 1. 節(jié)點(diǎn)狀態(tài) oc get nodes -o wide # 所有節(jié)點(diǎn)應(yīng)為Ready狀態(tài)IP地址正確 # 2. 集群Operator狀態(tài) oc get clusteroperators # 所有Operator應(yīng)為AvailableTrue, ProgressingFalse, DegradedFalse # 3. etcd健康狀態(tài) oc exec -n openshift-etcd etcd-node -- etcdctl endpoint health --cluster # 所有端點(diǎn)應(yīng)為healthy # 4. etcd成員列表 oc exec -n openshift-etcd etcd-node -- etcdctl member list -w table # 成員數(shù)量和IP地址正確 # 5. API Server可達(dá)性 oc get --raw /healthz # 應(yīng)返回ok # 6. 集群版本 oc get clusterversion # 應(yīng)顯示正常版本無異常條件 # 7. 核心Pod狀態(tài) oc get pods -n openshift-etcd oc get pods -n openshift-kube-apiserver oc get pods -n openshift-ovn-kubernetes # 所有Pod應(yīng)為Running狀態(tài)4.2 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案節(jié)點(diǎn)NotReadykubelet未正確注冊(cè)journalctl -u kubelet -f檢查kubelet配置和證書Pod網(wǎng)絡(luò)不通OVN隧道端點(diǎn)未更新oc get pods -n openshift-ovn-kubernetes清理OVN狀態(tài)并重啟API Server無法訪問證書SAN不含新IPopenssl x509 -text檢查證書重新簽發(fā)證書etcd成員缺失etcd未重新加入etcdctl member list手動(dòng)添加etcd成員Operator Degraded配置引用舊IPoc describe clusteroperator name更新對(duì)應(yīng)配置DNS解析失敗DNS記錄未更新oc get dns.operator -o yaml更新DNS Operator配置監(jiān)控target丟失Prometheus配置未更新檢查Prometheus target頁面重啟Prometheus或更新配置4.3 幾個(gè)我踩過的坑坑一忘了清理CNI狀態(tài)導(dǎo)致Pod網(wǎng)絡(luò)不通。第一次操作時(shí)節(jié)點(diǎn)重新加入后Pod一直處于ContainerCreating狀態(tài)。排查了半天才發(fā)現(xiàn)是/var/lib/cni/networks/下還存著舊IP的分配記錄。清理后恢復(fù)正常。坑二etcd成員移除后沒有清理數(shù)據(jù)目錄。有一次改完IP后etcd一直起不來日志顯示“member already exists”。原因是舊的數(shù)據(jù)目錄還在etcd以為自己是舊成員。刪除/var/lib/etcd/member/*后解決?？尤C書更新后沒有重啟對(duì)應(yīng)組件。證書Secret更新了但組件還在用舊證書。需要重啟對(duì)應(yīng)的Pod或等待Operator自動(dòng)滾動(dòng)更新。可以通過oc rollout restart手動(dòng)觸發(fā)?？铀腎PI集群刪除Machine后自動(dòng)創(chuàng)建了新節(jié)點(diǎn)。本來想保留原節(jié)點(diǎn)結(jié)果MachineSet自動(dòng)創(chuàng)建了一個(gè)新節(jié)點(diǎn)導(dǎo)致節(jié)點(diǎn)數(shù)量超出預(yù)期。后來先scale down MachineSet再操作。4.4 回滾方案萬一搞砸了怎么辦如果操作過程中出現(xiàn)不可恢復(fù)的問題回滾是最后的手段恢復(fù)etcd快照如果etcd數(shù)據(jù)損壞可以用之前備份的快照恢復(fù)恢復(fù)節(jié)點(diǎn)IP把IP改回原來的地址恢復(fù)配置文件從備份中恢復(fù)kubelet、CNI等配置重新加入集群讓節(jié)點(diǎn)以舊IP重新注冊(cè)回滾的前提是你有完整的備份。這也是為什么我在文章開頭就強(qiáng)調(diào)備份的重要性。5. 一些值得記住的經(jīng)驗(yàn)整個(gè)操作做下來最深的體會(huì)是OpenShift集群改IP不是單純的網(wǎng)絡(luò)操作而是一次涉及證書、etcd、網(wǎng)絡(luò)插件、監(jiān)控棧的系統(tǒng)工程。任何一個(gè)環(huán)節(jié)漏掉都會(huì)在后續(xù)某個(gè)時(shí)刻以意想不到的方式暴露出來。幾個(gè)關(guān)鍵原則值得記住第一能不改就不改。如果只是物理位置變化而網(wǎng)段不變保持IP不變是最省事的方案。改IP的代價(jià)遠(yuǎn)比你想象的大。第二控制平面節(jié)點(diǎn)和工作節(jié)點(diǎn)分開處理。工作節(jié)點(diǎn)改IP相對(duì)獨(dú)立可以逐個(gè)操作控制平面節(jié)點(diǎn)改IP涉及etcd quorum必須謹(jǐn)慎規(guī)劃操作窗口。第三證書是隱藏的雷區(qū)。很多人改完IP后集群表面看起來正常但某些組件之間的TLS通信已經(jīng)悄悄失敗了。定期檢查證書SAN列表是個(gè)好習(xí)慣。第四驗(yàn)證要徹底。不要只看oc get nodes顯示Ready就認(rèn)為成功了。Operator狀態(tài)、etcd健康、Pod網(wǎng)絡(luò)、API Server可達(dá)性、監(jiān)控target每一項(xiàng)都要確認(rèn)。第五備份是底線。etcd快照、配置文件備份、當(dāng)前狀態(tài)記錄這些準(zhǔn)備工作花不了多少時(shí)間但關(guān)鍵時(shí)刻能救命。最后分享一個(gè)小技巧如果你需要在測(cè)試環(huán)境反復(fù)練習(xí)這個(gè)操作可以用一個(gè)三節(jié)點(diǎn)的最小集群1 Master 2 Worker來模擬。把操作步驟寫成腳本每次練習(xí)時(shí)跑一遍熟練之后再到生產(chǎn)環(huán)境操作。這個(gè)操作對(duì)熟練度的要求很高臨時(shí)查文檔和胸有成竹地執(zhí)行心態(tài)和結(jié)果完全不一樣。