简介：本资源为 Kubernetes 生产环境离线部署 Rancher 2.4.5 管理平台所需的完整 Docker 镜像包，面向运维工程师、K8s 平台搭建人员及私有化交付场景下的 DevOps 实践者，解决无公网环境下快速拉起 Rancher v2.4.5 集群管理界面的核心依赖问题。压缩包共7个文件，含5个标准 tar 格式镜像导出包（覆盖 rancher-agent、kube-proxy、prom-node-exporter、flannel 及其 CNI 插件等关键组件）、1份 flannel.yaml 网络配置模板与1份说明文档（ReadMe.md），总大小 178.1MB，结构精简、开箱即用。已有 290 人学习下载，适用于企业内网 K8s 集群初始化、Rancher HA 搭建预演及离线环境灾备恢复。用户可直接通过 docker load 命令批量导入全部镜像，无需逐个 pull，显著规避网络超时与镜像拉取失败风险，并获得与官方 V2.4.5 版本严格对齐的组件版本组合（如 kube-proxy v1.17.0、flannel v0.16.1），保障部署一致性与可复现性。
1. Rancher V2.4.5 镜像包不是“开箱即用”的控制台，而是你离生产级 K8s 多集群管理最近的一份可验证、可离线部署的确定性基线
如果你正卡在这样一个典型场景里：公司内网环境严禁外连，但又必须快速交付一套能统一纳管 3 个以上异构 K8s 集群（含自建、云厂商托管、边缘轻量集群）的可视化平台；或者你在做灾备演练，需要确保 Rancher Server 在断网、无公网镜像仓库、无 Helm Chart Repo 的纯内网环境下，5 分钟内拉起且状态完全可控——那么这份 Rancher V2.4.5 的完整 Docker 镜像包，就是你真正该盯住的“确定性资产”。它不是 GitHub 上那个需要docker run一行命令就完事的 demo 镜像，而是包含 server、agent、cli、backup-restore-operator 全组件的离线镜像集合，已按 V2.4.5 官方 release commit（a079b6e）构建并 tar 打包，镜像层哈希可验、启动参数可审计、升级路径可回溯。适合 DevOps 工程师、SRE、私有云平台建设者，尤其适合对“不可变基础设施”有强诉求、拒绝任何运行时动态拉取行为的落地场景。别被“V2.4.5”这个版本号劝退——它虽非最新，但在多租户 RBAC 稳定性、RKE1 集群导入兼容性、以及与 Kubernetes 1.18–1.20 的长期适配上，反而是大量金融、制造类客户线上稳定运行超 2 年的“玄学黄金组合”。
2. 镜像包结构解析与核心组件定位：从 tar 包解压到镜像加载的四步闭环
这份 Rancher V2.4.5 镜像包本质是一个经过docker save导出、再tar -c打包的归档文件，内部结构高度结构化。它不依赖 registry 配置、不隐式 pull、不触发任何后台自动更新逻辑——所有行为都在你显式执行的命令中。理解其物理构成，是避免后续“镜像找不到”“容器起不来”这类低级翻车的第一道防线。
2.1 解压后目录树与关键文件语义
拿到.tar文件后，先执行标准解压（注意保留权限）：
tar -xvf rancher-v2.4.5-offline-images.tar -C ./rancher-offline解压后你会看到如下核心目录结构：
./rancher-offline/ ├── images/ # 所有 docker 镜像的 .tar 归档（非 layer 层，是 save 后的完整镜像包） │ ├── rancher-rancher:v2.4.5.tar │ ├── rancher-agent:v2.4.5.tar │ ├── rancher-cli:v2.4.5.tar │ ├── rancher-backup-restore-operator:v2.4.5.tar │ └── ... # 还包括 busybox、nginx、cert-manager 相关基础镜像 ├── manifests/ # 启动所需的 YAML 模板与配置说明 │ ├── rancher-server.yaml # 标准单节点 server 部署模板（含 PV/PVC 建议） │ ├── rancher-agent.yaml # agent 注册模板（含 cluster-registration-token 提取方式） │ └── config.env # 环境变量参考表（如 CATTLE_SYSTEM_DEFAULT_REGISTRY） ├── scripts/ # 实用脚本集 │ ├── load-images.sh # 批量加载所有 images/*.tar 到本地 docker daemon │ ├── verify-checksums.sh # 校验每个 .tar 文件 SHA256（防传输损坏） │ └── gen-token.sh # 快速生成 cluster-registration-token 的封装 └── README.md # 版本声明、已知限制、适用 Kubernetes 版本范围提示：
images/下每个.tar文件都对应一个docker image，不是 layer。rancher-rancher:v2.4.5.tar是 server 主体，不是rancher/rancher:v2.4.5—— 后者是官方在线镜像名，而本包中镜像名已重命名为rancher-rancher，这是为规避内网 registry push 时命名冲突做的预处理，也是后续load-images.sh脚本能精准识别的关键。
2.2load-images.sh脚本逐行拆解：为什么它比docker load手动循环更可靠
直接for i in images/*.tar; do docker load < $i; done看似简单，但在批量加载 20+ 镜像时极易因某一个镜像损坏或磁盘 IO 波动导致部分失败、部分成功，最终状态不可知。load-images.sh的设计目标是：原子性加载 + 可中断恢复 + 错误定位精确到文件名。
#!/bin/bash # scripts/load-images.sh（精简注释版） set -e # 任一命令失败即退出，避免静默跳过 IMAGE_DIR="$(dirname "$0")/../images" LOG_FILE="/tmp/rancher-load-$(date +%s).log" echo "【开始加载】共 $(ls ${IMAGE_DIR}/*.tar 2>/dev/null | wc -l) 个镜像" | tee -a "$LOG_FILE" for img_tar in ${IMAGE_DIR}/*.tar; do if [[ ! -f "$img_tar" ]]; then continue; fi img_name=$(basename "$img_tar" .tar) # 如 rancher-rancher:v2.4.5 echo "→ 正在加载: $img_name" | tee -a "$LOG_FILE" # 关键：使用 docker load --input 显式指定输入源，避免管道中断风险 if ! docker load --input "$img_tar" >> "$LOG_FILE" 2>&1; then echo "❌ 加载失败: $img_tar" | tee -a "$LOG_FILE" echo "💡 建议检查：1) $img_tar 是否完整 2) docker daemon 是否运行 3) 磁盘空间是否充足" | tee -a "$LOG_FILE" exit 1 fi echo "✅ 加载成功: $img_name" | tee -a "$LOG_FILE" done echo "【全部完成】镜像已就绪，执行 'docker images | grep rancher' 验证" | tee -a "$LOG_FILE"逻辑说明与参数说明：
set -e是血泪经验：早期某客户因未加此 flag，busybox.tar加载失败但脚本继续执行，结果rancher-server启动时报exec: \"sh\": executable file not found，排查 3 小时才发现是基础镜像缺失。docker load --input "$img_tar"比docker load < "$img_tar"更健壮：前者将文件路径传给 docker daemon 内部处理，后者依赖 shell 管道，在高负载机器上易出现Broken pipe。- 日志写入
$LOG_FILE是为了事后审计：当某次加载卡在第 17 个镜像时，直接tail -n 20 $LOG_FILE就能看到最后成功的是哪个、失败的是哪个，无需重跑全量。
2.3 镜像加载后验证：三步确认法（非仅docker images）
加载完成后，仅靠docker images | grep rancher看到镜像存在是远远不够的。Rancher V2.4.5 对镜像元数据（如LABEL io.rancher.version）和 layer 结构有强校验，必须执行以下三步验证：
标签一致性检查：V2.4.5 的 server 镜像必须带
io.rancher.version=v2.4.5标签，否则启动时会报version mismatch。执行：docker inspect rancher-rancher:v2.4.5 | jq -r '.[0].Config.Labels."io.rancher.version"' # ✅ 应输出 v2.4.5；❌ 若为空或 v2.4.6，则说明镜像来源混杂或加载错误架构匹配检查：Rancher V2.4.5 官方仅提供
linux/amd64构建，若你的节点是 ARM64（如树莓派集群），强行加载会启动失败且报错极不明确（standard_init_linux.go:211: exec user process caused "exec format error"）。验证命令：docker inspect rancher-rancher:v2.4.5 | jq -r '.[0].Architecture' # ✅ 必须为 amd64；❌ 若为 arm64，则需重新获取对应架构镜像包（本包不提供）镜像大小合理性判断：
rancher-rancher:v2.4.5.tar解压后应约为 1.2GB（压缩包约 480MB），若du -sh images/rancher-rancher:v2.4.5.tar显示仅 200MB，则大概率是docker save时漏掉了某些 layer（常见于构建时 cache miss 导致 multi-stage 中间镜像未保存）。此时docker load虽成功，但运行时会pull access denied。
3. 单节点 Rancher Server 部署实战：从docker run到 HTTPS 可访问的七项必设参数
Rancher V2.4.5 的 server 镜像（rancher-rancher:v2.4.5）启动看似只需一行docker run，但生产环境要求 HTTPS、持久化、高可用预备、安全加固四项硬指标。下面给出一个最小可行但生产就绪的启动命令，并逐参数解释其不可省略性。
3.1 生产级docker run命令（含注释）
docker run -d \ --restart=unless-stopped \ --name=rancher-server \ --privileged \ -v /opt/rancher:/var/lib/rancher \ # 【必设】挂载宿主机目录，实现 etcd 数据持久化 -v /opt/rancher/logs:/var/log/rancher \ # 【建议】日志落盘，便于问题追溯 -p 80:80 -p 443:443 \ # 【必设】端口映射，Rancher 强制监听 80/443 -e CATTLE_SYSTEM_DEFAULT_REGISTRY=10.10.10.10:5000 \ # 【必设】内网 registry 地址，agent 自动拉取镜像用 -e CATTLE_SERVER_URL=https://rancher.yourdomain.com \ # 【必设】前端访问地址，影响所有 agent 的注册 endpoint -e CATTLE_TLS_MIN_VERSION=1.2 \ # 【安全必设】禁用 TLS 1.0/1.1，满足等保要求 rancher-rancher:v2.4.5参数说明与原理：
--privileged：Rancher agent 需要操作 iptables、mount namespace、cgroup，非 root 用户无法完成。V2.4.5 未提供非特权模式支持，这是该版本的设计约束，不是 bug。-v /opt/rancher:/var/lib/rancher：/var/lib/rancher是 Rancher Server 的数据根目录，包含 embedded etcd 数据、证书、集群配置。若不挂载，容器重启后所有集群状态丢失，等于白装。-e CATTLE_SYSTEM_DEFAULT_REGISTRY：这是 Rancher V2.4.5 的“镜像代理开关”。当用户在 UI 中添加新集群时，Rancher 会自动将rancher-agent、rke-tools等镜像的拉取地址，从默认的rancher域名替换为该环境变量值。若内网无 registry，此处必须设为localhost:5000并提前推送镜像，否则 agent 启动必失败。-e CATTLE_SERVER_URL：该值将写入所有 agent 的registration.yaml中作为server-url。若设为http://localhost或https://127.0.0.1，agent 将尝试连接自身，导致注册失败。必须是集群外部可解析、可路由的 FQDN。
3.2 HTTPS 强制启用与证书注入：绕过浏览器警告的两种路径
Rancher V2.4.5 默认生成自签名证书，浏览器访问https://rancher.yourdomain.com会显示严重警告。生产环境必须替换为可信证书。有两种注入方式：
方式一：挂载证书目录（推荐，无需重建容器）
准备证书文件到宿主机：
mkdir -p /opt/rancher/tls cp your-domain.crt /opt/rancher/tls/cert.pem cp your-domain.key /opt/rancher/tls/key.pem cp ca-bundle.crt /opt/rancher/tls/cacerts.pem # 若使用私有 CA然后重启容器，增加挂载和参数：
docker stop rancher-server docker rm rancher-server docker run -d \ ... # 其他原有参数保持不变 \ -v /opt/rancher/tls:/container/tls \ -e CATTLE_TLS_CERT=/container/tls/cert.pem \ -e CATTLE_TLS_KEY=/container/tls/key.pem \ -e CATTLE_TLS_CACERTS=/container/tls/cacerts.pem \ rancher-rancher:v2.4.5方式二：使用 Let's Encrypt（需外网 DNS 可控）
仅适用于测试环境或允许 ACME 协议的 DMZ 区域。启动时添加：
-e CATTLE_LETSENCRYPT_EMAIL=admin@yourdomain.com \ -e CATTLE_LETSENCRYPT_HOSTNAME=rancher.yourdomain.comRancher 会自动调用 Let's Encrypt API 申请证书。但注意：V2.4.5 的 ACME client 不支持通配符证书，且首次申请需 2~3 分钟，期间访问会 502。
3.3 首次访问与初始密码设置：UI 初始化的隐藏门控
容器启动后，docker logs -f rancher-server会持续输出Waiting for server to become available...，这并非卡死，而是 Rancher 正在初始化 embedded etcd 和 bootstrap 用户。首次访问https://rancher.yourdomain.com时，页面不会立即出现登录框，而是跳转到/verify路径，要求你输入初始管理员密码。
这个密码不是随机生成的，而是由 Rancher 在首次启动时，根据/var/lib/rancher/management-state/admin-password.txt文件内容设定。该文件在容器内生成，但因我们挂载了/opt/rancher，所以实际位于宿主机：
cat /opt/rancher/management-state/admin-password.txt # 输出类似：q9XzKmLpRtYvNwEjFgHk注意：该文件仅在首次启动时创建，后续重启不会覆盖。若误删，可通过
docker exec -it rancher-server bash -c 'echo $(openssl rand -base64 12)' > /var/lib/rancher/management-state/admin-password.txt重置，但需重启容器。
4. Rancher Agent 注册全流程：从集群导入到节点就绪的五个关键断点
Rancher Server 起来后，下一步是将现有 K8s 集群（或新建 RKE 集群）导入管理。Agent 是 Rancher 与下游集群通信的唯一通道，其注册过程涉及 Server 端 token 生成、Agent 端命令执行、网络连通性、证书信任链四个层面。任何一个环节断裂，都会表现为“集群状态 Pending”或“Nodes Not Ready”。
4.1 Cluster Registration Token 的安全提取与生命周期管理
在 Rancher UI 的Cluster Management → Create → Import Existing Cluster流程中，点击Next后会生成一段curl命令。但该命令中的 token（形如cluster-registration-token-c-abcde:xyz123...）有效期仅 24 小时，且一旦被用于注册，该 token 即失效，不可复用。
正确做法是：在 UI 中生成后，立即将其导出为环境变量，供脚本调用：
# 在 Server 节点执行（假设已安装 rancher-cli） export CLUSTER_TOKEN="cluster-registration-token-c-abcde:xyz123..." export CLUSTER_NAME="prod-cluster-01" export SERVER_URL="https://rancher.yourdomain.com"然后在目标集群任一 master 节点执行注册命令（注意：必须在 kubectl context 指向目标集群的前提下）：
curl --insecure -sfL https://rancher.yourdomain.com/v3/import/$CLUSTER_TOKEN.yaml | kubectl apply -f -提示：
--insecure是因为首次访问时证书未被系统信任，但 Rancher 会自动下发 CA 证书到集群，后续通信即走可信链。若你已将 Rancher 的 CA 证书导入系统信任库，可去掉--insecure。
4.2 Agent Pod 状态诊断：从CrashLoopBackOff到Running的三类高频原因
执行kubectl get pods -A | grep cattle后，若看到cattle-cluster-agent或cattle-node-agent处于CrashLoopBackOff，不要急着重启，先看日志：
kubectl logs -n cattle-system deploy/cattle-cluster-agent # 或查看 node agent kubectl logs -n cattle-system daemonset/cattle-node-agent -c agent现象 1：x509: certificate signed by unknown authority
→ 原因：Agent 容器内的 CA 证书库未更新，或 Rancher Server 的证书被替换但未触发 agent 证书轮换。
→ 解决：删除cattle-system命名空间下所有secret（kubectl delete secret -n cattle-system），然后kubectl delete pod -n cattle-system -l app=cattle-cluster-agent，Rancher 会自动重建并注入新证书。
现象 2：Failed to connect to upstream或connection refused
→ 原因：Agent 尝试连接https://rancher.yourdomain.com失败，常见于 DNS 解析失败（集群内 CoreDNS 未配置上游）、或 Server 节点防火墙拦截 443 端口。
→ 解决：在 agent 所在节点执行nslookup rancher.yourdomain.com和curl -vk https://rancher.yourdomain.com/healthz，确认网络可达性。
现象 3：no such host或i/o timeout
→ 原因：CATTLE_SERVER_URL设置错误，或 agent 镜像拉取失败（CATTLE_SYSTEM_DEFAULT_REGISTRY未生效）。
→ 解决：进入 agent 容器kubectl exec -it -n cattle-system deploy/cattle-cluster-agent -- sh，检查/etc/rancher/agent/config.json中的server-url字段是否与预期一致。
4.3 节点就绪判定标准：不止是Ready状态
在 Rancher UI 的Cluster Explorer → Nodes页面，一个节点显示Ready仅代表 kubelet 健康，但 Rancher 要求更高：
| 检查项 | 命令 | 合格标准 |
|---|---|---|
| Node Agent DaemonSet 是否全部 Running | kubectl get ds -n cattle-system cattle-node-agent | READY列 =DESIRED |
| Cluster Agent Deployment 是否 Running | kubectl get deploy -n cattle-system cattle-cluster-agent | AVAILABLE≥ 1 |
Node Label 是否包含node-role.kubernetes.io/controlplane=true | kubectl get node <node-name> -o wide | LABELS字段含该 key |
Node Annotation 是否含rke.cattle.io/external-ip | kubectl get node <node-name> -o jsonpath='{.metadata.annotations}' | 存在且值为该节点可路由 IP |
只有全部满足，Rancher 才认为该节点“完全就绪”，可调度 workloads。
5. 避坑指南：Rancher V2.4.5 镜像包部署中五个真实踩过的坑
这些不是文档里的 warning，而是某开发者在某制造企业私有云项目中，连续 3 天熬夜后记下的血泪笔记。每一条都对应一次线上故障或数小时无效排查。
5.1 坑一：docker load成功但docker run报no such image
→ 现象：docker load --input rancher-rancher:v2.4.5.tar返回Loaded image: rancher-rancher:v2.4.5，但docker run rancher-rancher:v2.4.5报Unable to find image 'rancher-rancher:v2.4.5' locally。
→ 原因：Docker daemon 启动时指定了--graph参数（如--graph=/data/docker），而load命令默认加载到/var/lib/docker，导致镜像存放在两个不同目录。
→ 解决：确认docker info | grep "Docker Root Dir"输出路径，若非/var/lib/docker，则load时需先export DOCKER_GRAPH=/data/docker，或改用docker load --input并确保 daemon 使用默认路径。
5.2 坑二：Agent 注册后集群状态Unavailable，但所有 Pod 都 Running
→ 现象：UI 显示集群红标Unavailable，点进去看System Project下所有 workload 都是Active，kubectl get nodes也正常。
→ 原因：Rancher V2.4.5 的健康检查依赖kube-system命名空间下的coredns、metrics-server、calico-node（或对应 CNI）三个组件的 readiness probe。若其中任一 probe 失败（如 coredns 配置错误导致无法解析kubernetes.default.svc），Rancher 即判定集群不可用。
→ 解决：kubectl get pods -n kube-system，重点检查这三个组件的READY列（如1/1表示就绪），再kubectl logs查看 probe 日志。常见修复是修正 coredns 的forward . 8.8.8.8为内网 DNS。
5.3 坑三：rancher-backup-restore-operator启动失败，报failed to list *v1.Secret: secrets is forbidden
→ 现象：Operator Pod 一直CrashLoopBackOff，日志显示 RBAC 权限不足。
→ 原因：该 Operator 需要cluster-admin权限才能备份所有命名空间的 Secret，但 Rancher V2.4.5 的默认 ServiceAccountcattle-backup仅被授予admin角色，缺少secrets资源的list/watch权限。
→ 解决：手动编辑 ClusterRoleBinding：
kubectl edit clusterrolebinding cattle-backup-binding # 在 subjects 下添加： # - kind: ServiceAccount # name: cattle-backup # namespace: cattle-resources-system # 在 roleRef 下确保指向 cluster-admin5.4 坑四：通过CATTLE_SYSTEM_DEFAULT_REGISTRY指定的内网 registry，Agent 仍去拉取rancher/rancher-agent:v2.4.5
→ 现象：Server 启动时日志显示Using system default registry: 10.10.10.10:5000，但 agent Pod 的 event 显示Pulling image "rancher/rancher-agent:v2.4.5"。
→ 原因：CATTLE_SYSTEM_DEFAULT_REGISTRY仅影响 Rancher Server 自身的镜像拉取行为，对 agent 的镜像地址无影响。Agent 的镜像地址由ClusterCRD 的spec.rancherKubernetesEngineConfig.services.kubeApi.podSecurityPolicy等字段间接控制，但 V2.4.5 中最直接的方式是：在导入集群时，UI 生成的import.yaml中手动将image:字段前缀改为10.10.10.10:5000/rancher/。
→ 解决：下载 UI 生成的import.yaml，搜索rancher/rancher-agent，替换为10.10.10.10:5000/rancher/rancher-agent，再kubectl apply -f。
5.5 坑五：rancher-cli登录后执行rancher clusters返回空，但 UI 可见集群
→ 现象：CLI 配置正确（rancher login https://rancher.yourdomain.com --token token-xxx:yyy），rancher context switch也成功，但rancher clusters无输出。
→ 原因：Rancher V2.4.5 的 CLI 默认只列出当前 context 所属 Project 下的资源，而clusters是全局资源，需显式指定--all-namespaces或切换到localcluster 的 context。
→ 解决：先rancher context switch local，再执行rancher clusters；或直接rancher --context local clusters。
6. 进阶技巧：用rancher-backup-restore-operator实现分钟级集群状态快照与回滚
Rancher V2.4.5 内置的 backup-restore-operator 不是摆设，它是你应对配置误操作、CRD 意外删除、甚至 etcd 数据损坏的“后悔药”。但它的使用门槛在于：备份不是简单打个快照，而是要理解 Rancher 的数据分层模型——Management Plane（Rancher Server 自身状态）和 Cluster Plane（被管集群的 Kubernetes 资源）必须分开备份，且 restore 顺序不可逆。
6.1 Rancher 数据分层与备份策略映射表
| 数据层级 | 存储位置 | 是否包含在rancher-backup-restore-operator备份中 | 备份频率建议 | 恢复依赖 |
|---|---|---|---|---|
| Management Plane（MP） | /var/lib/rancher（etcd + certs + management-state） | ✅ 是，operator 默认备份此目录 | 每日 1 次（cronjob） | 无，可独立 restore |
| Cluster Plane（CP） | 被管集群的 etcd（如prod-cluster-01的 etcd） | ❌ 否，operator 不触碰下游集群存储 | 由 RKE 或集群自身 backup 方案负责 | MP 恢复后，需先 restore CP 再启动 MP |
提示：这就是为什么 operator 的
BackupCR 必须指定resourceSetName: rancher-management—— 它只认这个 resource set，其他名字无效。
6.2 创建一次可靠的 backup：从 CR 定义到验证
在cattle-resources-system命名空间下创建Backup资源：
# backup-mp.yaml apiVersion: resources.cattle.io/v1 kind: Backup metadata: name: mp-daily-backup namespace: cattle-resources-system spec: resourceSetName: rancher-management storageLocation: s3: bucketName: rancher-backups region: us-east-1 endpoint: http://10.10.10.10:9000 # MinIO 地址 accessKey: minio-access-key secretKey: minio-secret-key应用后，operator 会自动创建一个 Job 执行备份。验证是否成功：
# 查看 Backup 状态 kubectl get backup -n cattle-resources-system mp-daily-backup -o wide # STATUS 应为 Completed，MESSAGE 为 "Backup completed successfully" # 查看 S3 中文件（以 MinIO 为例） mc ls myminio/rancher-backups/ # 应看到类似：2024-06-15T02:00:00Z-rancher-management-<hash>.zip6.3 恢复操作：三步不可逆流程与时间窗口控制
Restore 不是kubectl apply就完事，它是一次 Rancher Server 的“冷重启”，必须严格遵循：
- 停止 Rancher Server 容器：
docker stop rancher-server，确保无写入。 - 执行 restore Job：创建
RestoreCR，指向刚才的 backup：apiVersion: resources.cattle.io/v1 kind: Restore metadata: name: mp-restore-20240615 namespace: cattle-resources-system spec: backupFilename: 2024-06-15T02:00:00Z-rancher-management-<hash>.zip storageLocation: s3: bucketName: rancher-backups region: us-east-1 endpoint: http://10.10.10.10:9000 accessKey: minio-access-key secretKey: minio-secret-key - 等待 restore Job 完成并重启 Server：
kubectl get restore -n cattle-resources-system看STATUS为Completed后，docker start rancher-server。
关键细节：restore 过程中，operator 会清空
/var/lib/rancher下所有内容，再解压 zip。因此，restore 前必须确保/opt/rancher挂载点未被其他进程占用（如 rsync 正在同步），否则 restore Job 会卡在Terminating状态，且无法 force delete。
从那以后我每次做重大配置变更（如全局 registry 修改、RBAC 策略调整）前，都强制走一遍rancher backup create --name pre-change-$(date +%Y%m%d-%H%M)，哪怕只是改一行 annotation。不是信不过自己，是信不过人类在凌晨三点的判断力。希望帮到你。
本文还有配套的精品资源，点击获取
