KnoAI 技术站

主题

rocky9-vm-04（192.168.122.190）故障排查报告 ​

生成时间：2026-07-14 18:42 (CST)
排查节点：rocky9-vm-04 / 192.168.122.190
登录方式：root@192.168.122.190
操作系统：Rocky Linux 9.8 (Blue Onyx)
内核版本：5.14.0-687.10.1.el9_8.0.1.x86_64
运行时长：约 1 小时（10:43 时 up 59 min）

1. 结论摘要 ​

该节点是 RKE2 集群的 control-plane + etcd + worker 三合一节点。当前节点本身 SSH 可登录、RKE2 server 进程在运行，但集群层面存在 多个级联故障，主要表现为：

  1. Rancher Server Pod 反复崩溃（CrashLoopBackOff，已重启 20 次），导致 imperative-api-extension 服务（10.12.1.9:6666）无法响应，rke2 代理持续报 502 / connection refused / no route to host。
  2. 集群节点 rocky9-vm-06 NotReady，Kubelet 自 09:07 起停止上报节点状态；大量 helm-operation Pod 被调度到该节点后长期 Pending。
  3. 私有镜像仓库缺镜像，导致 Fleet、Rancher-webhook、Rancher-turtles、system-upgrade-controller 等多个组件持续 ImagePullBackOff。
  4. 系统负载偏高（1/5/15 min 负载约 3–6），主要由 kube-apiserver、etcd、calico-node 及大量 Helm 操作占用。
  5. 系统层存在非致命告警：journal 损坏、EFI 分区未正常卸载、irqbalance 无法改 IRQ 亲和性、SELinux runtime disable 不支持、iptables 驱动已弃用。

2. 集群拓扑与节点状态 ​

节点角色IP状态备注
rocky9-vm-04control-plane,etcd,worker192.168.122.190Ready本次排查节点
rocky9-vm-05control-plane,etcd,worker192.168.122.231ReadyRancher Pod 运行在此节点
rocky9-vm-06control-plane,etcd,worker192.168.122.231NotReady与 vm-05 同 IP，疑似异常

⚠️ 注意：rocky9-vm-05 与 rocky9-vm-06 在 Kubernetes 中均注册为 192.168.122.231，存在 IP 冲突嫌疑，这很可能是 vm-06 失去心跳的根因之一。

2.1 rocky9-vm-06 关键状态 ​

text
Conditions:
  Ready                Unknown   Kubelet stopped posting node status.
  MemoryPressure       Unknown   NodeStatusUnknown
  DiskPressure         Unknown   NodeStatusUnknown
  PIDPressure          Unknown   NodeStatusUnknown
Taints:
  node.kubernetes.io/unreachable:NoExecute
  node.kubernetes.io/unreachable:NoSchedule
Lease RenewTime: 2026-07-14 08:05:44Z  (已长时间未更新)

3. 核心问题清单 ​

3.1 关键故障（影响 Rancher/集群功能） ​

优先级问题现象影响
P0Rancher Pod CrashLoopBackOffcattle-system/rancher-7b58694bc8-vrkdg 状态 CrashLoopBackOff，重启 20 次，启动探针失败Rancher UI/API 不可用；imperative-api-extension:6666 返回 502
P0节点 rocky9-vm-06 NotReadyKubelet 停止上报；大量 Pod Pending调度失败、工作负载中断、etcd 成员异常
P1私有仓库缺镜像fleet:v0.15.4、rancher-webhook:v0.10.7、kuberlr-kubectl:v7.1.0、rancher/turtles:v0.26.3 等拉取失败Fleet、Webhook、Turtles、system-upgrade-controller 无法部署
P1Pod 跨节点网络异常cert-manager liveness 探针 no route to host；rke2 到 10.12.1.9:6666 间歇性不可达服务健康检查失败、Rancher 组件通信异常
P2系统负载高load average 3–6 / 8 CPU；kube-apiserver 占 28% CPU、etcd 17%API 响应变慢、节点资源紧张

3.2 Pod 状态统计 ​

text
     34 Running
     23 Error
     14 Pending
      9 Completed
      6 ImagePullBackOff
      3 Terminating
      2 CrashLoopBackOff

3.3 异常 Pod 示例 ​

text
NAMESPACE               NAME                                                  READY   STATUS             RESTARTS
 cattle-fleet-system     fleet-controller-6d496b44c6-ghs48                     0/3     ImagePullBackOff   0
cattle-fleet-system     gitjob-746bdff858-6p64w                               0/1     ImagePullBackOff   0
cattle-fleet-system     helmops-7845cc4f55-mlwzw                              0/1     ImagePullBackOff   0
cattle-system           helm-operation-4lm26                                  0/2     Pending            0
cattle-system           helm-operation-9kt88                                  0/2     Pending            0
cattle-system           rancher-7b58694bc8-vrkdg                              0/1     CrashLoopBackOff   20
cattle-system           rancher-webhook-5bf68f7d5d-2vhvm                      0/1     ImagePullBackOff   0
cattle-turtles-system   rancher-turtles-controller-manager-7b9b565fc5-fm5xf   0/1     ImagePullBackOff   0

4. 详细根因分析 ​

4.1 Rancher Pod 崩溃导致 imperative-api 502 ​

Rancher Pod 监听端口 80/443/444/6666，运行参数：

text
Args:
  --http-listen-port=80
  --https-listen-port=443
  --add-local=true
Env:
  IMPERATIVE_API_DIRECT: true
  IMPERATIVE_API_APP_SELECTOR: rancher

Service imperative-api-extension 的 Endpoint 指向该 Pod IP 10.12.1.9:6666：

text
NAMESPACE     NAME                        ENDPOINTS
 cattle-system   imperative-api-extension    10.12.1.9:6666

由于 Rancher 容器反复崩溃，6666 端口无监听，rke2 作为代理持续返回：

text
level=error msg="Sending HTTP/1.1 502 response to 127.0.0.1:xxxxx: dial tcp 10.12.1.9:6666: connect: connection refused"
level=error msg="Sending HTTP/1.1 502 response to 127.0.0.1:xxxxx: dial tcp 10.12.1.9:6666: connect: no route to host"

这是当前日志中最高频、最显眼的错误，但它是 Rancher Pod 崩溃后的症状，不是根本原因。

4.2 rocky9-vm-06 NotReady 的两种可能 ​

  1. IP 冲突：vm-05 与 vm-06 都使用 192.168.122.231，可能导致网络层冲突、Kubelet 无法与 apiserver 稳定通信。
  2. 节点真实宕机/网络断开：vm-06 最后心跳时间为 08:04:55，Lease 在 08:05:44 后不再更新，已失联超过 2 小时。

需要登录 vm-06（192.168.122.231）进一步确认其真实状态。

4.3 私有镜像仓库缺少镜像 ​

仓库地址：192.168.122.156:30000
连通性：可达（TCP 30000 通，但 catalog 需要认证）。

但以下镜像在仓库中不存在，导致持续 ImagePullBackOff：

text
192.168.122.156:30000/rancher/fleet:v0.15.4                 → NotFound
192.168.122.156:30000/rancher/rancher-webhook:v0.10.7       → NotFound
192.168.122.156:30000/rancher/kuberlr-kubectl:v7.1.0        → NotFound
192.168.122.156:30000/rancher/turtles:v0.26.3               → NotFound

这通常是：

  • 离线镜像包未完整导入；
  • Rancher 版本与镜像 tag 不匹配；
  • 私有仓库同步/推送遗漏。

4.4 高负载来源 ​

text
PID    %CPU   COMMAND
2648   28.3   kube-apiserver
6123   16.9   etcd
5458   12.5   calico-node -felix
1011   11.1   /usr/local/bin/rke2 server
1988    5.6   kubelet

高负载由以下因素叠加：

  • Rancher Pod 崩溃重试、大量 Helm operation 反复创建/失败；
  • Pod 跨节点网络异常导致探针失败、容器反复重启；
  • ImagePullBackOff 导致 Kubelet 持续重试拉取镜像；
  • apiserver 处理大量失败 Pod/Job/Event 的状态更新。

4.5 系统层非致命告警 ​

时间来源告警内容建议
08:53:47systemd-journaldsystem.journal corrupted or uncleanly shut down属非正常关机后遗症，可清理或重建 journal
08:53:59kernelFAT-fs (vda2): Volume was not properly unmounted. Please run fsck./boot/efi 未正常卸载，建议 fsck.vfat /dev/vda2
08:54:28irqbalanceCannot change IRQ 55 affinity: Operation not permittedVM 环境下常见，通常不影响业务
08:53:38kernelSELinux: Runtime disable is not supported, use selinux=0 on kernel cmdline.当前 SELinux 策略可能为 Permissive/Enforcing，无需 runtime 关闭
08:53:40kernelDeprecated Driver: ip_tables will not be maintained in future major release未来内核升级需迁移到 nftables

5. 处理建议 ​

5.1 立即处理（恢复集群可用性） ​

  1. 确认并恢复 rocky9-vm-06

    • 尝试 SSH 登录 192.168.122.231，检查节点是否开机、网络是否正常。
    • 若 vm-06 已无法恢复，应将其从集群中移除：
      bash
      kubectl delete node rocky9-vm-06
      然后清理 etcd 成员（如需要）：
      bash
      rke2 etcd-snapshot save   # 先备份
rke2 etcd member-remove <member-id>
    • 修复 IP 冲突：确保 vm-05 与 vm-06 使用不同 IP。

  2. 终止 Pending 在 vm-06 的 helm-operation Pod

    • 这些 Pod 已阻塞 15–35 分钟，不会自动重调度（因节点仍存在于集群）。
    • 删除后它们会根据新调度策略分配到 Ready 节点：
      bash
      kubectl delete pod -n cattle-system --field-selector spec.nodeName=rocky9-vm-06

  3. 查看 Rancher Pod 崩溃原因

    • 获取崩溃日志：
      bash
      kubectl logs -n cattle-system rancher-7b58694bc8-vrkdg --previous
    • 常见原因：数据库连接失败、证书过期、内存不足、启动依赖服务不可用。根据日志进一步处理。

5.2 中期修复（补齐镜像与组件） ​

  1. 向私有仓库推送缺失镜像

    • 确认 Rancher 版本对应的正确镜像 tag：
      bash
      kubectl get settings.management.cattle.io server-version
    • 从公网拉取或从离线包导入以下镜像并推送到 192.168.122.156:30000：
      • rancher/fleet:v0.15.4
      • rancher/rancher-webhook:v0.10.7
      • rancher/kuberlr-kubectl:v7.1.0
      • rancher/turtles:v0.26.3
      • rancher/system-upgrade-controller 对应版本
    • 示例：
      bash
      docker pull rancher/fleet:v0.15.4
docker tag rancher/fleet:v0.15.4 192.168.122.156:30000/rancher/fleet:v0.15.4
docker push 192.168.122.156:30000/rancher/fleet:v0.15.4

  2. 验证镜像补齐后状态

    • 删除 ImagePullBackOff Pod 触发重新拉取：
      bash
      kubectl delete pod -n cattle-fleet-system -l app=fleet-controller
kubectl delete pod -n cattle-system -l app=rancher-webhook

5.3 系统层修复 ​

  1. 检查并修复 /boot/efi
    bash
    umount /boot/efi
fsck.vfat -a /dev/vda2
mount /boot/efi
  2. 清理损坏 journal
    bash
    systemctl stop systemd-journald
rm -f /var/log/journal/*/system.journal~*
systemctl start systemd-journald
  3. 建议重启一次节点以消除 FAT / journal 的 unclean 状态（先确保 Rancher 数据已备份）。

5.4 预防与监控 ​

  1. 节点 IP 管理：使用 DHCP 保留或静态 IP，避免虚拟机克隆导致 IP 冲突。
  2. 镜像仓库同步：在升级 Rancher 前，先完整同步所需镜像到离线仓库。
  3. 关键告警：
    • Node NotReady 超过 5 分钟；
    • Pod 状态 ImagePullBackOff / CrashLoopBackOff 持续存在；
    • Rancher Pod 重启次数异常；
    • 节点 load average 持续高于 CPU 核心数。

6. 关键命令输出（节选） ​

6.1 系统负载与资源 ​

text
up 59 min,  load average: 2.85, 3.72, 3.82
Mem: 31Gi total, 3.5Gi used, 27Gi available
Swap: 0B
Filesystem /dev/vda4 xfs 99G 9.8G 90G 10%

6.2 rke2-server 状态 ​

text
rke2-server.service - Rancher Kubernetes Engine v2 (server)
     Active: active (running) since Tue 2026-07-14 09:47:04 UTC; 56min ago
   Main PID: 1011 (rke2)
      Tasks: 371
     Memory: 1.3G (peak: 1.3G)
        CPU: 14min 6.851s

6.3 rke2 配置 ​

yaml
node-name: rocky9-vm-04
node-ip: 192.168.122.190
advertise-address: 192.168.122.190
tls-san:
  - 192.168.122.190
  - rocky9-vm-04
cluster-cidr: 10.12.0.0/16
service-cidr: 10.13.0.0/16
kube-proxy-arg:
  - "proxy-mode=ipvs"
system-default-registry: 192.168.122.156:30000
etcd-snapshot-retention: 5
etcd-snapshot-schedule-cron: "0 */6 * * *"

6.4 路由与 Flannel VTEP ​

text
default via 192.168.122.1 dev eth0
10.12.1.0/24 via 10.12.1.0 dev flannel.1 onlink
10.12.2.0/24 via 10.12.2.0 dev flannel.1 onlink

flannel.1 VTEP MAC: ae:fc:1b:52:9d:ee  local: 192.168.122.190
  ee:4e:62:d4:1a:9a dst 192.168.122.231  (vm-05)
  72:2c:53:f2:bc:f8 dst 192.168.122.231  (vm-06)

6.5 rke2-server 高频错误日志 ​

text
time="2026-07-14T10:36:35Z" level=error msg="Sending HTTP/1.1 502 response to 127.0.0.1:65408: dial tcp 10.12.1.9:6666: connect: no route to host"
time="2026-07-14T10:36:40Z" level=error msg="Sending HTTP/1.1 502 response to 127.0.0.1:19602: dial tcp 10.12.1.9:6666: connect: connection refused"
time="2026-07-14T10:35:59Z" level=error msg="Sending HTTP/1.1 502 response to 127.0.0.1:43002: dial tcp 10.12.1.4:6666: connect: connection refused"

7. 总结 ​

当前 rocky9-vm-04 节点本身并非“完全不可用”，但它是受损 RKE2 集群的一部分，主要症状是 Rancher Pod 崩溃 与 节点 vm-06 NotReady 引发的级联故障。建议按以下顺序处理：

  1. 优先恢复/清理 rocky9-vm-06；
  2. 查看 Rancher 崩溃日志并修复其启动失败原因；
  3. 补齐私有仓库缺失镜像；
  4. 清理 Pending/Error Pod，观察集群自愈；
  5. 修复系统层 FAT / journal 异常。

报告由 Kimi Code CLI 自动生成。