實戰(zhàn)指南：構(gòu)建自定義鏡像、Helm 部署與 CAPRKE2 v2prov 集成測試)
Rancher 本地開發(fā)實戰(zhàn)指南構(gòu)建自定義鏡像、Helm 部署與 CAPRKE2 v2prov 集成測試【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher本篇開發(fā)指南以倉庫 docs/development.md 為骨架系統(tǒng)講解在 Rancher 項目中完成一次「本地閉環(huán)開發(fā)」的完整路徑先用make quick通過 docker buildx 構(gòu)建自定義架構(gòu)的 Rancher 鏡像再用 Helm 將自定義鏡像部署到集群最后深入 CAPRKE2 v2prov 本地集成測試的完整環(huán)境搭建、運行與清理流程。讀完你將掌握 Rancher 鏡像的跨架構(gòu)構(gòu)建技巧、Helm 覆蓋參數(shù)的正確用法以及一套可在本機反復(fù)運行的 CAPI CAPD CAPRKE2 集成測試配方。一、快速構(gòu)建本地容器鏡像make quick在將改動提交到 Pull Request 之前開發(fā)者往往需要先在容器鏡像里驗證變更是否按預(yù)期工作。Rancher 倉庫提供了一個便捷腳本make quick其實現(xiàn)位于 dev-scripts/quick它基于docker buildx構(gòu)建天然支持跨 CPU 架構(gòu)cross-building編譯。針對當(dāng)前操作系統(tǒng)與架構(gòu)構(gòu)建鏡像在倉庫根目錄執(zhí)行REPOlocalhost:5000/my-test-repo/image TAGtag make quick如果希望為其他架構(gòu)交叉構(gòu)建只需額外設(shè)置ARCH變量REPOlocalhost:5000/my-test-repo/image \ TAGtag \ ARCHamd64 \ make quick腳本背后的構(gòu)建細節(jié)閱讀 dev-scripts/quick 源碼可以了解該命令的底層實現(xiàn)多階段構(gòu)建目標package/Dockerfile 定義了server、agent、server-binary、k3s-images等多個 target。未設(shè)置TARGET時腳本默認構(gòu)建server與agent兩個鏡像產(chǎn)物 tag 分別為${REPO}/rancher:${TAG}和${REPO}/rancher-agent:${TAG}設(shè)置TARGETbinary-server則只產(chǎn)出本地二進制到當(dāng)前目錄TARGETk3s-images則導(dǎo)出 k3s 鏡像列表。構(gòu)建參數(shù)自動注入腳本會從 package/Dockerfile 中提取CATTLE_K3S_VERSION、CATTLE_KDM_BRANCH、CATTLE_HELM_VERSION等版本信息并從 git 當(dāng)前 HEAD 取短 commit隨后以--build-arg形式傳入保證鏡像內(nèi)嵌的版本號與源碼一致。調(diào)試構(gòu)建設(shè)置BINARY_DEBUGtrue時腳本會移除 Go 的-s剝離符號表flag 并關(guān)閉編譯器優(yōu)化GCFLAGSall-N -l便于在鏡像內(nèi)進行斷點調(diào)試。本地依賴替換replace directive支持腳本會掃描 go.mod 中的replace指令若本地路徑存在于BUILD_SAFE_DIRS允許前綴內(nèi)會通過--build-context與--build-arg注入 apiserver、lasso、norman、remotedialer、shepherd、steve、wrangler 等模塊的本地源碼路徑讓開發(fā)者可以直接用本地依賴進行鏡像驗證。推送設(shè)置PUSHtrue時構(gòu)建完成后會自動執(zhí)行docker push。因此make quick不僅是「快」它本質(zhì)上是一條完整的、可定制的 Rancher 鏡像生產(chǎn)線。二、通過 Helm 部署自定義鏡像鏡像構(gòu)建好之后下一步就是把它部署到集群中驗證。Rancher 官方使用 Helm Chart 進行安裝Chart 定義見 chart/Chart.yaml部署自定義鏡像只需要覆蓋兩個變量helm upgrade --install rancher/rancher \ --namespace cattle-system \ --create-namespace \ --set rancherImagemy-test-repo/image \ --set rancherImageTagdev-tagrancherImage自定義鏡像倉庫與鏡像名對應(yīng)上一節(jié)構(gòu)建出的鏡像。rancherImageTag自定義 tag。--create-namespace會自動創(chuàng)建cattle-system命名空間helm upgrade --install兼具安裝與升級能力便于反復(fù)迭代部署。Chart 的完整可配置項定義在 chart/values.yaml 與 chart/values.schema.json 中需要調(diào)整資源、探針、Ingress 等參數(shù)時可參考這兩份文件。三、CAPRKE2 v2prov 本地集成測試全流程Test_Operation_SetE_CAPRKE2DockerOperations是 Rancher 中一個僅限本地運行的集成測試它針對 CAPI Cluster控制平面為 CAPRKE2 的RKE2ControlPlane基礎(chǔ)設(shè)施為 CAPI Docker 提供方執(zhí)行 Rancher 的操作適配器operation adapter系列操作——etcd 快照保存/恢復(fù)與加密密鑰輪換。CI 不會運行它因為所需的環(huán)境kind docker 網(wǎng)絡(luò) 掛載到管理集群節(jié)點的宿主機 docker socket只在本地接好。本機前置條件docker、k3d、kubectl。三個工具的完整使用流程如下。第 1 步準備本地集群make dev-env該目標對應(yīng)腳本 dev-scripts/dev-env它做三件事創(chuàng)建 CAPD 硬編碼使用的kinddocker 網(wǎng)絡(luò)sigs.k8s.io/cluster-api/test/infrastructure/docker/internal/docker/manager.go中的DefaultNetwork名即kind。創(chuàng)建掛接到該網(wǎng)絡(luò)的 k3d 集群默認名local-caprke2并把宿主機/var/run/docker.sock以 hostPath 方式 bind-mount 進 server 節(jié)點——這正是 CAPD 上游 manager.yaml 的掛載方式。這兩個不變量共同保證 CAPD 的 controller 既能訪問宿主機 docker daemon又能路由到 CAPD 派生的負載容器。把默認 kubectl context 切換到新集群k3d-local-caprke2使后續(xù)讀取~/.kube/config的工具包括 Rancher自動指向它。腳本同時檢查docker、k3d、jq、kubectl是否在 PATH 中且具備冪等性——集群已存在時直接復(fù)用不會重復(fù)創(chuàng)建。第 2 步讓 Rancher 連接新集群Rancher 讀取~/.kube/config此時它已指向k3d-local-caprke2。用你習(xí)慣的方式啟動 Rancher 即可例如 GoLand 運行目標或./dev-scripts/quickRancher 首次啟動時會向集群安裝 TurtlesRancher Turtles 是 CAPI 與 Rancher 之間的橋接組件這一步為后續(xù)安裝 CAPI Provider 打下基礎(chǔ)。第 3 步安裝 CAPRKE2 CAPD ProviderRancher 起來之后執(zhí)行make install-caprke2-providers對應(yīng)腳本 dev-scripts/install-caprke2-providers 的流程是等待 Turtles CRD輪詢等待capiproviders.turtles-capi.cattle.ioCRD 出現(xiàn)Rancher 啟動后約 12 分鐘通過 scripts/retry 實現(xiàn) 300 秒超時重試若一直不出現(xiàn)腳本會提示先啟動 Rancher 再重試。應(yīng)用 Provider 清單默認應(yīng)用倉庫內(nèi) tests/v2prov/defaults/caprke2-providers.yaml。該清單定義了三個 CAPIProviderrke2-bootstraptype: bootstrap由 RKE2Config/RKE2ConfigTemplate 生成 bootstrap secretrke2-control-planetype: controlPlane負責(zé)調(diào)和 RKE2ControlPlanedockertype: infrastructure在宿主 docker socket 上運行 DockerCluster/DockerMachine。等待就緒分別等待rke2-bootstrap-system/rke2-bootstrap-controller-manager、rke2-control-plane-system/rke2-control-plane-controller-manager、capd-system/capd-controller-manager三個 Deployment 完成 rollout。第 4 步運行測試V2PROV_TEST_CAPRKE2true go test -v -failfast -timeout 60m \ -run ^Test_Operation_SetE_CAPRKE2DockerOperations$ \ ./tests/v2prov/tests/imported/...V2PROV_TEST_CAPRKE2true是測試的開關(guān)測試源碼 tests/v2prov/tests/imported/caprke2_test.go 中若該環(huán)境變量不等于true會直接t.Skip這也是該測試無法在 CI 運行的原因之一。-failfast在首個失敗用例處停止-timeout 60m給出充足超時預(yù)算整個操作序列涉及多次重啟控制平面。關(guān)于測試名的說明development.md 中的-run正則對應(yīng)歷史單節(jié)點冒煙測試名從當(dāng)前源碼 tests/v2prov/tests/imported/caprke2_test.go 看同族測試已擴展為Test_Imported_Operation_SetE_CAPRKE2DockerOperations單控制平面及其_OneServerOneAgent、_ThreeServers、_ThreeServersThreeAgents變體文件頂部注釋給出了現(xiàn)行推薦用法V2PROV_TEST_CAPRKE2true go test -v \ -run ^Test_Imported_Operation_SetE_CAPRKE2Docker \ ./tests/v2prov/tests/imported/...第 5 步清理環(huán)境make dev-env-cleanup對應(yīng)腳本 dev-scripts/dev-env-cleanup 會刪除 k3d 集群對于kinddocker 網(wǎng)絡(luò)僅當(dāng)沒有任何容器掛接時才刪除避免誤傷仍在使用的真實 kind 集群或其他 CAPI/CAPD 環(huán)境。環(huán)境變量覆蓋項變量作用默認值CAPRKE2_DEV_CLUSTERk3d 集群名同時作用于make dev-env與make dev-env-cleanuplocal-caprke2K3S_VERSIONk3s 鏡像 tagv1.33.5-k3s1V2PROV_TEST_CAPRKE2_MANIFEST本地 Provider 清單的絕對路徑make install-caprke2-providers將原樣應(yīng)用它而不用倉庫默認清單未設(shè)置V2PROV_TEST_CAPRKE2_TURTLES_REFrancher/turtles的 git reftag/branch/SHA腳本會克隆該 ref 并對charts/rancher-turtles-providers執(zhí)行helm template后應(yīng)用便于測試倉庫鎖定版本之外的上游 Turtles 版本未設(shè)置四、原理縱深operation adapter 與測試如何驗證操作適配器的注冊與分派CAPRKE2 操作之所以能作用于 CAPI Cluster關(guān)鍵在于操作適配器adapter機制。pkg/operations/capi.go 在init()中為cluster.x-k8s.io/v1beta2的ClusterGVK 注冊了適配器工廠它從 CAPI Client 緩存讀取 Cluster 對象再通過capiClusterAdapter根據(jù)controlPlaneRef分派——RKEControlPlane走 CAPR 適配器RKE2ControlPlane則走 CAPRKE2 適配器pkg/operations/capi.go。這也解釋了為何測試中的操作ClusterRef指向 CAPI Cluster 而非 mgmt v3 的鏡像資源。測試的操作序列與“恢復(fù)證明”tests/v2prov/tests/imported/caprke2_test.go 中的runCAPRKE2OperationsTest依次執(zhí)行三個操作并逐步驗證ETCDSnapshotSave先在目標集群的default命名空間寫入一個 value 為wow的 ConfigMap作為“恢復(fù)證明”標記再發(fā)起快照保存操作由于 etcd 只跑在控制平面節(jié)點上測試會等待與Replicas數(shù)量一致、且時間戳在保存開始之后的快照文件出現(xiàn)。ETCDSnapshotRestore先刪除該 ConfigMap然后從控制平面 CAPI Machine 中挑選最新的一個作為 init-node 標識多輪 restore/輪換后舊機器可能已被滾動替換據(jù)此查找快照并執(zhí)行恢復(fù)單節(jié)點集群按磁盤上的原始快照文件名恢復(fù)多節(jié)點集群按ETCDSnapshotCR 名恢復(fù)由CAPRKE2Options.UseSnapshotFileName區(qū)分。恢復(fù)后輪詢最多 60 次、每次間隔 5 秒等待 ConfigMap 重新出現(xiàn)且值為wow——期間 apiserver 會因重啟而短暫不可達測試對此做了容錯。EncryptionKeyRotation最后執(zhí)行加密密鑰輪換該操作會暫停并重啟集群斷言操作進入OperationPhaseSucceeded階段。此外tests/v2prov/operations/etcdsnapshot.go 等文件提供了下游客戶端構(gòu)建、快照 CR 輪詢等公共操作工具展示了完整的測試基建。若某步失敗測試還會調(diào)用cluster.GatherDebugData收集調(diào)試數(shù)據(jù) bundle方便本地排障。五、總結(jié)與本地迭代建議綜合以上流程一套高效的 Rancher 本地開發(fā)循環(huán)是修改代碼 →REPO鏡像 TAGtag make quick構(gòu)建鏡像需要時可指定ARCH交叉構(gòu)建helm upgrade --install覆蓋rancherImage/rancherImageTag完成熱部署涉及 CAPRKE2/操作適配器改動時按「make dev-env→ 啟動 Rancher →make install-caprke2-providers→ 運行 v2prov 測試 →make dev-env-cleanup」的完整鏈路做集成驗證。這套工具鏈的每一環(huán)都能在倉庫中找到對應(yīng)的可讀腳本dev-scripts/ 目錄下是理解 Rancher 鏡像構(gòu)建與 CAPI 集成測試機制的最佳入口。【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Rancher 本地開發(fā)實戰(zhàn)指南：構(gòu)建自定義鏡像、Helm 部署與 CAPRKE2 v2prov 集成測試
Rancher 本地開發(fā)實戰(zhàn)指南構(gòu)建自定義鏡像、Helm 部署與 CAPRKE2 v2prov 集成測試【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher本篇開發(fā)指南以倉庫 docs/development.md 為骨架系統(tǒng)講解在 Rancher 項目中完成一次「本地閉環(huán)開發(fā)」的完整路徑先用make quick通過 docker buildx 構(gòu)建自定義架構(gòu)的 Rancher 鏡像再用 Helm 將自定義鏡像部署到集群最后深入 CAPRKE2 v2prov 本地集成測試的完整環(huán)境搭建、運行與清理流程。讀完你將掌握 Rancher 鏡像的跨架構(gòu)構(gòu)建技巧、Helm 覆蓋參數(shù)的正確用法以及一套可在本機反復(fù)運行的 CAPI CAPD CAPRKE2 集成測試配方。一、快速構(gòu)建本地容器鏡像make quick在將改動提交到 Pull Request 之前開發(fā)者往往需要先在容器鏡像里驗證變更是否按預(yù)期工作。Rancher 倉庫提供了一個便捷腳本make quick其實現(xiàn)位于 dev-scripts/quick它基于docker buildx構(gòu)建天然支持跨 CPU 架構(gòu)cross-building編譯。針對當(dāng)前操作系統(tǒng)與架構(gòu)構(gòu)建鏡像在倉庫根目錄執(zhí)行REPOlocalhost:5000/my-test-repo/image TAGtag make quick如果希望為其他架構(gòu)交叉構(gòu)建只需額外設(shè)置ARCH變量REPOlocalhost:5000/my-test-repo/image \ TAGtag \ ARCHamd64 \ make quick腳本背后的構(gòu)建細節(jié)閱讀 dev-scripts/quick 源碼可以了解該命令的底層實現(xiàn)多階段構(gòu)建目標package/Dockerfile 定義了server、agent、server-binary、k3s-images等多個 target。未設(shè)置TARGET時腳本默認構(gòu)建server與agent兩個鏡像產(chǎn)物 tag 分別為${REPO}/rancher:${TAG}和${REPO}/rancher-agent:${TAG}設(shè)置TARGETbinary-server則只產(chǎn)出本地二進制到當(dāng)前目錄TARGETk3s-images則導(dǎo)出 k3s 鏡像列表。構(gòu)建參數(shù)自動注入腳本會從 package/Dockerfile 中提取CATTLE_K3S_VERSION、CATTLE_KDM_BRANCH、CATTLE_HELM_VERSION等版本信息并從 git 當(dāng)前 HEAD 取短 commit隨后以--build-arg形式傳入保證鏡像內(nèi)嵌的版本號與源碼一致。調(diào)試構(gòu)建設(shè)置BINARY_DEBUGtrue時腳本會移除 Go 的-s剝離符號表flag 并關(guān)閉編譯器優(yōu)化GCFLAGSall-N -l便于在鏡像內(nèi)進行斷點調(diào)試。本地依賴替換replace directive支持腳本會掃描 go.mod 中的replace指令若本地路徑存在于BUILD_SAFE_DIRS允許前綴內(nèi)會通過--build-context與--build-arg注入 apiserver、lasso、norman、remotedialer、shepherd、steve、wrangler 等模塊的本地源碼路徑讓開發(fā)者可以直接用本地依賴進行鏡像驗證。推送設(shè)置PUSHtrue時構(gòu)建完成后會自動執(zhí)行docker push。因此make quick不僅是「快」它本質(zhì)上是一條完整的、可定制的 Rancher 鏡像生產(chǎn)線。二、通過 Helm 部署自定義鏡像鏡像構(gòu)建好之后下一步就是把它部署到集群中驗證。Rancher 官方使用 Helm Chart 進行安裝Chart 定義見 chart/Chart.yaml部署自定義鏡像只需要覆蓋兩個變量helm upgrade --install rancher/rancher \ --namespace cattle-system \ --create-namespace \ --set rancherImagemy-test-repo/image \ --set rancherImageTagdev-tagrancherImage自定義鏡像倉庫與鏡像名對應(yīng)上一節(jié)構(gòu)建出的鏡像。rancherImageTag自定義 tag。--create-namespace會自動創(chuàng)建cattle-system命名空間helm upgrade --install兼具安裝與升級能力便于反復(fù)迭代部署。Chart 的完整可配置項定義在 chart/values.yaml 與 chart/values.schema.json 中需要調(diào)整資源、探針、Ingress 等參數(shù)時可參考這兩份文件。三、CAPRKE2 v2prov 本地集成測試全流程Test_Operation_SetE_CAPRKE2DockerOperations是 Rancher 中一個僅限本地運行的集成測試它針對 CAPI Cluster控制平面為 CAPRKE2 的RKE2ControlPlane基礎(chǔ)設(shè)施為 CAPI Docker 提供方執(zhí)行 Rancher 的操作適配器operation adapter系列操作——etcd 快照保存/恢復(fù)與加密密鑰輪換。CI 不會運行它因為所需的環(huán)境kind docker 網(wǎng)絡(luò) 掛載到管理集群節(jié)點的宿主機 docker socket只在本地接好。本機前置條件docker、k3d、kubectl。三個工具的完整使用流程如下。第 1 步準備本地集群make dev-env該目標對應(yīng)腳本 dev-scripts/dev-env它做三件事創(chuàng)建 CAPD 硬編碼使用的kinddocker 網(wǎng)絡(luò)sigs.k8s.io/cluster-api/test/infrastructure/docker/internal/docker/manager.go中的DefaultNetwork名即kind。創(chuàng)建掛接到該網(wǎng)絡(luò)的 k3d 集群默認名local-caprke2并把宿主機/var/run/docker.sock以 hostPath 方式 bind-mount 進 server 節(jié)點——這正是 CAPD 上游 manager.yaml 的掛載方式。這兩個不變量共同保證 CAPD 的 controller 既能訪問宿主機 docker daemon又能路由到 CAPD 派生的負載容器。把默認 kubectl context 切換到新集群k3d-local-caprke2使后續(xù)讀取~/.kube/config的工具包括 Rancher自動指向它。腳本同時檢查docker、k3d、jq、kubectl是否在 PATH 中且具備冪等性——集群已存在時直接復(fù)用不會重復(fù)創(chuàng)建。第 2 步讓 Rancher 連接新集群Rancher 讀取~/.kube/config此時它已指向k3d-local-caprke2。用你習(xí)慣的方式啟動 Rancher 即可例如 GoLand 運行目標或./dev-scripts/quickRancher 首次啟動時會向集群安裝 TurtlesRancher Turtles 是 CAPI 與 Rancher 之間的橋接組件這一步為后續(xù)安裝 CAPI Provider 打下基礎(chǔ)。第 3 步安裝 CAPRKE2 CAPD ProviderRancher 起來之后執(zhí)行make install-caprke2-providers對應(yīng)腳本 dev-scripts/install-caprke2-providers 的流程是等待 Turtles CRD輪詢等待capiproviders.turtles-capi.cattle.ioCRD 出現(xiàn)Rancher 啟動后約 12 分鐘通過 scripts/retry 實現(xiàn) 300 秒超時重試若一直不出現(xiàn)腳本會提示先啟動 Rancher 再重試。應(yīng)用 Provider 清單默認應(yīng)用倉庫內(nèi) tests/v2prov/defaults/caprke2-providers.yaml。該清單定義了三個 CAPIProviderrke2-bootstraptype: bootstrap由 RKE2Config/RKE2ConfigTemplate 生成 bootstrap secretrke2-control-planetype: controlPlane負責(zé)調(diào)和 RKE2ControlPlanedockertype: infrastructure在宿主 docker socket 上運行 DockerCluster/DockerMachine。等待就緒分別等待rke2-bootstrap-system/rke2-bootstrap-controller-manager、rke2-control-plane-system/rke2-control-plane-controller-manager、capd-system/capd-controller-manager三個 Deployment 完成 rollout。第 4 步運行測試V2PROV_TEST_CAPRKE2true go test -v -failfast -timeout 60m \ -run ^Test_Operation_SetE_CAPRKE2DockerOperations$ \ ./tests/v2prov/tests/imported/...V2PROV_TEST_CAPRKE2true是測試的開關(guān)測試源碼 tests/v2prov/tests/imported/caprke2_test.go 中若該環(huán)境變量不等于true會直接t.Skip這也是該測試無法在 CI 運行的原因之一。-failfast在首個失敗用例處停止-timeout 60m給出充足超時預(yù)算整個操作序列涉及多次重啟控制平面。關(guān)于測試名的說明development.md 中的-run正則對應(yīng)歷史單節(jié)點冒煙測試名從當(dāng)前源碼 tests/v2prov/tests/imported/caprke2_test.go 看同族測試已擴展為Test_Imported_Operation_SetE_CAPRKE2DockerOperations單控制平面及其_OneServerOneAgent、_ThreeServers、_ThreeServersThreeAgents變體文件頂部注釋給出了現(xiàn)行推薦用法V2PROV_TEST_CAPRKE2true go test -v \ -run ^Test_Imported_Operation_SetE_CAPRKE2Docker \ ./tests/v2prov/tests/imported/...第 5 步清理環(huán)境make dev-env-cleanup對應(yīng)腳本 dev-scripts/dev-env-cleanup 會刪除 k3d 集群對于kinddocker 網(wǎng)絡(luò)僅當(dāng)沒有任何容器掛接時才刪除避免誤傷仍在使用的真實 kind 集群或其他 CAPI/CAPD 環(huán)境。環(huán)境變量覆蓋項變量作用默認值CAPRKE2_DEV_CLUSTERk3d 集群名同時作用于make dev-env與make dev-env-cleanuplocal-caprke2K3S_VERSIONk3s 鏡像 tagv1.33.5-k3s1V2PROV_TEST_CAPRKE2_MANIFEST本地 Provider 清單的絕對路徑make install-caprke2-providers將原樣應(yīng)用它而不用倉庫默認清單未設(shè)置V2PROV_TEST_CAPRKE2_TURTLES_REFrancher/turtles的 git reftag/branch/SHA腳本會克隆該 ref 并對charts/rancher-turtles-providers執(zhí)行helm template后應(yīng)用便于測試倉庫鎖定版本之外的上游 Turtles 版本未設(shè)置四、原理縱深operation adapter 與測試如何驗證操作適配器的注冊與分派CAPRKE2 操作之所以能作用于 CAPI Cluster關(guān)鍵在于操作適配器adapter機制。pkg/operations/capi.go 在init()中為cluster.x-k8s.io/v1beta2的ClusterGVK 注冊了適配器工廠它從 CAPI Client 緩存讀取 Cluster 對象再通過capiClusterAdapter根據(jù)controlPlaneRef分派——RKEControlPlane走 CAPR 適配器RKE2ControlPlane則走 CAPRKE2 適配器pkg/operations/capi.go。這也解釋了為何測試中的操作ClusterRef指向 CAPI Cluster 而非 mgmt v3 的鏡像資源。測試的操作序列與“恢復(fù)證明”tests/v2prov/tests/imported/caprke2_test.go 中的runCAPRKE2OperationsTest依次執(zhí)行三個操作并逐步驗證ETCDSnapshotSave先在目標集群的default命名空間寫入一個 value 為wow的 ConfigMap作為“恢復(fù)證明”標記再發(fā)起快照保存操作由于 etcd 只跑在控制平面節(jié)點上測試會等待與Replicas數(shù)量一致、且時間戳在保存開始之后的快照文件出現(xiàn)。ETCDSnapshotRestore先刪除該 ConfigMap然后從控制平面 CAPI Machine 中挑選最新的一個作為 init-node 標識多輪 restore/輪換后舊機器可能已被滾動替換據(jù)此查找快照并執(zhí)行恢復(fù)單節(jié)點集群按磁盤上的原始快照文件名恢復(fù)多節(jié)點集群按ETCDSnapshotCR 名恢復(fù)由CAPRKE2Options.UseSnapshotFileName區(qū)分。恢復(fù)后輪詢最多 60 次、每次間隔 5 秒等待 ConfigMap 重新出現(xiàn)且值為wow——期間 apiserver 會因重啟而短暫不可達測試對此做了容錯。EncryptionKeyRotation最后執(zhí)行加密密鑰輪換該操作會暫停并重啟集群斷言操作進入OperationPhaseSucceeded階段。此外tests/v2prov/operations/etcdsnapshot.go 等文件提供了下游客戶端構(gòu)建、快照 CR 輪詢等公共操作工具展示了完整的測試基建。若某步失敗測試還會調(diào)用cluster.GatherDebugData收集調(diào)試數(shù)據(jù) bundle方便本地排障。五、總結(jié)與本地迭代建議綜合以上流程一套高效的 Rancher 本地開發(fā)循環(huán)是修改代碼 →REPO鏡像 TAGtag make quick構(gòu)建鏡像需要時可指定ARCH交叉構(gòu)建helm upgrade --install覆蓋rancherImage/rancherImageTag完成熱部署涉及 CAPRKE2/操作適配器改動時按「make dev-env→ 啟動 Rancher →make install-caprke2-providers→ 運行 v2prov 測試 →make dev-env-cleanup」的完整鏈路做集成驗證。這套工具鏈的每一環(huán)都能在倉庫中找到對應(yīng)的可讀腳本dev-scripts/ 目錄下是理解 Rancher 鏡像構(gòu)建與 CAPI 集成測試機制的最佳入口。【免費下載鏈接】rancherComplete container management platform項目地址: https://gitcode.com/GitHub_Trending/ra/rancher創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考