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