主题
日常运维手册
集群: K3s v1.35.4+k3s1 | 3 Master (.38/.39/.40) + 1 Worker (.41) 管理平面: Rancher Prime 最后更新: 2026-08-31 使用方式: 第 1~2 节日常必用,建议打印;遇到问题先查第 10 节
目录
- 1. 运维命令速查表
- 2. 日常巡检
- 3. 节点运维
- 4. 工作负载运维
- 5. K3s 服务管理
- 6. etcd 备份与恢复
- 7. 集群升级
- 8. 证书管理
- 9. 存储与磁盘运维
- 10. 故障排查手册
- 11. 安全基线
- 12. 应急预案与灾备
1. 运维命令速查表
1.1 节点上的系统命令
| 场景 | 命令 (Master) | 命令 (Worker) |
|---|---|---|
| 服务状态 | systemctl status k3s | systemctl status k3s-agent |
| 启动/停止/重启 | systemctl start/stop/restart k3s | systemctl start/stop/restart k3s-agent |
| 实时日志 | journalctl -u k3s -f | journalctl -u k3s-agent -f |
| 版本 | k3s --version | k3s --version |
| kubectl | k3s kubectl ...(建议 alias kubectl='k3s kubectl') | 无 |
| 配置文件 | /etc/rancher/k3s/config.yaml | 同左 |
| 镜像仓库配置 | /etc/rancher/k3s/registries.yaml | 同左 |
| kubeconfig | /etc/rancher/k3s/k3s.yaml | 无 |
| 节点令牌 | /var/lib/rancher/k3s/server/node-token | 无 |
| 数据目录 | /var/lib/rancher/k3s/ | /var/lib/rancher/k3s/agent |
| 卸载 | k3s-uninstall.sh | k3s-agent-uninstall.sh |
1.2 kubectl 日常命令(任一 Master 上,前缀 k3s)
bash
# 集群状态
kubectl get nodes -o wide # 节点列表
kubectl get pods -A # 所有 Pod
kubectl get pods -A -o wide | grep -v Running # 快速找异常
kubectl top nodes && kubectl top pods -A # 资源用量 (需 metrics-server)
kubectl get events -A --sort-by=.lastTimestamp | tail -20 # 最近事件
# 工作负载
kubectl -n <ns> rollout status deploy/<name> # 观察发布进度
kubectl -n <ns> rollout undo deploy/<name> # 回滚上一版本
kubectl -n <ns> scale deploy/<name> --replicas=3 # 扩缩容
kubectl -n <ns> rollout restart deploy/<name> # 滚动重启
# 排错
kubectl describe pod <pod> -n <ns> # 事件与调度信息
kubectl logs <pod> -n <ns> --previous # 上次崩溃的日志
kubectl logs -f <pod> -n <ns> -c <容器> # 实时日志
kubectl exec -it <pod> -n <ns> -- sh # 进容器
kubectl get pod <pod> -n <ns> -o yaml # 完整定义
# 节点维护
kubectl cordon <node> # 暂停调度 (维护前)
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data # 排空
kubectl uncordon <node> # 恢复调度2. 日常巡检
2.1 每日巡检清单(5 分钟)
| # | 检查项 | 方式 | 通过标准 |
|---|---|---|---|
| 1 | 集群卡片状态 | Rancher UI Home | Active,无红色告警 |
| 2 | 节点状态 | UI Dashboard 或 kubectl get nodes | 4/4 Ready |
| 3 | 系统组件 | kubectl get pods -n kube-system | 全部 Running |
| 4 | cattle-agent | kubectl -n cattle-system get pods | Running(否则 UI 失联) |
| 5 | 业务 Pod | kubectl get pods -A | grep -v Running | 无异常 |
| 6 | 磁盘水位 | 各节点 df -h | 使用率 < 80% |
| 7 | etcd 快照 | k3s etcd-snapshot list | head | 最新快照 < 12 小时前 |
| 8 | 证书有效期 | 每周: 见第 8 节 | 剩余 > 30 天 |
2.2 一键巡检脚本
保存为 /usr/local/bin/k3s-health-check.sh(放在任一 Master):
bash
#!/bin/bash
# k3s-health-check.sh — K3s 集群一键巡检
set -uo pipefail
G='\033[0;32m'; R='\033[0;31m'; Y='\033[0;33m'; N='\033[0m'
K="k3s kubectl"
echo "========= K3s 巡检 $(date '+%F %T') ========="
# 1. 节点
echo -e "\n[1] 节点状态"
NOT_READY=$($K get nodes --no-headers | grep -cv " Ready" || true)
$K get nodes -o wide
[ "$NOT_READY" -eq 0 ] && echo -e " ${G}OK: 全部 Ready${N}" || echo -e " ${R}FAIL: ${NOT_READY} 个节点异常${N}"
# 2. 异常 Pod
echo -e "\n[2] 异常 Pod"
BAD=$($K get pods -A --no-headers | grep -Ev "Running|Completed" || true)
if [ -z "$BAD" ]; then echo -e " ${G}OK: 无异常${N}"; else echo -e " ${R}$BAD${N}"; fi
# 3. cattle-agent (Rancher 纳管)
echo -e "\n[3] Rancher agent"
$K -n cattle-system get pods -o wide 2>/dev/null || echo -e " ${Y}未纳管${N}"
# 4. etcd 最近快照
echo -e "\n[4] etcd 快照"
SNAP=$(k3s etcd-snapshot list 2>/dev/null | head -2 | tail -1 | awk '{print $1,$4,$5}')
[ -n "$SNAP" ] && echo -e " ${G}最近快照: $SNAP${N}" || echo -e " ${Y}未找到快照${N}"
# 5. 磁盘
echo -e "\n[5] 数据目录磁盘"
df -h /var/lib/rancher/k3s | tail -1 | awk '{print " 已用: "$5" ("$2" 总量)"}'
# 6. 内存
echo -e "\n[6] 节点内存"
free -h | grep Mem | awk '{printf " 本机已用 %s / %s\n",$3,$2}'
echo -e "\n========= 巡检结束 ========="bash
chmod +x /usr/local/bin/k3s-health-check.sh
# 可选: 每天早上 8 点自动巡检并记录
echo '0 8 * * * root /usr/local/bin/k3s-health-check.sh >> /var/log/k3s-check.log 2>&1' \
> /etc/cron.d/k3s-check3. 节点运维
3.1 节点标签与污点(控制业务落点)
bash
# 给 Worker 打标签, 让业务优先跑在 Worker 上
kubectl label node szb122041 node-role.kubernetes.io/worker=true
# (可选) 禁止业务调度到 Master: 给 3 台 Master 打污点
for n in szb122038 szb122039 szb122040; do
kubectl taint nodes $n node-role.kubernetes.io/master=true:NoSchedule
doneDeployment 中声明只去 Worker:
yaml
spec:
template:
spec:
nodeSelector:
node-role.kubernetes.io/worker: "true"3.2 扩容新 Worker
新机器完成 01 文档 6.3/6.4 初始化后:
bash
# 新节点上执行 (token 取任一 Master 的 /var/lib/rancher/k3s/server/node-token)
INSTALL_K3S_SKIP_DOWNLOAD=true \
K3S_URL=https://192.168.122.38:6443 \
K3S_TOKEN=<node-token内容> \
bash k3s-install.sh验证:kubectl get nodes 出现新节点且 Ready; Rancher UI 集群节点数自动 +1(无需重新导入)。
3.3 下线一台 Worker
bash
kubectl cordon szb122041 # 停止调度新 Pod
kubectl drain szb122041 --ignore-daemonsets --delete-emptydir-data # 驱逐现有 Pod
# 确认业务迁移完成后, 在节点上执行:
k3s-agent-uninstall.sh
# 再从集群删除节点对象:
kubectl delete node szb122041⚠️ 本集群只有 1 台 Worker,下线前先扩容新 Worker,或确认业务允许调度到 Master。
3.4 更换/重装一台 Master
原则:逐台操作,任何时刻至少保持 2 台 Master 在线(法定人数)。
kubectl cordon <旧Master>,确认其上没有关键业务(或容忍短暂中断);- 从 etcd 集群移除该成员(在健康 Master 上):
bash
ETCD=/var/lib/rancher/k3s/data/current/bin/etcdctl
TLS=/var/lib/rancher/k3s/server/tls/etcd
ETCDCTL_API=3 $ETCD --endpoints=https://127.0.0.1:2379 \
--cacert=$TLS/server-ca.crt --cert=$TLS/client.crt --key=$TLS/client.key \
member list # 找到旧成员 ID
ETCDCTL_API=3 $ETCD --endpoints=https://127.0.0.1:2379 \
--cacert=$TLS/server-ca.crt --cert=$TLS/client.crt --key=$TLS/client.key \
member remove <ID>- 旧节点执行
k3s-uninstall.sh清理(或重装系统); - 新机器按 7.2 的 server 加入命令挂回集群(数据目录须为空);
kubectl delete node <旧节点>清理旧节点对象,kubectl uncordon新节点。
4. 工作负载运维
4.1 发布 / 回滚
bash
# 发布新版本 (改镜像即触发滚动更新)
kubectl -n demo set image deploy/nginx-demo nginx=192.168.122.156:30000/library/nginx:1.27
# 观察进度
kubectl -n demo rollout status deploy/nginx-demo
# 查看历史版本
kubectl -n demo rollout history deploy/nginx-demo
# 回滚到上一版 / 指定版本
kubectl -n demo rollout undo deploy/nginx-demo
kubectl -n demo rollout undo deploy/nginx-demo --to-revision=2建议给 Deployment 配置发布策略与就绪探针(readinessProbe), 否则滚动更新可能出现短暂 502:
yamlstrategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } }
4.2 扩缩容
bash
kubectl -n demo scale deploy/nginx-demo --replicas=5
# 或 UI: Workload 列表行 ⋮ → Scale自动扩缩(HPA)示例(依赖 metrics-server,K3s 已内置):
bash
kubectl -n demo autoscale deploy/nginx-demo --min=2 --max=10 --cpu-percent=70
kubectl -n demo get hpa # 观察4.3 重启与清理
bash
kubectl -n demo rollout restart deploy/nginx-demo # 滚动重启全部副本
kubectl -n demo delete pod <卡住的pod> --grace-period=0 --force # 强制删卡死 Pod5. K3s 服务管理
5.1 重启注意事项
| 操作 | 影响 | 说明 |
|---|---|---|
| 重启 1 台 Master | 秒级 API 抖动 | etcd 仍有 2 成员,集群可用;建议先 cordon |
| 重启 2 台 Master | ⚠️ 失去多数派 | 禁止同时操作 |
| 重启 Worker | 节点上 Pod 短暂不可用 | 有副本的应用自动漂移,建议先 drain |
| 停止全部 Master | 控制面下线 | 已运行 Pod 短期仍在,但无法自愈/变更 |
5.2 修改启动参数
bash
# 1. 编辑配置 (优于改 systemd 命令行)
vi /etc/rancher/k3s/config.yaml # 例: 追加 --disable=traefik
# 2. 重启服务
systemctl restart k3s # Master
systemctl restart k3s-agent # Worker常见参数:
--disable=traefik(换 Ingress)、--node-label、--kubelet-arg=eviction-hard=...、--snapshot-cron(定时快照,见 6.1)。
6. etcd 备份与恢复
6.1 定时快照(强烈建议第一天就配置)
在 3 台 Master 的 /etc/rancher/k3s/config.yaml 中加入:
yaml
etcd-snapshot-schedule-cron: "0 */6 * * *" # 每 6 小时
etcd-snapshot-retention: 28 # 保留 28 份
etcd-snapshot-dir: /var/lib/rancher/k3s/server/db/snapshots然后 systemctl restart k3s。验证:k3s etcd-snapshot list。
生产环境建议再把快照目录通过 cron + rsync 同步到集群外的备份机, 防止整机磁盘损坏导致快照与数据同时丢失。
6.2 手动快照与查看
bash
k3s etcd-snapshot save --name before-upgrade # 立即备份
k3s etcd-snapshot list # 列表
k3s etcd-snapshot delete <名称> # 删除6.3 从快照恢复(控制面损坏时)
⚠️ 恢复会丢弃快照之后的所有变更。恢复前尽量再
save一份当前快照。
场景 A:集群还能跑,想回到旧状态
bash
# 1. 在所有 Master 上停止服务
systemctl stop k3s
# 2. 在初始化节点 (.38) 上恢复
k3s server --cluster-reset --cluster-reset-restore-from <快照名>
# (该命令会重置 etcd 为单成员并恢复数据, 完成后提示可正常启动)
# 3. 启动 .38, 其余 2 台删除旧数据后重新加入:
systemctl start k3s # .38
# .39/.40:
systemctl stop k3s
rm -rf /var/lib/rancher/k3s/server/db
systemctl start k3s # 自动重新加入场景 B:3 台 Master 全部损坏(灾难恢复) 见 第 12 节应急预案。
恢复后验证:kubectl get nodes、k3s etcd-snapshot list、业务抽查。
7. 集群升级
7.1 升级策略
- 小版本滚动:v1.35.4+k3s1 → v1.35.x+k3sy(推荐,风险低);
- 跨次版本:v1.35 → v1.36,先在测试集群验证,逐台升级;
- 顺序:先 Master(一台一台),后 Worker;
- 升级前:
k3s etcd-snapshot save --name before-upgrade+ 业务低峰期。
7.2 方式一:Rancher UI 升级(导入的 K3s 集群)
Rancher 对导入的 K3s 集群支持 UI 编排升级:
- 集群管理 → 集群行
⋮→ Edit Config; - Kubernetes Version 下拉选择新版本(列表来自 Rancher 元数据; 气隙环境需先同步 Rancher 的 releases/镜像数据);
- 保存后 Rancher 通过 system-upgrade-controller 分批滚动升级节点, 可在集群事件/节点状态中观察进度。
若下拉框为空或升级卡住,改用方式二手动升级,更可控。
7.3 方式二:手动逐台升级(最稳妥)
bash
# === 每台机器依次执行: 先 .38, 再 .39/.40, 最后 .41 ===
# 1. (Master 可选) 先 cordon
kubectl cordon szb122038
# 2. 升级二进制 (气隙: 提前下载好新版二进制传到节点)
systemctl stop k3s # Worker 上是 k3s-agent
install -m 755 k3s-new /usr/local/bin/k3s
k3s --version # 确认新版本
systemctl start k3s
# 3. 验证本机
k3s kubectl get nodes # 本机 Ready 且 VERSION 已更新
# (Master) 4. uncordon
kubectl uncordon szb122038检查点:每台升完后确认 kubectl get nodes 全部 Ready、 kubectl get pods -A 无新增异常,再升下一台。
7.4 使用 system-upgrade-controller 自动升级(可选进阶)
K3s 官方提供 system-upgrade-controller, 通过 Plan CRD 声明式批量升级(适合节点多的场景)。 本集群 4 节点规模手动升级即可,此处不展开。
8. 证书管理
K3s 使用自签证书,有效期 1 年并自动轮换(到期前自动续期,通常无需干预)。 需要人工介入的两种情况:
8.1 查看证书有效期
bash
# 查看 API Server 服务证书 (最关键的一张)
openssl x509 -in /var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt \
-noout -subject -dates
# 批量扫描所有证书的到期时间
for f in /var/lib/rancher/k3s/server/tls/*.crt; do
END=$(openssl x509 -in "$f" -noout -enddate 2>/dev/null | cut -d= -f2)
[ -n "$END" ] && echo "$END $(basename $f)"
done | sort8.2 强制轮换证书
bash
systemctl stop k3s
k3s certificate rotate # 轮换所有证书
# 或只轮换指定: k3s certificate rotate --service api-server
systemctl start k3s轮换后如遇客户端报错,更新本地
k3s.yaml并清理浏览器缓存证书。
8.3 增加证书访问地址
客户端需要从新 IP/域名访问时(如新增 VIP),在启动参数追加 --tls-san <地址> 后重启即可,K3s 会自动重新签发证书。
9. 存储与磁盘运维
9.1 local-path 存储位置
K3s 内置的 local-path 默认把 PV 数据放在 /var/lib/rancher/k3s/storage/ 下。数据绑定节点,不做跨节点共享。
bash
kubectl get sc # 查看 StorageClass
kubectl get pvc -A # 所有 PVC 及其绑定状态
du -sh /var/lib/rancher/k3s/storage/* # 各卷实际占用9.2 清理磁盘
| 目录 | 内容 | 清理建议 |
|---|---|---|
/var/lib/rancher/k3s/agent/containerd/ | 容器镜像与运行时 | 不要手动删,用 crictl rmi --prune |
/var/lib/rancher/k3s/storage/ | PVC 数据 | 删 PVC 后自动回收 |
/var/log/journal/ | 系统日志 | journalctl --vacuum-size=500M |
/var/lib/rancher/k3s/server/db/snapshots/ | etcd 快照 | 按保留策略自动清理 |
清理未使用镜像(任一节点):
bash
k3s crictl rmi --prune # 删除未被任何容器引用的镜像9.3 磁盘告警阈值建议
| 目录 | 告警线 | 动作线 |
|---|---|---|
系统盘 / | 80% | 清日志、清镜像 |
/var/lib/rancher/k3s | 80% | 扩容磁盘或迁移存储 |
kubelet 自带磁盘压力驱逐:节点磁盘使用超过阈值会自动驱逐 Pod (默认 imagefs.available < 15%)。所以磁盘水位是最容易被忽视的故障源。
10. 故障排查手册
10.1 排查总流程
现象 → 定位层级:
├─ 集群级 (API 不通/etcd 异常) → 10.2 / 10.5
├─ 节点级 (NotReady) → 10.3
├─ Pod 级 (起不来/反复重启) → 10.4
├─ 网络级 (访问不通) → 10.6
└─ Rancher UI 失联 → 10.7通用三板斧:kubectl get events -A、kubectl describe、journalctl -u k3s -f。
10.2 API Server 无法访问
| 检查 | 命令 | 处置 |
|---|---|---|
| 服务是否存活 | systemctl status k3s | 不存活 → 查日志 journalctl -u k3s -n 100 |
| 端口是否监听 | ss -lntp | grep 6443 | — |
| etcd 是否有法定人数 | 3 台里至少 2 台 k3s 在跑 | 不足 → 恢复故障节点或走 6.3 |
| 证书过期 | openssl s_client -connect <ip>:6443 | 过期 → 8.2 轮换 |
10.3 节点 NotReady
bash
kubectl describe node <node> # 看 Conditions 哪一项 False
# 常见原因及处置:
# KubeletNotReady + 节点可 SSH → 登节点查: systemctl status k3s-agent; journalctl
# NetworkUnavailable → Flannel 异常: 重启该节点 k3s 服务
# DiskPressure / MemoryPressure → 磁盘/内存满, 清理或扩容 (第 9 节)
# 节点不可达 (NotReady+失联) → 先查机器本身: 电源/网络/宿主机10.4 Pod 异常速查
| Pod 状态 | 最可能原因 | 排查命令 / 处置 |
|---|---|---|
Pending | 资源不足 / 污点 / PVC 未绑定 | kubectl describe pod,看 Events |
ImagePullBackOff | 镜像名错 / Harbor 没有该镜像 | crictl pull <image> 在节点手动验证;同步镜像到 Harbor |
ErrImagePull + 自签仓库 | registries.yaml 未配 / 认证失败 | 检查 6.4 配置并 systemctl restart k3s(-agent) |
CrashLoopBackOff | 应用自身报错 | kubectl logs --previous 看崩溃前日志 |
ContainerCreating 卡住 | 网络插件/存储卷挂载 | describe pod 看具体挂载项 |
Evicted | 节点资源压力驱逐 | 清理节点资源,Pod 自动重建 |
本环境最高频问题就是 ImagePull 类:气隙环境所有镜像必须先进 Harbor, 新应用上线前先用
skopeo copy同步(参考../README.md第 4 节)。
10.5 etcd 故障
| 现象 | 处置 |
|---|---|
| 单台 etcd 成员掉线 | 修复该节点服务;多数派仍在,集群不中断 |
| 2 台同时掉线(无多数派) | 优先恢复原成员(重启服务);无法恢复时从快照恢复(6.3) |
| 数据损坏 | --cluster-reset 重置为单成员再重新加入其他节点(6.3) |
原则:先保多数派,再谈数据恢复;恢复前永远先做一次当前快照。
10.6 网络访问不通
bash
# 1. Pod 内自检
kubectl exec -it <pod> -- sh
wget -qO- http://127.0.0.1:<port> # 应用本身通不通
nslookup kubernetes.default # 集群 DNS 通不通
wget -qO- http://<svc>.<ns>.svc.cluster.local # Service 通不通
# 2. Service 是否有后端
kubectl get endpoints <svc> -n <ns> # 为空 = selector 没匹配到 Pod
# 3. Ingress 不通
kubectl get ingress -A # ADDRESS 是否分配
kubectl -n kube-system logs -l app.kubernetes.io/name=traefik --tail=50
# 检查 Host 头与规则是否匹配10.7 Rancher UI 集群失联 (Unavailable)
bash
# 1. agent 是否正常
kubectl -n cattle-system get pods
kubectl -n cattle-system logs deploy/cattle-cluster-agent --tail=50| 日志特征 | 原因 | 处置 |
|---|---|---|
x509: certificate signed by unknown authority | 信任链问题 | 重新生成注册命令并应用 |
CA checksum mismatch | Rancher CA 变更 | 删除并重建 agent(重新执行导入注册命令) |
connection refused / timeout | 节点到 Rancher 地址不通 | 核对 server-url、防火墙、DNS |
本环境曾发生过 cattle-cluster-agent CA checksum 故障,完整复盘见 hami/03-cattle-cluster-agent修复记录。
10.8 K3s 服务无法启动
bash
journalctl -u k3s -n 100 --no-pager # 看最后的错误| 日志特征 | 原因 | 处置 |
|---|---|---|
failed to get CA certs | server 地址不可达 | 检查 --server 地址与 6443 端口 |
token mismatch | 加入令牌错误 | 用 Master 的 node-token 重试 |
context deadline exceeded 拉镜像 | Harbor 不通 | 节点 curl -I http://192.168.122.156:30000/v2/ |
port is already in use | 端口占用 | ss -lntp 找到占用进程 |
| 启动卡住无日志 | 磁盘满 / inode 满 | df -h && df -i |
11. 安全基线
11.1 凭据管理
| 项 | 位置 | 要求 |
|---|---|---|
| K3S_TOKEN / node-token | Master /var/lib/rancher/k3s/server/node-token | 不外泄;泄露后轮换(见 11.3) |
| kubeconfig | /etc/rancher/k3s/k3s.yaml | 权限 600(生产),不要随意 --write-kubeconfig-mode 644 |
| Harbor 密码 | xxx | 以 credentials.md 为准,定期轮换 |
| Rancher admin | UI | 强密码 + 定期更换;生产对接 LDAP 后用组授权 |
11.2 日常安全习惯
- 最小权限:业务账号只给 Project/Namespace 级权限,不发 Cluster Owner;
- 镜像最小化:所有镜像过 Harbor,禁止节点直连外部仓库(气隙天然满足);
- 定期升级:K3s 补丁版本及时跟进(安全 CVE);
- 定期备份:etcd 快照 + 快照异地副本(6.1);
- 审计:重要变更(升级/删节点/恢复)登记到运维记录。
11.3 令牌轮换
怀疑 token 泄露时:
bash
# 在初始化 Master (.38) 上执行; -t 传入的是【当前/原 token】(node-token 内容)
systemctl stop k3s
k3s token rotate -t <当前token> # 随机生成新 token, 写入 server/token
systemctl start k3s
# 其余 Master / Worker 依次重启服务 (k3s / k3s-agent)
# 已建连节点依靠节点证书继续工作; 若有节点无法回连,
# 用新 token (/var/lib/rancher/k3s/server/node-token) 重新加入即可注意:轮换前先
k3s etcd-snapshot save;操作选在业务低峰期。
12. 应急预案与灾备
12.1 故障等级与响应
| 等级 | 定义 | 响应 |
|---|---|---|
| P1 | 控制面整体不可用 / 业务全面中断 | 立即处理,参考 12.2;必要时执行灾难恢复 |
| P2 | 单 Master 宕机 / 部分业务异常 | 30 分钟内介入,按第 10 节定位 |
| P3 | 单点隐患(磁盘水位高、证书将到期) | 当日处理 |
12.2 单点故障快速恢复卡
| 故障 | 业务影响 | 快速动作 |
|---|---|---|
| 1 台 Master 宕机 | 无(剩 2 台满足法定人数) | 修复/更换该节点(3.4),无需紧急恢复数据 |
| Worker 宕机 | 该节点 Pod 中断,有副本的自动漂移 | 修复节点;无副本业务考虑先手动在其他节点拉起 |
| Rancher 管理面宕机 | 仅 UI 不可用 | 集群照常运行;修复 Rancher 后 agent 自动重连 |
| 2 台 Master 宕机 | 控制面只读/不可写 | 优先拉起故障节点;失败则 6.3 从快照恢复 |
| 全集群损坏 | 全面中断 | 12.3 灾难恢复流程 |
12.3 灾难恢复流程(全集群重建)
前提:有 etcd 快照的异地副本 + K3s 二进制与镜像(Harbor)。
1. 准备 4 台干净机器(或清理旧机器: k3s-uninstall.sh + 清空 /var/lib/rancher/k3s)
2. 按 01 文档第 6~7 节重建集群(同版本、同 token 建议)
3. 停止服务, 用最近的异地快照执行 6.3 的恢复流程
4. 启动集群, 验证 node/pod/业务
5. 在 Rancher 中更新集群状态(必要时重新导入)
6. 复盘并归档恢复演练建议:每季度在隔离环境做一次快照恢复演练, 确认备份真实可用(没演练过的备份等于没有备份)。
附录:运维记录模板
每次重要操作建议按此格式追加记录(可放本目录 ops-log.md):
markdown
## <日期> <操作标题>
- 操作人 / 时间:
- 背景与目标:
- 执行步骤摘要:
- 验证结果:
- 回滚方案是否可用:
- 遗留事项:相关文档
| 文档 | 用途 |
|---|---|
| 01-零基础入门与集群原理 | 原理与建集群 |
| 02-Rancher-Prime-UI使用指南 | UI 操作 |
| 04-网络通信与节点故障影响分析 | 通信链路与宕机影响(与本文第 6/10/12 节配合) |
| ../README.md | 镜像清单与同步脚本 |
| ../../credentials.md | 凭据汇总 |