1. 動(dòng)手前必須想清楚的事:為什么要改Pod CIDR和Service CIDR先說個(gè)現(xiàn)實(shí)情況:Kubernetes集群的網(wǎng)絡(luò)地址段,最佳的調(diào)整時(shí)機(jī)是在集群創(chuàng)建之前。但實(shí)際運(yùn)維中,總有各種原因讓你不得不在集群運(yùn)行起來之后去動(dòng)這兩個(gè)網(wǎng)段。我自己碰到過的場景大概這么幾類:集群創(chuàng)建初期網(wǎng)段規(guī)劃拍腦袋定得太隨意,結(jié)果Pod一多就把網(wǎng)段地址耗盡;或者是公司網(wǎng)絡(luò)策略調(diào)整,原來用的10.x網(wǎng)段和公司內(nèi)部其他系統(tǒng)的網(wǎng)段沖突了;還有的是多集群統(tǒng)一管理需求,每個(gè)集群的網(wǎng)段必須要納入統(tǒng)一規(guī)劃,結(jié)果老集群的網(wǎng)段不合規(guī)。Pod CIDR管的是集群里每一個(gè)Pod的IP從哪里分配,Service CIDR管的是ClusterIP從哪個(gè)網(wǎng)段來。這兩個(gè)網(wǎng)段一旦定下來,幾乎所有網(wǎng)絡(luò)相關(guān)的組件都會(huì)圍繞它們工作,改起來等于整個(gè)集群的網(wǎng)絡(luò)系統(tǒng)要?jiǎng)右淮未笫中g(shù)。但好消息是:如果你的集群是基于kubeadm部署的標(biāo)準(zhǔn)集群,結(jié)構(gòu)清晰、組件干凈,那么這個(gè)操作是完全可以完成的,而且有相對(duì)穩(wěn)定的操作路徑可以走。如果你用的是云廠商托管的Kubernetes服務(wù),大概率沒有這個(gè)權(quán)限去改,這類操作基本只適用于自建的、可控的集群環(huán)境。在決定動(dòng)手之前,先花一天時(shí)間確認(rèn)自己是真的需要改,而不是懶得重建集群。原因很簡單:整個(gè)過程的停機(jī)時(shí)間、排查成本、出問題回滾的復(fù)雜度,大概率比重建一個(gè)集群要高出不少。如果集群規(guī)模小、應(yīng)用都是無狀態(tài)的,重建新集群然后把應(yīng)用遷過去,可能比你想象中更快更穩(wěn)。但如果集群里有大量的持久化存儲(chǔ)、復(fù)雜的網(wǎng)絡(luò)策略、或者很多依賴固定IP的老應(yīng)用,那就只能選擇在線修改這條路。我自己經(jīng)歷過一次生產(chǎn)環(huán)境的修改,當(dāng)時(shí)集群的大小大概是30多個(gè)節(jié)點(diǎn),Pod數(shù)破千,Service也有幾百個(gè)。整個(gè)操作花了大概4個(gè)小時(shí)的維護(hù)窗口,中間踩了不少坑,有一兩個(gè)坑差點(diǎn)把集群搞癱。這篇文章,就是想把整個(gè)過程的思路、步驟、坑,完整地寫出來。2. 需要?jiǎng)拥兜暮诵慕M件與牽連面分析2.1 哪些組件管著這兩個(gè)網(wǎng)段Pod CIDR和Service CIDR在Kubernetes里不是存到一個(gè)魔法配置文件里就完事的,而是散布在多個(gè)組件的啟動(dòng)參數(shù)、資源對(duì)象的字段和聲明里。先列一下核心組件。kube-controller-manager負(fù)責(zé)管理整個(gè)控制面的控制器邏輯,它有兩個(gè)參數(shù)在這件事里非常關(guān)鍵。--cluster-cidr參數(shù)決定了為每個(gè)節(jié)點(diǎn)分配Pod子網(wǎng)時(shí)的總范圍,換句話說,整個(gè)集群的Pod網(wǎng)段是由它用一把大尺子劃出來的。--service-cluster-ip-range參數(shù)則決定了Service的ClusterIP可以從哪些地址中分配。這兩個(gè)參數(shù)分別控制Pod網(wǎng)段和Service網(wǎng)段的總邊界,是全局配置中的頂層設(shè)置。接著是kube-apiserver,它只涉及Service CIDR,通過--service-cluster-ip-range參數(shù)來決定Service資源在創(chuàng)建時(shí)從哪個(gè)范圍給你分配ClusterIP。這個(gè)參數(shù)在apiserver和controller-manager里必須保持一致,不然會(huì)出現(xiàn)Service創(chuàng)建成功但I(xiàn)P分配不遵循預(yù)期的情況。再往下是kubelet,每個(gè)節(jié)點(diǎn)上的kubelet會(huì)從所在節(jié)點(diǎn)的Pod CIDR子網(wǎng)里給Pod分配IP。Node資源對(duì)象上有個(gè)spec.podCIDR字段,在kubeadm部署的集群中,這個(gè)字段默認(rèn)是kube-controller-manager里的節(jié)點(diǎn)IPAM控制器自動(dòng)分配的。調(diào)用節(jié)點(diǎn)宿主機(jī)的網(wǎng)絡(luò)工具時(shí)會(huì)引用這個(gè)字段,所以這個(gè)字段的值如果和實(shí)際不匹配,Pod網(wǎng)絡(luò)就起不來。然后是kube-proxy。它本身不直接配置CIDR,但它的iptables或IPVS規(guī)則里到處都是基于Service CIDR的判斷邏輯和加載規(guī)則。Service的ClusterIP發(fā)生變化時(shí),如果只改了控制面的參數(shù),但kube-proxy還在用舊網(wǎng)段加載規(guī)則,那網(wǎng)絡(luò)轉(zhuǎn)發(fā)就會(huì)出現(xiàn)各種奇怪的問題。最后是網(wǎng)絡(luò)插件層。無論是Calico、Flannel還是Cilium,它們?cè)诩撼跏蓟臅r(shí)候,都會(huì)讀取配置來指定網(wǎng)絡(luò)通告范圍、IP池范圍、路由發(fā)布策略。這些配置和kube-controller-manager的CIDR設(shè)置必須對(duì)齊。這里用個(gè)生活化類比:整個(gè)集群像一個(gè)小城市的規(guī)劃。Pod CIDR是居民住宅區(qū)的總地塊范圍,Service CIDR是商業(yè)區(qū)的總地塊范圍。政府(控制器)負(fù)責(zé)分割土地,警察局(網(wǎng)絡(luò)插件)負(fù)責(zé)維護(hù)治安巡邏路線。你要把整個(gè)城市的地塊重新劃分,就必須同時(shí)讓規(guī)劃局、政府、警察局、以及每個(gè)建筑物里的物業(yè)(節(jié)點(diǎn)上的kubelet)全部同步到位,不然就會(huì)出現(xiàn)有人按舊地圖辦事的情況。2.2 修改后受影響的資源清單不考慮清楚哪些資源和數(shù)據(jù)會(huì)受到影響,貿(mào)然動(dòng)手改,后面必定是要吃苦頭的。我先梳理一下會(huì)被直接影響的東西。第一類,是所有已經(jīng)創(chuàng)建出來的Service。Service的ClusterIP一旦分配就不會(huì)自動(dòng)變。假如你的Service CIDR原來是10.96.0.0/12,現(xiàn)在已經(jīng)有一堆Service拿到了10.96.x.x的IP。你改成10.100.0.0/16后,這些舊IP的Service不會(huì)自動(dòng)遷移,它們還在舊網(wǎng)段里,但apiserver和kube-proxy已經(jīng)不認(rèn)這個(gè)網(wǎng)段了。結(jié)果就是DNS解析出來的ClusterIP是一個(gè)“外面的世界已經(jīng)不認(rèn)”的地址,流量轉(zhuǎn)發(fā)直接斷掉。第二類,是所有已經(jīng)分配了IP的Pod。每個(gè)節(jié)點(diǎn)上的子網(wǎng)是由節(jié)點(diǎn)IPAM分配的,比如原節(jié)點(diǎn)的Pod CIDR子網(wǎng)是10.244.1.0/24,里面已經(jīng)跑了幾個(gè)Pod,分別拿到了10.244.1.5、10.244.1.6這些地址。你修改總網(wǎng)段之后,如果不處理這些存量Pod,它們會(huì)繼續(xù)占著舊地址運(yùn)行,直到被重建。所以在線修改Pod CIDR的過程,本質(zhì)上就是個(gè)節(jié)點(diǎn)分批驅(qū)逐、然后讓節(jié)點(diǎn)重新獲取新子網(wǎng)、再讓Pod在新子網(wǎng)里重建的過程。第三類,是Kubernetes內(nèi)置的DNS服務(wù)。kube-dns或者CoreDNS本身也是以Pod的形式運(yùn)行的,它也有自己的Service。如果你的Service CIDR一改,CoreDNS的Service ClusterIP也會(huì)變,而集群里所有應(yīng)用是通過這個(gè)ClusterIP去訪問DNS的,如果這個(gè)IP沒同步好,整個(gè)集群的域名解析都會(huì)出問題。第四類,是網(wǎng)絡(luò)插件的狀態(tài)。Calico的IP池?cái)?shù)據(jù)、Flannel在etcd里的網(wǎng)絡(luò)配置,這些東西如果不更新,網(wǎng)絡(luò)插件會(huì)和Kubernetes控制面的認(rèn)知互相打架。最典型的表現(xiàn)就是:Pod成功創(chuàng)建了,但一直處于ContainerCreating狀態(tài),因?yàn)榫W(wǎng)絡(luò)插件不知道自己應(yīng)該給新Pod做網(wǎng)絡(luò)配置。所以,改CIDR不是改一批配置文件重啟組件那么簡單。它實(shí)際上是在做一次有風(fēng)險(xiǎn)的網(wǎng)絡(luò)重構(gòu)。3. 完整執(zhí)行步驟:從環(huán)境備份到集群恢復(fù)3.1 執(zhí)行前的檢查、備份與風(fēng)險(xiǎn)預(yù)估強(qiáng)烈建議在執(zhí)行前把所有可能用到的信息先備份下來,這不是可選項(xiàng),是必選項(xiàng)。第一步,備份etcd。Kubernetes集群的幾乎所有狀態(tài)都存在etcd里,包括所有Service的ClusterIP分配、Node的podCIDR字段、網(wǎng)絡(luò)插件的狀態(tài)。etcd備份是最有底氣的一步,有了它,萬一操作到一半發(fā)現(xiàn)走不通,可以快速回滾到操作前的狀態(tài)。etcd的備份方式看你的部署方式,kubeadm自帶的etcd一般是靜態(tài)Pod,可以直接在etcd Pod里用etcdctl snapshot save命令做快照。注意在快照前先設(shè)置好ETCDCTL_API3環(huán)境變量,防止默認(rèn)走v2協(xié)議。第二步,記錄當(dāng)前所有Service的ClusterIP。用kubectl get svc -A -o wide把每個(gè)名字空間下的Service的ClusterIP、類型、選擇器等信息全部導(dǎo)出來。后面如果你需要手動(dòng)重建Service,這些信息就是依據(jù)。第三步,記錄當(dāng)前所有Node的podCIDR字段。用kubectl get nodes -o json | jq .items[] | {name: .metadata.name, podCIDR: .spec.podCIDR}之類的命令把所有信息記錄到文件里。第四步,和團(tuán)隊(duì)確認(rèn)收益。把所有應(yīng)用都列出來,檢查哪些是無狀態(tài)應(yīng)用、可以接受重建,哪些是有狀態(tài)應(yīng)用、依賴持久化存儲(chǔ)或固定IP。有狀態(tài)應(yīng)用的處理策略是單獨(dú)定義的,不要在維護(hù)窗口里現(xiàn)想。還有一些前置條件必須確認(rèn)。集群一定是kubeadm部署的或者類型接近的標(biāo)準(zhǔn)集群,管理組件是靜態(tài)Pod形式或者systemd服務(wù)形式。如果集群是用云平臺(tái)自帶的部署工具做的,大概率不可改。集群中不能有正在執(zhí)行中的資源變更操作,維護(hù)窗口內(nèi)要禁止其他同事在集群里做任何變更。3.2 控制面組件的修改順序與重啟技巧整個(gè)操作的順序有個(gè)總原則:先改控制面,再改數(shù)據(jù)面;先改配置,再動(dòng)節(jié)點(diǎn);先在測試節(jié)點(diǎn)驗(yàn)證,再逐步擴(kuò)大范圍?？刂泼娴男薷?主要落在/etc/kubernetes/manifests/目錄下的三個(gè)靜態(tài)Pod的YAML文件里,分別是kube-apiserver.yaml、kube-controller-manager.yaml、kube-scheduler.yaml。kube-apiserver.yaml里的--service-cluster-ip-range參數(shù)是必須改的。舉例來說,原來配置是--service-cluster-ip-range10.96.0.0/12,要改成--service-cluster-ip-range10.100.0.0/16,保留好SDN之前的參數(shù),不要?jiǎng)悠渌渲谩ube-controller-manager.yaml里要改兩個(gè)參數(shù):--cluster-cidr控制Pod分配的總網(wǎng)段,--service-cluster-ip-range控制Service網(wǎng)段的范圍。這里有個(gè)非常容易踩的坑:controller-manager和apiserver的Service CIDR參數(shù)必須完全一致,否則會(huì)導(dǎo)致kube-controller-manager在分配Service IP時(shí)產(chǎn)生診斷和分配行為的不一致。改完這兩個(gè)文件之后,kubelet會(huì)檢測到靜態(tài)Pod清單文件發(fā)生變化,自動(dòng)重啟對(duì)應(yīng)組件。這一步是kubeadm的標(biāo)準(zhǔn)機(jī)制,不需要手動(dòng)操作,但要記住一件事:apiserver和controller-manager是分開的靜態(tài)Pod,它們的重啟是逐個(gè)進(jìn)行的。在apiserver重啟期間,所有kubectl操作會(huì)短暫不可用,這是正?，F(xiàn)象。需要特別注意的是kube-apiserver和kube-controller-manager的啟動(dòng)順序。理論上先改哪一個(gè)都行,但實(shí)際操作中我的經(jīng)驗(yàn)是先改controller-manager再改apiserver。因?yàn)閏ontroller-manager重啟失敗的影響小于apiserver重啟失敗的影響,先處理風(fēng)險(xiǎn)小的組件更合理。等apiserver重啟完成后,立刻檢查kubectl get --raw/healthz來確認(rèn)API Server恢復(fù)健康。組件重啟完成后,去etcd里確認(rèn)一下是否已經(jīng)有新的Service IP開始被分配?？梢杂胑tcdctl get /registry/services/specs --prefix的方法去查看,也可以直接創(chuàng)建兩個(gè)測試Service看它們分配到的ClusterIP是不是新網(wǎng)段里的地址。如果新創(chuàng)建的Service拿到的還是舊網(wǎng)段的IP,說明apiserver或controller-manager的修改沒有生效,需要回到配置文件里排查。3.3 處理存量Service的ClusterIP遷移策略控制面組件改完并且確認(rèn)新Service能拿到新網(wǎng)段IP之后,接下來面對(duì)的就是一堆已經(jīng)存在且IP還是舊網(wǎng)段的存量Service。處理思路不復(fù)雜:把Service刪掉,再用新的ClusterIP重新創(chuàng)建。但是這里有個(gè)細(xì)節(jié),直接刪掉Service對(duì)外部服務(wù)的影響是短暫的,因?yàn)镾ervice的Endpoints數(shù)據(jù)可能在刪除的瞬間被清掉,而后端Pod卻還正常活著。對(duì)于集群內(nèi)部應(yīng)用,馬上重建一個(gè)新的同名Service,流量會(huì)無縫切換,因?yàn)樗袘?yīng)用是通過Service名加端口訪問的,不再依賴舊的ClusterIP。但我強(qiáng)烈不建議一條條命令去手動(dòng)操作,即使再小的集群,也不值得把時(shí)間花在不停輸入kubectl命令上。我推薦寫一個(gè)簡單的腳本,把上面第1步記錄的所有Service信息讀進(jìn)來,逐個(gè)處理。腳本的核心邏輯:遍歷全部名字空間下所有非默認(rèn)類型的Service,針對(duì)ClusterIP類型的進(jìn)行重建。先執(zhí)行刪除,再把原Service配置導(dǎo)出成YAML后,把spec.clusterIP字段置空,交給apiserver自動(dòng)分配新網(wǎng)段里的IP。注意保留原來所有的labels、selector、ports和annotations。有個(gè)特殊的Service必須提前想好方案:CoreDNS的Service。等所有存量Service都重建完之后,再單獨(dú)處理CoreDNS。原因是CoreDNS一旦被重建,集群內(nèi)所有DNS解析都會(huì)短暫中斷,而不只是某一個(gè)應(yīng)用的流量中斷,所以要放在最后一步來做,把影響面控制在最短時(shí)間內(nèi)。還有一類特殊情況:給定了固定clusterIP的Service。有些應(yīng)用在設(shè)計(jì)時(shí)會(huì)給Service的clusterIP指定一個(gè)固定值,這類Service依賴舊網(wǎng)段的權(quán)限設(shè)定,是必須修改配置里指定的clusterIP的。先把YAML配置里的spec.clusterIP改成新網(wǎng)段里的一個(gè)可用地址,再執(zhí)行重建。否則apiserver會(huì)直接報(bào)錯(cuò),不會(huì)讓你創(chuàng)建成功。3.4 節(jié)點(diǎn)層面Pod CIDR的遷移:節(jié)點(diǎn)驅(qū)逐與重新分配存量Service的問題處理完之后,接著處理最折騰的部分:節(jié)點(diǎn)Pod網(wǎng)段的遷移。每個(gè)節(jié)點(diǎn)只能處理它自己被分配的Pod子網(wǎng),而每個(gè)節(jié)點(diǎn)的子網(wǎng)一旦分配了就不會(huì)自動(dòng)變。kube-controller-manager的節(jié)點(diǎn)IPAM控制器只會(huì)在節(jié)點(diǎn)剛加入集群、spec.podCIDR字段還沒有值的時(shí)候去分配子網(wǎng),如果已經(jīng)分配了,它不會(huì)自動(dòng)重新分。想要讓節(jié)點(diǎn)拿到新網(wǎng)段的子網(wǎng),思路是:把節(jié)點(diǎn)踢出集群,再讓它重新加入。在kubeadm集群里,這個(gè)過程就是kubectl drain加上重新初始化,但實(shí)際的流程會(huì)更加精細(xì)。我的操作順序是這樣的:標(biāo)記節(jié)點(diǎn)為不可調(diào)度:kubectl cordon node-name驅(qū)逐節(jié)點(diǎn)上的Pod:kubectl drain node-name --ignore-daemonsets --delete-emptydir-data在節(jié)點(diǎn)上重置kubeadm:kubeadm reset清除或修改節(jié)點(diǎn)上網(wǎng)絡(luò)插件的狀態(tài)信息(具體取決于網(wǎng)絡(luò)插件)重新執(zhí)行kubeadm join,把節(jié)點(diǎn)加回集群取消節(jié)點(diǎn)不可調(diào)度標(biāo)記:kubectl uncordon node-name等待該節(jié)點(diǎn)上的Pod全部重建完成驗(yàn)證該節(jié)點(diǎn)的spec.podCIDR已經(jīng)是新網(wǎng)段注意驅(qū)逐時(shí)--ignore-daemonsets是必須的,因?yàn)镈aemonSet的Pod不應(yīng)該也不行被驅(qū)逐,比如網(wǎng)絡(luò)插件的DaemonSet。--delete-emptydir-data也是必須的,否則使用emptyDir的應(yīng)用Pod會(huì)因?yàn)閿?shù)據(jù)需要被刪除而一直處于驅(qū)逐失敗狀態(tài)。這里有一個(gè)沒人會(huì)提前告訴你的大坑:節(jié)點(diǎn)的驅(qū)逐順序要考慮網(wǎng)絡(luò)插件本身。Calico或Flannel這類網(wǎng)絡(luò)插件是以DaemonSet形式跑在每個(gè)節(jié)點(diǎn)上的,它們的DaemonSet Pod天然不可被驅(qū)逐,但這不代表網(wǎng)絡(luò)插件沒有狀態(tài)需要清理。拿Calico舉例,如果節(jié)點(diǎn)上的calico-node和calico-kube-controllers正常工作,你在節(jié)點(diǎn)上執(zhí)行了kubeadm reset,節(jié)點(diǎn)會(huì)脫離集群,但是Calico的IP池里可能還殘留著這個(gè)節(jié)點(diǎn)之前分配過的Pod子網(wǎng)狀態(tài)。如果不清理,節(jié)點(diǎn)重新加入時(shí),IPAM控制器會(huì)嘗試給同一個(gè)節(jié)點(diǎn)分配新的子網(wǎng),這時(shí)Calico的數(shù)據(jù)存儲(chǔ)里可能存在沖突,節(jié)點(diǎn)上的新Pod會(huì)一直拿不到IP,一直處于ContainerCreating。所以我推薦的處理方式:在節(jié)點(diǎn)被重置之前,要把Calico對(duì)該節(jié)點(diǎn)的IP池分配信息清掉。Calico通過CRD資源做IP池管理時(shí),通常是直接刪除Node資源中對(duì)應(yīng)的BGP Peer和IP池綁定記錄。一般通過calicoctl node status去查看和清理,或者在節(jié)點(diǎn)重新加入后手動(dòng)設(shè)置跨越現(xiàn)有池和新的池之間的路由。這一部分非常依賴你用的網(wǎng)絡(luò)插件,沒法給出通用命令。但通用思路是:保證網(wǎng)絡(luò)插件認(rèn)為這個(gè)節(jié)點(diǎn)是一個(gè)全新的、沒有歷史包袱的節(jié)點(diǎn)。如果集群規(guī)模不大,還有一種不走kubeadm reset的做法:手動(dòng)改Node的spec.podCIDR字段,然后讓kubelet重新初始化網(wǎng)絡(luò)。這個(gè)方法理論上省事,但實(shí)際操作中踩坑無數(shù),原因是kubelet初始化時(shí)的很多網(wǎng)絡(luò)判斷邏輯是基于節(jié)點(diǎn)已有的子網(wǎng)配置來的,你強(qiáng)行改了字段但不清理舊網(wǎng)絡(luò)接口和路由表,大概率起不來。除非你非常了解你的網(wǎng)絡(luò)插件和kubelet的網(wǎng)絡(luò)初始化邏輯,否則我強(qiáng)烈不推薦手動(dòng)改字段,老老實(shí)實(shí)走驅(qū)逐、重置、重新加入的流程更安全。重新加入節(jié)點(diǎn)之后,立刻用kubectl get node node-name -o jsonpath{.spec.podCIDR}去檢查新子網(wǎng),確認(rèn)是新網(wǎng)段。然后檢查節(jié)點(diǎn)上的Pod是不是都從新子網(wǎng)里拿到的IP,可以用kubectl get pods -A -o wide | grep node-name確認(rèn)。3.5 網(wǎng)絡(luò)插件的同步調(diào)整網(wǎng)絡(luò)插件層的調(diào)整是整個(gè)操作里最容易被忽視、后果卻最嚴(yán)重的部分。先說Flannel的情況。Flannel的配置是存在ConfigMap里的,而且實(shí)際生效的配置在etcd里。如果你用的是kubeadm自帶的Flannel方案,網(wǎng)絡(luò)配置在kube-flannel-cfg這個(gè)ConfigMap里,但真正驅(qū)動(dòng)flanneld的網(wǎng)絡(luò)配置是存在etcd里的一份JSON配置。最穩(wěn)妥的操作是:先把ConfigMap里的Network字段改成新網(wǎng)段,再刪除Flannel的DaemonSet Pod,讓所有節(jié)點(diǎn)的flanneld用新配置重啟一遍。但這還不夠,Flannel會(huì)在每個(gè)節(jié)點(diǎn)上創(chuàng)建cni0網(wǎng)橋和flannel.1隧道接口,這些老接口如果不清理,新配置起來時(shí)可能會(huì)判斷“接口已存在”而跳過重新配置,結(jié)果就是新Pod拿到新網(wǎng)段的IP,但流量完全不通。Calico的情況稍微復(fù)雜一點(diǎn)。Calico用IPPool CRD定義IP池,如果Pod CIDR改了,需要?jiǎng)?chuàng)建對(duì)應(yīng)新網(wǎng)段的IPPool,并且要處理IPAM的地址分配序列。在節(jié)點(diǎn)重新加入集群之前,需要先配置好新網(wǎng)段的IPPool,否則calico-ipam給節(jié)點(diǎn)上的Pod分配IP時(shí)會(huì)發(fā)現(xiàn)沒有對(duì)應(yīng)的池可用。Cilium也比較類似,它不一定用CRD管理網(wǎng)絡(luò)范圍,有些場景直接讀kube-controller-manager的--cluster-cidr來綁定規(guī)則。這種情況下,只要控制面的配置改對(duì)了,kube-proxy也改對(duì)了,網(wǎng)絡(luò)插件會(huì)自動(dòng)基于新CIDR工作。但如果你在Cilium里顯式配置過cluster-pool-ipv4-cidr,就必須同步修改。這里給一個(gè)通用的判斷思路:所有網(wǎng)絡(luò)插件本質(zhì)上都在回答“集群的Pod網(wǎng)段范圍是多少”和“某個(gè)節(jié)點(diǎn)負(fù)責(zé)哪個(gè)子網(wǎng)”這兩個(gè)問題。你的調(diào)優(yōu)目標(biāo)就是讓網(wǎng)絡(luò)插件對(duì)這兩個(gè)問題的回答,和Kubernetes控制面的回答保持一致。不一致的表現(xiàn)通常很簡單直接:Pod一直處于ContainerCreating,報(bào)錯(cuò)信息指向網(wǎng)絡(luò)配置沖突。3.6 kube-proxy與各節(jié)點(diǎn)參數(shù)的同步處理kube-proxy的運(yùn)行模式通常不影響修改后的行為,它的配置是動(dòng)態(tài)監(jiān)聽Service和Endpoint,基于apiserver的數(shù)據(jù)生成轉(zhuǎn)發(fā)規(guī)則。理論上,只要控制面的Service CIDR改了,kube-proxy會(huì)自動(dòng)適配新規(guī)則。但是這里有潛在問題:kube-proxy在啟動(dòng)時(shí)通過--cluster-cidr參數(shù)判斷是否需要開啟--masquerade-all等特性時(shí)用的網(wǎng)段還是舊值。所以我在操作中的做法是:改完控制面之后,順手把每個(gè)節(jié)點(diǎn)的kube-proxy配置文件里的CIDR字段同步改掉。kube-proxy的配置默認(rèn)在kube-system名字空間下的kube-proxy這個(gè)ConfigMap里,里面有個(gè)clusterCIDR字段,把它改成新的Pod CIDR即可。改了ConfigMap后,重啟所有節(jié)點(diǎn)的kube-proxy Pod,讓它們重新加載配置。這一步不做的后果是:節(jié)點(diǎn)上kube-proxy還是用舊網(wǎng)段作為判斷流量是否需要做NAT的基準(zhǔn),新網(wǎng)段的Pod流量可能會(huì)出現(xiàn)源IP被錯(cuò)誤處理的狀況,表現(xiàn)為跨節(jié)點(diǎn)訪問Service正常,但Pod訪問外部網(wǎng)絡(luò)時(shí)源IP不對(duì),導(dǎo)致很多第三方服務(wù)的回調(diào)、日志、狀態(tài)判斷全部出錯(cuò)。3.7 集群內(nèi)應(yīng)用服務(wù)的最終驗(yàn)證組件和節(jié)點(diǎn)都處理完之后,不代表就完事了。驗(yàn)證環(huán)節(jié)是整個(gè)流程里最后一道保險(xiǎn)。我的驗(yàn)證清單大概是這樣:先驗(yàn)證基礎(chǔ)網(wǎng)絡(luò):在兩個(gè)不同的節(jié)點(diǎn)上分別創(chuàng)建兩個(gè)測試Pod,互相ping對(duì)方的Pod IP,確認(rèn)跨節(jié)點(diǎn)Pod通信正常。再驗(yàn)證Service訪問:部署一個(gè)簡單的測試應(yīng)用和Service,在集群內(nèi)使用kubectl run創(chuàng)建一個(gè)臨時(shí)的curl Pod,curl測試Service的ClusterIP加端口,確認(rèn)Service轉(zhuǎn)發(fā)正常,CoreDNS域名解析正常。接著驗(yàn)證外部訪問:如果集群里有Ingress或者LoadBalancer類型的Service,必須逐個(gè)驗(yàn)證。NodePort類型的Service也要測試,因?yàn)镹odePort的端口范圍仍然需要和Service的ClusterIP通過kube-proxy規(guī)則配合,這里出問題影響面比較大。然后要驗(yàn)證有狀態(tài)應(yīng)用:如果你的集群里有StatefulSet,它有穩(wěn)定的網(wǎng)絡(luò)標(biāo)識(shí)和存儲(chǔ)卷,重建后要確認(rèn)PVC綁定正常、數(shù)據(jù)完整性沒有受到損害。這一步容易出現(xiàn)各種存儲(chǔ)層的問題。最后驗(yàn)證監(jiān)控和日志,這個(gè)很多人會(huì)忘記。監(jiān)控Agent(比如node-exporter的DaemonSet)訪問apiserver的方式、日志采集Agent的端點(diǎn)配置,這些不會(huì)因?yàn)镃IDR變化自動(dòng)更新,如果它們的配置里寫死了舊IP,會(huì)一直報(bào)錯(cuò)。我見過某次操作之后監(jiān)控?cái)?shù)據(jù)完全中斷的情況,原因就是Prometheus的配置文件里寫死了一個(gè)舊網(wǎng)段的Service ClusterIP。4. 實(shí)際操作過程中的免坑指南4.1 執(zhí)行流程的時(shí)間表與回滾方案整個(gè)過程的時(shí)間節(jié)奏,按我做過一次的規(guī)模(30節(jié)點(diǎn)、Pod上千、Service幾百)來算:控制面修改與驗(yàn)證約40分鐘,存量Service重建約30分鐘,節(jié)點(diǎn)逐個(gè)遷移約2.5小時(shí)(每個(gè)節(jié)點(diǎn)約5到8分鐘),網(wǎng)絡(luò)插件與kube-proxy調(diào)整約30分鐘,最終驗(yàn)證約30分鐘?？傆?jì)4小時(shí)左右,這已經(jīng)是比較理想的情況。如果中間出現(xiàn)意外,比如節(jié)點(diǎn)驅(qū)逐卡住、網(wǎng)絡(luò)插件狀態(tài)清理不干凈,時(shí)間會(huì)翻倍。所以維護(hù)窗口至少準(zhǔn)備6個(gè)小時(shí),并且要有一個(gè)明確的回滾機(jī)制?；貪L的前提就是etcd快照。什么情況下要回滾?我自己的判斷標(biāo)準(zhǔn)是:apiserver或controller-manager重啟后一直不健康,且15分鐘內(nèi)無法解決;或者前幾個(gè)節(jié)點(diǎn)驅(qū)逐后新子網(wǎng)分配異常,Pod創(chuàng)建不起來,說明網(wǎng)絡(luò)插件控制面和節(jié)點(diǎn)對(duì)齊的過程存在根本性缺陷;或者發(fā)生了數(shù)據(jù)面網(wǎng)絡(luò)大面積中斷,導(dǎo)致核心業(yè)務(wù)長時(shí)間不可用。回滾操作本身不復(fù)雜:停掉kubelet,恢復(fù)etcd快照,再把控制面組件配置恢復(fù)原樣,所有節(jié)點(diǎn)上的kubelet網(wǎng)絡(luò)接口全部清理后重啟kubelet。但回滾也不便宜,它基本等于一次集群重啟,所以這個(gè)決策要果斷,不要猶豫。改了CIDR最怕的就是“再試著調(diào)調(diào)”,這和在高速公路上邊開車邊修方向盤沒區(qū)別。4.2 我踩過的幾個(gè)經(jīng)典坑第一個(gè)坑是Drain節(jié)點(diǎn)時(shí),有Pod卡在Terminating。原因通常是這個(gè)Pod的終止依賴某個(gè)已刪除的Service或者PVC,驅(qū)逐過程一直握手失敗。解決辦法是檢查這個(gè)Pod的事件,找到依賴關(guān)系,把依賴問題處理完后重新驅(qū)逐。不要一開始就--force,強(qiáng)制刪除Pod可能讓業(yè)務(wù)徹底中斷。第二個(gè)坑是節(jié)點(diǎn)重新加入后,kubelet反復(fù)重啟。原因通常是kubeadm reset之后,節(jié)點(diǎn)上留有舊的CA證書或kubelet配置,導(dǎo)致新的kubeadm join生成的證書和apiserver不匹配。解決辦法是在重置后清理干凈/etc/kubernetes/目錄、/var/lib/kubelet/目錄,必要時(shí)也把/etc/cni/net.d/目錄下的網(wǎng)絡(luò)插件配置一起清掉再重新加入。第三個(gè)坑是網(wǎng)絡(luò)插件的IPv4Pool殘留。我在處理一個(gè)Calico集群時(shí)就遇到這個(gè),新節(jié)點(diǎn)重新加入集群后,節(jié)點(diǎn)上的Pod報(bào)Calico IPAM: no IPs available的錯(cuò)誤。查下來是Calico的block還在被舊節(jié)點(diǎn)信息引用,舊節(jié)點(diǎn)信息沒有清理干凈。解決方法是刪除Calico的IPAM數(shù)據(jù)中對(duì)該節(jié)點(diǎn)的引用,或者用calicoctl把對(duì)應(yīng)的IPPool和block一并刪除再重新放。第四個(gè)坑比較隱蔽:部分應(yīng)用Pod里寫死了舊網(wǎng)段的IP。比如某個(gè)中間件的配置里指定了舊網(wǎng)段的數(shù)據(jù)庫Pod IP,節(jié)點(diǎn)驅(qū)逐重建后,數(shù)據(jù)庫的Pod拿到了新IP,但應(yīng)用的配置還指向舊IP,應(yīng)用自然連不上數(shù)據(jù)庫。這個(gè)只能在遷移前就做排查,把所有應(yīng)用配置里的硬編碼IP找出來,在維護(hù)窗口開始前就發(fā)公告讓相關(guān)應(yīng)用Owner們處理好自動(dòng)重連邏輯。4.3 什么時(shí)候應(yīng)該放棄在線修改最后一定要說清楚一個(gè)現(xiàn)實(shí):如果集群里有下面這幾個(gè)條件,不太建議用在線修改的方案。集群里有大量依賴固定IP訪問的應(yīng)用,并且這些應(yīng)用沒有配置中心化管理的配置;集群里存在比較多的StatefulSet且每個(gè)Pod的PVC沒有做異地備份;網(wǎng)絡(luò)插件版本的定制化程度很高,修改和調(diào)試成本難以預(yù)估;或者集群規(guī)模巨大節(jié)點(diǎn)的數(shù)量超過50個(gè)。在這些情況下,我個(gè)人的傾向是明確告訴團(tuán)隊(duì):重建集群,做應(yīng)用遷移。時(shí)間成本不一定更高,穩(wěn)定性卻高出很多。在線改CIDR真正合適的前提是:應(yīng)用無狀態(tài)化程度高、網(wǎng)絡(luò)配置全部走Service和DNS的抽象層、網(wǎng)絡(luò)插件是常見的標(biāo)準(zhǔn)組件、團(tuán)隊(duì)手里有完整的配置管理能力。這四個(gè)條件缺一個(gè),風(fēng)險(xiǎn)都會(huì)讓操作收益變得非常不值得。5. 操作后的長期影響與收尾工作操作完成且業(yè)務(wù)驗(yàn)證無異常之后,還有幾個(gè)長期項(xiàng)需要做。第一,把所有集群的CIDR規(guī)劃文檔同步更新,避免后續(xù)建設(shè)者不知道新網(wǎng)段規(guī)劃。第二,將所有組件的配置參數(shù)檢查一遍,確保沒有遺漏的舊網(wǎng)段引用。第三,把這次操作的復(fù)盤記錄寫好,把所有踩過的坑和對(duì)應(yīng)解法整理成文檔,方便未來有人遇到同樣的問題時(shí)有據(jù)可查。此外,把etcd的新快照再備份一份,確保當(dāng)前狀態(tài)有一個(gè)安全備份點(diǎn)。這一步很多人做完操作之后會(huì)忽略,結(jié)果下次出問題時(shí)發(fā)現(xiàn)備份的還是改CIDR之前的狀態(tài),恢復(fù)反而一個(gè)大回退。最后再發(fā)一個(gè)有價(jià)值的經(jīng)驗(yàn):不管哪個(gè)組件出了問題,排查的第一命令永遠(yuǎn)是journalctl -u kubelet -f或者查看對(duì)應(yīng)靜態(tài)Pod的日志,而不是到處猜。網(wǎng)絡(luò)問題排查的第一命令永遠(yuǎn)是ip route、ip addr和iptables -t nat -L -n,把實(shí)際路由和規(guī)則先看一遍,再去看配置。大多數(shù)“配置沒問題”的網(wǎng)絡(luò)故障,本質(zhì)上都是實(shí)際生效的東西和配置里寫的東西不一致而已。改CIDR這件事,風(fēng)險(xiǎn)高但路徑清晰。做好每一步的確認(rèn),控制好節(jié)奏,列清楚回滾方案,應(yīng)對(duì)好細(xì)節(jié)問題,是可以在不重建集群的前提下完成的。但作為運(yùn)維,真正重要的不是“能不能改”,而是“值不值得改”,以及“如果真的改掛了,能不能在一小時(shí)以內(nèi)恢復(fù)”。把這兩個(gè)問題想清楚了,再動(dòng)手,你的勝算就大很多。