最近我把一套跑在RKE集群上的Rancher管理平臺(tái)從舊機(jī)器整體遷到了新環(huán)境。Rancher本身不復(fù)雜復(fù)雜的是它管理的一堆下游集群——每個(gè)下游集群里的agent都只認(rèn)原來(lái)的server-url和證書。遷移過(guò)程中先后經(jīng)歷了備份、恢復(fù)、agent重連、證書替換最后還要處理一堆歷史配置殘留。這篇文章把我這次基于RKE部署的Rancher管理平臺(tái)遷移的完整過(guò)程、關(guān)鍵命令和后來(lái)復(fù)盤出來(lái)的幾個(gè)坑都寫出來(lái)希望給要做同樣事情的人一個(gè)參考路徑。全文涉及Rancher版本與K8s版本的對(duì)齊、backup operator備份恢復(fù)、下游集群重連驗(yàn)證以及幾個(gè)我在遷移過(guò)程中踩過(guò)的典型問(wèn)題。1. 先想明白R(shí)KE架構(gòu)下Rancher遷移到底在遷什么1.1 RKE與Rancher的分工梳理RKERancher Kubernetes Engine是一個(gè)通過(guò)一條命令拉起Kubernetes集群的工具它用cluster.yml描述節(jié)點(diǎn)信息和集群配置執(zhí)行rke up后生成一套可用的K8s集群。而Rancher是跑在這套集群上的容器化應(yīng)用通過(guò)helm chart安裝到cattle-system命名空間用來(lái)管理它所在的local集群以及其他外部集群。這兩個(gè)層次一定要分清楚RKE負(fù)責(zé)“蓋房子”Rancher負(fù)責(zé)“住進(jìn)去做管理”。遷移的時(shí)候房子要重新蓋但里面的家具、賬本、住戶登記信息都要盡量原樣搬過(guò)去。這里的“賬本”主要就是Rancher在K8s里持久化的各種自定義資源CRD、configmap、secret、RBAC以及底層etcd中的狀態(tài)。1.2 為什么不能直接“打包拷貝”很多人第一次接觸Rancher遷移時(shí)會(huì)想Rancher不是一堆容器嗎把鏡像、數(shù)據(jù)目錄復(fù)制過(guò)去不就行了實(shí)際上Rancher管理平臺(tái)的狀態(tài)高度依賴Kubernetes的API對(duì)象和etcd它內(nèi)部還有多個(gè)controller通過(guò)watch機(jī)制同步信息。直接拷貝鏡像和靜態(tài)文件完全沒(méi)有意義因?yàn)镽ancher生成的密碼、token、私鑰存在secret里單獨(dú)復(fù)制一份出來(lái)并不代表可用對(duì)象之間的引用關(guān)系必須一起帶過(guò)去。下游集群通過(guò)agent和Rancher保持心跳agent里記錄的是server-url和證書信息單純復(fù)制會(huì)導(dǎo)致agent指向錯(cuò)誤的地址。Kubernetes本身是分布式系統(tǒng)它的etcd數(shù)據(jù)包含節(jié)點(diǎn)IP、證書等不能把一套集群的etcd直接丟給另一套集群用。可以把這個(gè)過(guò)程類比成搬家搬家具容易但你得先把戶籍、水電燃?xì)膺@些登記信息同步過(guò)去不然新家里通電通水了原來(lái)的賬單還是寄到舊地址。遷移的本質(zhì)是“數(shù)據(jù)、身份、網(wǎng)絡(luò)信任”三者的整體搬遷。1.3 遷移完成后的目標(biāo)狀態(tài)遷移完成后我們希望達(dá)到如下?tīng)顟B(tài)新集群上的Rancher版本和舊環(huán)境一致或者至少滿足升級(jí)兼容矩陣。登錄賬號(hào)、權(quán)限角色、全局設(shè)置、用戶密碼全部保留。下游集群仍然被Rancher管理agent自動(dòng)重新注冊(cè)。審計(jì)日志、監(jiān)控配置等可選組件按需保留。為此遷移前需要把舊環(huán)境的信息完整記錄下來(lái)建議用表格逐項(xiàng)填寫Rancher版本、Helm chart版本、K8s版本、RKE版本、server-url、證書類型、外部認(rèn)證方式、下游集群數(shù)量、以及是否有自定義的CRD或存儲(chǔ)配置。記錄項(xiàng)示例值用途rancher/rancher鏡像版本v2.7.8新環(huán)境安裝時(shí)需要對(duì)應(yīng)helm chart版本103.1.5避免restore時(shí)版本沖突rke --versionv1.4.10新環(huán)境RKE版本對(duì)齊server-urlhttps://rancher.example.com下游agent連接的關(guān)鍵證書類型受信CA證書 / 自簽證書決定是否要遷移私鑰認(rèn)證方式本地用戶 / LDAP / OIDC決定外部認(rèn)證是否需要二次配置下游集群數(shù)量7個(gè)遷移后驗(yàn)證清單1.4 常見(jiàn)遷移方案對(duì)比方案ARancher backup-restore-operator備份恢復(fù)。在舊集群安裝backup operator創(chuàng)建Backup CR把Rancher關(guān)鍵資源resourceSet備份到S3兼容對(duì)象存儲(chǔ)或本地路徑新環(huán)境反向操作Restore。優(yōu)點(diǎn)是備份粒度精準(zhǔn)、官方維護(hù)、適合遷移場(chǎng)景。缺點(diǎn)是這個(gè)工具只覆蓋Rancher自身狀態(tài)底層K8s的網(wǎng)絡(luò)插件、ingress等需要另建。方案B對(duì)承載Rancher的K8s集群做etcd快照然后在新環(huán)境用相同的RKE配置重建集群再恢復(fù)快照。優(yōu)點(diǎn)是Rancher本身幾乎無(wú)感知。缺點(diǎn)是對(duì)新舊環(huán)境的pod CIDR、service網(wǎng)段、甚至node名稱一致性要求很高靈活性差不太適合換機(jī)器、換機(jī)房的場(chǎng)景。方案C全新部署Rancher再手工配置或通過(guò)API遷移用戶、項(xiàng)目。優(yōu)點(diǎn)是環(huán)境干凈。缺點(diǎn)是工作量大、極易遺漏而且有很多不可復(fù)制的內(nèi)容比如agent注冊(cè)token、審計(jì)日志歷史、部分CRD狀態(tài)。方案優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景backup operator遷移官方維護(hù)、粒度精準(zhǔn)、狀態(tài)完整只覆蓋Rancher資源換機(jī)器、換機(jī)房、版本不變或小版本升級(jí)etcd快照恢復(fù)整個(gè)集群狀態(tài)整體搬遷對(duì)網(wǎng)絡(luò)段、節(jié)點(diǎn)名要求高純硬件遷移且網(wǎng)絡(luò)規(guī)劃不變?nèi)虏渴鹗止づ渲脽o(wú)歷史包袱工作量大易遺漏舊環(huán)境已不可用且業(yè)務(wù)允許重建我這次采用的是方案A為主B作為備選兜底。這也是官方推薦路徑下文主要圍繞它展開(kāi)。2. 動(dòng)手前先把家底盤清楚必須帶走的數(shù)據(jù)和狀態(tài)2.1 資源清單不止cattle-system一個(gè)命名空間Rancher在K8s里并不是只往cattle-system里寫數(shù)據(jù)。備份的時(shí)候至少要考慮這些對(duì)象cattle-system命名空間Rancher pod、service、相關(guān)configmap。cattle-pipeline流水線相關(guān)配置。cattle-logging、cattle-monitoring、cattle-alerting日志、監(jiān)控、告警配置如果沒(méi)啟用就沒(méi)有。management.cattle.io組下的CRDCluster、Project、User、GlobalRole、Setting、Token等。secret包括admin密碼hash、服務(wù)賬戶token、agent注冊(cè)token等。RBAC自定義的角色綁定和權(quán)限設(shè)置。使用backup operator時(shí)它默認(rèn)的resourceSet已經(jīng)覆蓋了這些主流對(duì)象。實(shí)際操作中我在Backup CR里顯式使用官方預(yù)置的resourceSetName這樣不容易漏。不建議手工指定一堆命名空間因?yàn)楹苋菀茁┑裟硞€(gè)CRD等恢復(fù)后缺數(shù)據(jù)再排查就很被動(dòng)了。2.2 版本和配置信息盤點(diǎn)遷移前必須記下來(lái)除了數(shù)據(jù)還有幾類配置信息必須提前記錄。否則遷移到一半會(huì)發(fā)現(xiàn)server-url指向舊地址AI大模型都救不了你rancher/rancher鏡像版本以及helm chart版本用helm ls -n cattle-system查看。RKE版本用rke --version查看。K8s版本用kubectl version查看或者看RKE cluster.yml里的kubernetes_version。server-url在Rancher UI的全局設(shè)置里查看這是下游agent連接的關(guān)鍵。認(rèn)證方式如果用的是本地用戶備份里有密碼hash恢復(fù)后原密碼仍可用如果接的是外部LDAP或OIDC遷移后需要在新環(huán)境重新配置認(rèn)證提供方地址或信任關(guān)系。ingress證書類型自簽還是受信CA簽發(fā)。如果在遷移中更換域名或IP證書也要同步更新。強(qiáng)烈建議把上面這些寫到一個(gè)固定文檔里遷移過(guò)程中每一步都對(duì)照著核對(duì)。我的經(jīng)驗(yàn)是文檔里漏掉一個(gè)版本號(hào)后面恢復(fù)時(shí)可能多花兩個(gè)小時(shí)來(lái)排查。2.3 備份實(shí)操安裝backup operator并創(chuàng)建Backup CRbackup operator通過(guò)helm chart安裝命名空間是rancher-backup。安裝完成后創(chuàng)建一個(gè)Backup CR結(jié)構(gòu)類似apiVersion: resources.cattle.io/v1 kind: Backup metadata: name: rancher-backup spec: storageLocation: s3: bucketName: my-rancher-backups region: ap-east-1 endpoint: s3.example.com resourceSetName: rancher-resource-set encryptionConfigSecretName: backup-encryption-secret幾個(gè)字段的意圖說(shuō)下storageLocation備份文件存到S3兼容對(duì)象存儲(chǔ)也可以配置local存到節(jié)點(diǎn)路徑。生產(chǎn)環(huán)境建議S3兼容存儲(chǔ)方便新環(huán)境讀取。encryptionConfigSecretName可選。如果舊環(huán)境有敏感數(shù)據(jù)需要加密就得用同樣的加密配置否則新環(huán)境restore時(shí)解不開(kāi)。resourceSetName官方預(yù)置的資源集默認(rèn)使用rancher-resource-set。創(chuàng)建后觀察狀態(tài)等狀態(tài)變?yōu)镃ompleted表示備份完成。備份文件會(huì)生成一個(gè)tar.gz包里面是包含Rancher資源和CRD定義的一個(gè)清單。備份成功后確認(rèn)一下輸出的文件名后面Restore要用到。提示關(guān)于加密secret如果舊集群里配置了新集群安裝backup operator時(shí)也要把這個(gè)secret一起建出來(lái)并且內(nèi)容一致否則restore會(huì)直接失敗。這是最容易忽略的坑。2.4 備份完成后的驗(yàn)證備份狀態(tài)Completed不代表萬(wàn)事大吉。建議先下載備份文件確認(rèn)tar.gz包大小不是0字節(jié)再用tar解壓看一眼里面的資源列表。我遇到過(guò)備份文件生成成功但因?yàn)镾3接口兼容問(wèn)題文件內(nèi)容是殘缺的到restore階段才暴露。提前解壓驗(yàn)證幾秒的事能省下后面一整天的排查。3. 新環(huán)境搭建RKE拉起集群時(shí)的版本對(duì)齊與資源規(guī)劃3.1 版本對(duì)齊是遷移的第一原則先決定新環(huán)境的K8s版本。原則是新集群的版本與舊集群一致或者至少位于Rancher版本對(duì)應(yīng)的支持矩陣之內(nèi)。版本差太大的話Rancher chart在restore過(guò)程中可能出現(xiàn)CRD版本沖突、API group變更等問(wèn)題導(dǎo)致升級(jí)不動(dòng)、pod起不來(lái)。RKE本身也分版本舊環(huán)境用哪個(gè)版本生成的RKE新環(huán)境最好也用同一個(gè)版本。RKE生成的集群里kube-system下的一些組件版本和配置會(huì)有細(xì)微差異版本不一致會(huì)加大后面排查的難度。另外如果這次遷移同時(shí)想升級(jí)Rancher大版本我的建議是分兩步走先按舊版本遷移穩(wěn)定運(yùn)行后再做升級(jí)。不要邊遷移邊升級(jí)一次只引入一個(gè)變量否則出了問(wèn)題你不知道是遷移導(dǎo)致的還是升級(jí)導(dǎo)致的。3.2 cluster.yml的關(guān)鍵配置保持一致性在RKE集群的cluster.yml里有幾個(gè)參數(shù)會(huì)影響Kubernetes網(wǎng)絡(luò)層和證書層遷移時(shí)盡量跟舊環(huán)境保持一致network.plugin最常用canal或flannel新舊環(huán)境建議一致。services.kube-controller的service_cluster_ip_range與cluster_cidr集群內(nèi)部地址段建議保持與舊集群一致。如果變了Rancher里已存在的服務(wù)路由和網(wǎng)絡(luò)策略可能會(huì)出問(wèn)題。kubernetes_version保持同版本。nodes配置可以用新的主機(jī)名和IP這是允許變化的因?yàn)镵8s節(jié)點(diǎn)身份會(huì)重新生成。老規(guī)矩改節(jié)點(diǎn)IP沒(méi)問(wèn)題但pod CIDR和service網(wǎng)段不能隨意改遷移后很多已創(chuàng)建的服務(wù)地址和網(wǎng)絡(luò)策略都是基于原網(wǎng)段的。3.3 新環(huán)境節(jié)點(diǎn)資源規(guī)劃Rancher管理平臺(tái)自身不重但也不要太寒酸。承載Rancher的K8s集群至少用3個(gè)節(jié)點(diǎn)組成etcdcontrolplane角色生產(chǎn)建議每個(gè)節(jié)點(diǎn)4核8G起步磁盤用SSD并且40G以上。如果還要在下游集群上使用監(jiān)控、告警資源再往上浮。RKE要求節(jié)點(diǎn)能訪問(wèn)公開(kāi)鏡像倉(cāng)庫(kù)或者提前把鏡像推到私有倉(cāng)庫(kù)并在cluster.yml里配置registry認(rèn)證。新環(huán)境的節(jié)點(diǎn)時(shí)間同步也一定要做好K8s證書和agent錨定時(shí)間偏差太大會(huì)直接握手失敗。這些基礎(chǔ)項(xiàng)出了問(wèn)題后面恢復(fù)Rancher時(shí)出現(xiàn)的報(bào)錯(cuò)會(huì)非常奇怪。3.4 初始化后先做基礎(chǔ)驗(yàn)證別急著恢復(fù)執(zhí)行rke up之后先用kubectl get nodes -o wide確認(rèn)所有節(jié)點(diǎn)Ready再用kubectl get pods -A確認(rèn)kube-system和ingress-nginx的pod全部Running。這時(shí)候先不要急著裝Rancher或者做restore先把網(wǎng)絡(luò)層驗(yàn)證一遍。比如隨便跑一個(gè)測(cè)試服務(wù)確認(rèn)集群內(nèi)部DNS正常、pod之間可以通信。等基礎(chǔ)集群穩(wěn)定后再用helm安裝Rancher chart。安裝時(shí)用一個(gè)臨時(shí)的bootstrapPassword即可后續(xù)會(huì)被備份數(shù)據(jù)覆蓋。4. 恢復(fù)數(shù)據(jù)那一刻backup operator restore實(shí)操細(xì)節(jié)4.1 恢復(fù)前置準(zhǔn)備新環(huán)境恢復(fù)之前先把backup operator裝上命名空間同樣是rancher-backup。這一步和舊環(huán)境安裝基本一致需要注意兩點(diǎn)如果備份時(shí)用了encryptionConfigSecretName新環(huán)境要先創(chuàng)建同名secret內(nèi)容保持一致。如果備份文件在S3兼容對(duì)象存儲(chǔ)新環(huán)境要確保網(wǎng)絡(luò)可以訪問(wèn)這個(gè)地址尤其是私有化部署的對(duì)象存儲(chǔ)防火墻規(guī)則要提前配好。4.2 restore CR的編寫restore CR示例apiVersion: resources.cattle.io/v1 kind: Restore metadata: name: rancher-restore spec: backupFilename: rancher-backup-xxx.tar.gz storageLocation: s3: bucketName: my-rancher-backups region: ap-east-1 endpoint: s3.example.com resourceSetName: rancher-resource-set prune: true幾個(gè)字段的意圖backupFilename必須指向備份時(shí)生成的文件名。prune恢復(fù)時(shí)是否刪除目標(biāo)集群中已有的、不在備份里的Rancher資源。強(qiáng)烈建議設(shè)為true否則新環(huán)境安裝Rancher chart時(shí)會(huì)預(yù)創(chuàng)建一些默認(rèn)對(duì)象和備份數(shù)據(jù)混在一起容易沖突。storageLocation和備份時(shí)保持一致。創(chuàng)建restore后backup operator會(huì)在cattle-system里啟動(dòng)Rancher pod并恢復(fù)數(shù)據(jù)期間UI可能短時(shí)不可用需要耐心等。觀察restore狀態(tài)到Completed再刪除restore對(duì)象。4.3 恢復(fù)后的首次登錄和原始憑據(jù)恢復(fù)完成后Rancher會(huì)自動(dòng)重啟。用舊環(huán)境的管理員賬號(hào)密碼登錄如果用臨時(shí)bootstrapPassword是登不進(jìn)去的。如果舊環(huán)境密碼也沒(méi)記錄在恢復(fù)前提前從舊集群的secret里把a(bǔ)dmin密碼hash導(dǎo)出或者干脆在遷移前重置一次管理員密碼并記錄下來(lái)。登錄之后全局設(shè)置里的server-url非常關(guān)鍵。如果新環(huán)境地址變了要立刻改過(guò)來(lái)。改server-url時(shí)Rancher會(huì)嘗試重新生成下游集群的agent注冊(cè)配置。4.4 為什么順序必須是先有Rancher基礎(chǔ)chart再restore有人問(wèn)為什么不能在一臺(tái)空K8s集群上直接安裝backup operator然后restore因?yàn)閞estore本質(zhì)上是把Rancher自身的資源對(duì)象覆蓋進(jìn)去但它沒(méi)有能力重建Rancher chart全部初始化流程所依賴的骨架。比如cattle-system命名空間的基礎(chǔ)對(duì)象、ingress、serviceAccount等。先安裝Rancher chart可以把這些骨架搭好然后再用備份數(shù)據(jù)覆蓋血肉。骨架和血肉來(lái)自同一個(gè)版本時(shí)最穩(wěn)。4.5 恢復(fù)后的第一輪驗(yàn)證登錄Rancher UI后先看全局設(shè)置、用戶列表、角色權(quán)限是否完整。再進(jìn)入local集群看節(jié)點(diǎn)負(fù)載是否正常。此時(shí)下游集群大概率顯示Disconnected不用慌這一步正常下一步處理。5. 遷移后最麻煩的部分下游集群怎么重新接回Rancher5.1 失聯(lián)原因分解下游集群失聯(lián)的直接原因通常是agent注冊(cè)時(shí)保存的server-url還是舊地址DNS切換后連不上。證書不匹配TLS握手失敗。Rancher服務(wù)端生成的新token沒(méi)有分發(fā)下去。防火墻或安全組沒(méi)放行新的管理集群端口?？梢赃@么理解下游集群的agent就像一臺(tái)老式電話機(jī)號(hào)碼簿里記的還是舊號(hào)碼。你要讓Rancher這邊的座機(jī)先確認(rèn)自己的新號(hào)碼然后想辦法把新號(hào)碼通知給所有電話機(jī)。5.2 先讓server-url和證書確定下來(lái)遷移后第一件事是把全局設(shè)置里的server-url改為最終對(duì)外地址并確認(rèn)證書有效。如果地址變化導(dǎo)致證書不匹配通常需要更新Rancher ingress的TLS secret換成覆蓋新地址的證書。在Rancher UI的Settings里觸發(fā)配置刷新。之后下游集群的agent如果自動(dòng)重連失敗再手動(dòng)重發(fā)。如果舊環(huán)境用了自簽證書遷移時(shí)要保留私鑰和完整證書鏈不能只帶一個(gè)crt。私鑰不匹配的話agent全部握手失敗報(bào)的都是x509錯(cuò)誤。5.3 自動(dòng)重連與手動(dòng)兜底大部分情況下只要server-url正確、網(wǎng)絡(luò)通暢cattle-cluster-agent和cattle-node-agent會(huì)在幾分鐘內(nèi)恢復(fù)正常。判斷方法在Rancher UI查看下游集群的狀態(tài)從Disconnected慢慢變回Active。在下游集群執(zhí)行kubectl get pods -n cattle-system看cattle-cluster-agent和cattle-node-agent是否Running。如果仍異常查看agent日志常見(jiàn)的是x509證書錯(cuò)誤或request timeout。手動(dòng)兜底路徑在Rancher UI進(jìn)入對(duì)應(yīng)集群的編輯頁(yè)面找到Registration Token重新生成或查看kubeconfig。拿到該集群的agent manifest。在下游集群里刪除舊的agent Deployment/DaemonSet讓它們重新拉取最新配置。更直接的做法在目標(biāo)集群對(duì)應(yīng)頁(yè)面用Edit Cluster重新保存一次Rancher會(huì)重新下發(fā)注冊(cè)命令。5.4 驗(yàn)證每類角色的狀態(tài)可以用一張表輔助驗(yàn)證檢查對(duì)象參考命令預(yù)期結(jié)果Rancher管理集群節(jié)點(diǎn)kubectl get nodes全部ReadyRancher podkubectl get pods -n cattle-systemRunning下游集群cattle-cluster-agentkubectl -n cattle-system get podsRunning或重建后正常下游集群cattle-node-agentkubectl -n cattle-system get daemonset正常調(diào)度Rancher UI集群列表集群管理-集群狀態(tài)為Active5.5 證書和token的實(shí)操經(jīng)驗(yàn)如果要保留原有自簽證書新環(huán)境必須把舊證書的私鑰、證書鏈完整帶入不能只帶一個(gè)crt。如果是遷移后重新簽發(fā)證書那么下游集群必須能通過(guò)新地址驗(yàn)證服務(wù)端身份否則agent全部握手失敗。比較省事的做法是遷移后直接換成受信CA簽發(fā)的域名證書一勞永逸。還有一個(gè)細(xì)節(jié)Rancher的agent注冊(cè)token是有有效期的如果遷移間隔太久token可能已經(jīng)過(guò)期。這種情況下重新生成新token即可。6. 復(fù)盤走過(guò)的彎路典型失敗場(chǎng)景與排查鏈路6.1 場(chǎng)景一恢復(fù)后Rancher UI起來(lái)了但登錄一直報(bào)錯(cuò)我遇到過(guò)restore完成后頁(yè)面反復(fù)提示Unauthorized的情況。排查下來(lái)發(fā)現(xiàn)是臨時(shí)裝的Rancher chart和備份數(shù)據(jù)的版本不一致導(dǎo)致admin用戶相關(guān)CRD沖突。解決方法是把Rancher chart卸載重新裝到與舊環(huán)境一致的chart版本再restore。所以恢復(fù)前核對(duì)chart版本絕對(duì)不要省。這一條異常重要。6.2 場(chǎng)景二下游集群顯示Disconnectedagent日志報(bào)TLS錯(cuò)誤agent日志里的典型錯(cuò)誤是certificate signed by unknown authority或x509: certificate is valid for xxx。這說(shuō)明agent拿到的證書和當(dāng)前server-url不匹配。處理步驟確認(rèn)server-url和實(shí)際訪問(wèn)地址一致。確認(rèn)ingress證書是新地址的有效證書。在下游集群刪除cattle-system下agent相關(guān)pod強(qiáng)制重建。如果還不行直接在Rancher里重新生成registration token并apply。6.3 場(chǎng)景三新集群上的Rancher pod一直ImagePullBackOff新環(huán)境通常還沒(méi)配好鏡像倉(cāng)庫(kù)的登錄信息特別是從私有鏡像倉(cāng)庫(kù)拉Rancher鏡像時(shí)。處理手段是提前在節(jié)點(diǎn)上配置docker login或者在cluster.yml和Rancher chart的values里配置imagePullSecrets。舊環(huán)境用了哪些鏡像建議提前導(dǎo)出鏡像清單避免新環(huán)境臨時(shí)找鏡像。6.4 場(chǎng)景四prune沒(méi)開(kāi)恢復(fù)后Rancher里混著一堆重復(fù)對(duì)象臨時(shí)安裝的Rancher chart會(huì)預(yù)創(chuàng)建默認(rèn)的集群對(duì)象。如果restore時(shí)prune沒(méi)開(kāi)備份里沒(méi)有的默認(rèn)對(duì)象會(huì)留在系統(tǒng)里看起來(lái)像多出來(lái)幾個(gè)服務(wù)或項(xiàng)目。它們的資源類型和正常對(duì)象混在一起排查很費(fèi)勁。所以restore時(shí)prune盡量設(shè)成true。6.5 排查思路的層次總結(jié)幾條排錯(cuò)順序第一層網(wǎng)絡(luò)通不通。從下游集群節(jié)點(diǎn)執(zhí)行curl -k https://新server-url:443。第二層證書對(duì)不對(duì)。檢查證書域名、有效期。第三層server-url對(duì)不對(duì)。在Rancher全局設(shè)置里看。第四層Token和agent配置有沒(méi)有更新?？碼gent日志和registration token。第五層版本和CRD有沒(méi)有沖突。看Rancher pod日志和CRD版本。按這個(gè)順序走大部分問(wèn)題的根因都能定位到前四層。如果真的到第五層基本就是版本規(guī)劃的問(wèn)題需要回到備份和chart版本匹配這條線上重新對(duì)齊。6.6 一個(gè)小建議遷移前先完整演練一遍如果你的環(huán)境比較復(fù)雜比如下游集群非常多、有自定義RBAC、有外部認(rèn)證強(qiáng)烈建議先搭一個(gè)臨時(shí)環(huán)境完整演練一遍備份、恢復(fù)、下游重連、驗(yàn)證。演練過(guò)程能暴露大部分問(wèn)題也會(huì)讓你對(duì)restore的耗時(shí)和UI中斷時(shí)間有預(yù)期真遷的時(shí)候心里有底?；氐介_(kāi)頭說(shuō)的那次遷移。整個(gè)過(guò)程讓我印象最深的不是restore那一下而是備份清單和版本記錄是否完整。只要這些基礎(chǔ)信息是齊的遷移就像按照地圖走一遍反過(guò)來(lái)最基礎(chǔ)的版本不匹配就能讓你卡住半天。以后再接到類似的Rancher遷移任務(wù)我會(huì)先花半小時(shí)盤點(diǎn)版本、server-url、證書和備份文件再動(dòng)手。遷移窗口期盡量選在業(yè)務(wù)低峰restore過(guò)程中的UI中斷時(shí)間通常不會(huì)太長(zhǎng)但下游集群重新注冊(cè)的時(shí)間取決于集群數(shù)量和網(wǎng)絡(luò)狀況?？傮w來(lái)看基于RKE部署的Rancher遷移只要把握住數(shù)據(jù)、身份、網(wǎng)絡(luò)信任這三件事不會(huì)出大問(wèn)題。