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