一、问题背景在使用 kubeadm 搭建 Kubernetes 三节点集群后集群结构如下k8s-master │ ├── k8s-node01 │ └── k8s-node02部署 Kubernetes 集群和 Flannel 网络插件后我在集群中部署 Nginx 测试应用。由于服务器无法稳定访问 Docker Hub因此首先通过 containerd 手动拉取镜像然后使用 Ansible 将镜像离线分发到各个 Kubernetes 节点。镜像分发成功后Nginx Pod 可以被正常调度但是随后发现 Node02 出现大量组件异常。主要表现为Nginx CrashLoopBackOff kube-flannel CrashLoopBackOff kube-proxy CrashLoopBackOff因此开始对 Kubernetes 集群进行逐层排查。二、问题一Docker Hub 网络超时最开始部署 Nginx 时出现ImagePullBackOff查看 Pod 事件kubectl describe pod pod-name发现failed to pull image docker.io/library/nginx:latest dial tcp registry-1.docker.io:443: i/o timeout说明服务器无法正常访问 Docker Hub。因此改为使用镜像仓库ctr -n k8s.io images pull docker.1panel.live/library/nginx:latest确认镜像ctr -n k8s.io images list | grep nginx导出镜像ctr -n k8s.io images export images/nginx.tar \ docker.1panel.live/library/nginx:latest然后通过 Ansible 将镜像批量复制到三个节点并导入 containerd。最终三个节点均成功拥有 Nginx 镜像。三、问题二Master 无法访问 Node02 的 kubelet 10250 端口部署 Pod 后Master 查看 Node02 上的容器日志出现dial tcp 10.0.4.13:10250: i/o timeout首先检查 Node02 本地 kubeletsudo systemctl status kubelet结果Active: active (running)继续检查端口sudo ss -lntp | grep 10250结果LISTEN *:10250说明kubelet 服务正常运行并且已经监听 10250 端口。但是在 Master 测试nc -vz -w 3 10.0.4.13 10250结果TIMEOUT同时ping 10.0.4.13正常。SSHnc -vz -w 3 10.0.4.13 22也正常。因此说明节点网络正常 SSH 正常 但是 10250 被网络策略阻断最终检查云服务器网络策略后发现 Node02 的相关端口权限没有放通。放通后重新测试nc -vz -w 3 10.0.4.13 10250结果ConnectedMaster 可以正常访问 Node02 的 kubelet。四、问题三Flannel RBAC 权限不足10250 端口恢复后Node02 仍然存在异常。查看 Kubernetes 系统组件kubectl get pods -A -o wide发现kube-flannel CrashLoopBackOff进一步排查发现Flannel 的 ClusterRole 对 nodes 资源缺少 get 权限。Flannel 启动后需要访问 Kubernetes API 获取节点信息。但是 RBAC 权限配置不完整Flannel ↓ 访问 Kubernetes API ↓ 获取 Node 信息 ↓ RBAC 权限不足 ↓ Flannel 无法正常工作 ↓ 不断重启修复方法是在 Flannel ClusterRole 中增加- apiGroups: - resources: - nodes verbs: - get修改权限后删除 Node02 上旧的 Flannel Podkubectl delete pod -n kube-flannel flannel-pod-name由于 Flannel 使用 DaemonSet 管理Pod 被删除后会自动重建。最终Flannel 3/3 Ready三个节点的 Pod 网络恢复正常。五、问题四Node02 kube-proxy 持续 CrashLoopBackOffFlannel 恢复后继续观察系统组件。发现kube-proxy在 Node02 上仍然不断重启。查看容器sudo crictl ps -a发现 kube-proxy 重启次数持续增加。例如kube-proxy ATTEMPT 252说明kube-proxy 并没有稳定运行。Node02 成为了唯一持续出现 kube-proxy 异常的节点。六、最终根因iptables nft 与 legacy 模式兼容性问题经过进一步排查最终确认Node02 使用的 iptables 模式为 nft 兼容模式而当前 Kubernetes/kube-proxy 网络规则环境与 nft 模式存在兼容性问题。Kubernetes 的 kube-proxy 需要通过 iptables 管理Service Pod 转发 NAT DNAT SNAT 负载均衡如果 iptables 后端模式与 Kubernetes 网络组件存在兼容性问题就可能导致iptables 规则异常 ↓ kube-proxy 初始化失败 ↓ 容器退出 ↓ kubelet 自动重启 ↓ CrashLoopBackOff因此最终决定将 Node02 的 iptables 从iptables-nft切换到iptables-legacy七、修复操作1. 切换 Node02 iptables 到 legacy 模式在 Node02 上执行sudo update-alternatives --config iptables选择iptables-legacy同时需要检查 IPv6sudo update-alternatives --config ip6tables选择ip6tables-legacy检查当前模式iptables --version确认输出类似iptables v1.8.x (legacy)2. 重启 kubelet切换 iptables 后需要重新启动 kubeletsudo systemctl restart kubelet这样可以让节点重新加载 Kubernetes 相关配置和 ConfigMap 挂载状态。检查sudo systemctl status kubelet确认Active: active (running)3. 删除旧 kube-proxy Pod查看 kube-proxykubectl get pods -n kube-system -o wide | grep kube-proxy删除 Node02 上旧的异常 Podkubectl delete pod -n kube-system kube-proxy-node02-pod由于 kube-proxy 使用 DaemonSet 管理删除旧 Pod ↓ DaemonSet 自动检测 ↓ 自动创建新的 kube-proxy Pod ↓ 加载新的 iptables 环境 ↓ kube-proxy 正常启动八、最终集群状态经过以上修复后集群所有核心组件恢复正常。组件节点状态kube-proxyk8s-master✅ Runningkube-proxyk8s-node01✅ Runningkube-proxyk8s-node02✅ Running已稳定运行无重启Flannel全部节点✅ 3/3 ReadyCoreDNSk8s-master✅ 2/2 Running控制平面组件k8s-master✅ 全部 Healthy最终 Kubernetes 集群恢复正常。九、本次故障完整时间线本次排障实际上经历了多个独立问题。部署 Nginx ↓ ImagePullBackOff ↓ Docker Hub 网络超时 ↓ 使用 ctr 离线导入镜像 ↓ Ansible 批量分发镜像 ↓ Master 无法访问 Node02 kubelet ↓ 10250 端口网络权限问题 ↓ 放通 10250 ↓ Flannel CrashLoopBackOff ↓ 发现 RBAC nodes 缺少 get 权限 ↓ 修复 Flannel ClusterRole ↓ Flannel 恢复正常 ↓ Node02 kube-proxy 持续 CrashLoopBackOff ↓ 排查 iptables 模式 ↓ 发现 nft 模式兼容性问题 ↓ 切换 iptables-legacy ↓ 重启 kubelet ↓ 删除旧 kube-proxy Pod ↓ DaemonSet 自动重建 ↓ kube-proxy 恢复正常 ↓ 集群全部组件恢复十、本次排障经验总结1. CrashLoopBackOff 不是根因CrashLoopBackOff只是 Kubernetes 告诉我们这个容器正在不断启动和退出。真正的根因需要继续查看kubectl describe pod podkubectl logs pod --previous以及sudo crictl ps -a2. Kubernetes 排障必须从底层组件逐层分析推荐排查顺序业务 Pod ↓ 容器日志 ↓ Kubelet ↓ Containerd ↓ Kube-proxy ↓ CNI 网络 ↓ Flannel ↓ iptables ↓ 节点网络 ↓ RBAC ↓ Kubernetes API不要看到 Nginx 异常就一直排查 Nginx。本次问题最终涉及镜像仓库网络 10250 端口网络权限 Flannel RBAC iptables 模式 kube-proxy3. iptables 模式会直接影响 Kubernetes 网络在 Kubernetes 环境中需要特别注意iptables-nft iptables-legacy如果节点之间 iptables 环境不同或者 Kubernetes 网络组件与当前后端模式不兼容就可能导致kube-proxy 异常 Service 网络异常 Pod 网络异常 NAT 规则异常 节点组件 CrashLoopBackOff因此部署 Kubernetes 前建议统一检查所有节点iptables --version确保集群节点网络环境一致。十一、最终总结这次 Kubernetes 集群故障并不是单一问题而是多个问题叠加导致的。最终排查出的主要问题包括问题一Docker Hub 网络超时使用ctr 导出镜像 Ansible 离线分发解决。问题二Node02 kubelet 10250 网络不通通过检查云服务器网络权限 放通 10250解决。问题三Flannel RBAC 权限不足通过为 nodes 增加 get 权限 删除旧 Flannel Pod解决。问题四Node02 kube-proxy 持续崩溃最终根因是Node02 的 iptables nft 模式与当前 Kubernetes 网络环境存在兼容性问题。最终通过切换 iptables-legacy 重启 kubelet 删除旧 kube-proxy Pod DaemonSet 自动重建成功恢复 kube-proxy。最终结论本次排障让我真正理解了 Kubernetes 的组件依赖关系Docker / Containerd ↓ Kubelet ↓ CNI / Flannel ↓ iptables ↓ kube-proxy ↓ Pod 网络 ↓ 业务应用一个业务 Pod 出现CrashLoopBackOff根因可能并不在业务容器本身。只有按照日志 → Pod 状态 → Kubelet → 网络 → CNI → iptables → RBAC这样的思路逐层排查才能真正定位 Kubernetes 集群中的复杂故障。最终k8s-master、k8s-node01、k8s-node02 三个节点全部恢复正常Flannel、kube-proxy、CoreDNS 和业务 Pod 均稳定运行。
Kubernetes 集群实战排障：Flannel RBAC 与 kube-proxy iptables 模式导致节点异常
一、问题背景在使用 kubeadm 搭建 Kubernetes 三节点集群后集群结构如下k8s-master │ ├── k8s-node01 │ └── k8s-node02部署 Kubernetes 集群和 Flannel 网络插件后我在集群中部署 Nginx 测试应用。由于服务器无法稳定访问 Docker Hub因此首先通过 containerd 手动拉取镜像然后使用 Ansible 将镜像离线分发到各个 Kubernetes 节点。镜像分发成功后Nginx Pod 可以被正常调度但是随后发现 Node02 出现大量组件异常。主要表现为Nginx CrashLoopBackOff kube-flannel CrashLoopBackOff kube-proxy CrashLoopBackOff因此开始对 Kubernetes 集群进行逐层排查。二、问题一Docker Hub 网络超时最开始部署 Nginx 时出现ImagePullBackOff查看 Pod 事件kubectl describe pod pod-name发现failed to pull image docker.io/library/nginx:latest dial tcp registry-1.docker.io:443: i/o timeout说明服务器无法正常访问 Docker Hub。因此改为使用镜像仓库ctr -n k8s.io images pull docker.1panel.live/library/nginx:latest确认镜像ctr -n k8s.io images list | grep nginx导出镜像ctr -n k8s.io images export images/nginx.tar \ docker.1panel.live/library/nginx:latest然后通过 Ansible 将镜像批量复制到三个节点并导入 containerd。最终三个节点均成功拥有 Nginx 镜像。三、问题二Master 无法访问 Node02 的 kubelet 10250 端口部署 Pod 后Master 查看 Node02 上的容器日志出现dial tcp 10.0.4.13:10250: i/o timeout首先检查 Node02 本地 kubeletsudo systemctl status kubelet结果Active: active (running)继续检查端口sudo ss -lntp | grep 10250结果LISTEN *:10250说明kubelet 服务正常运行并且已经监听 10250 端口。但是在 Master 测试nc -vz -w 3 10.0.4.13 10250结果TIMEOUT同时ping 10.0.4.13正常。SSHnc -vz -w 3 10.0.4.13 22也正常。因此说明节点网络正常 SSH 正常 但是 10250 被网络策略阻断最终检查云服务器网络策略后发现 Node02 的相关端口权限没有放通。放通后重新测试nc -vz -w 3 10.0.4.13 10250结果ConnectedMaster 可以正常访问 Node02 的 kubelet。四、问题三Flannel RBAC 权限不足10250 端口恢复后Node02 仍然存在异常。查看 Kubernetes 系统组件kubectl get pods -A -o wide发现kube-flannel CrashLoopBackOff进一步排查发现Flannel 的 ClusterRole 对 nodes 资源缺少 get 权限。Flannel 启动后需要访问 Kubernetes API 获取节点信息。但是 RBAC 权限配置不完整Flannel ↓ 访问 Kubernetes API ↓ 获取 Node 信息 ↓ RBAC 权限不足 ↓ Flannel 无法正常工作 ↓ 不断重启修复方法是在 Flannel ClusterRole 中增加- apiGroups: - resources: - nodes verbs: - get修改权限后删除 Node02 上旧的 Flannel Podkubectl delete pod -n kube-flannel flannel-pod-name由于 Flannel 使用 DaemonSet 管理Pod 被删除后会自动重建。最终Flannel 3/3 Ready三个节点的 Pod 网络恢复正常。五、问题四Node02 kube-proxy 持续 CrashLoopBackOffFlannel 恢复后继续观察系统组件。发现kube-proxy在 Node02 上仍然不断重启。查看容器sudo crictl ps -a发现 kube-proxy 重启次数持续增加。例如kube-proxy ATTEMPT 252说明kube-proxy 并没有稳定运行。Node02 成为了唯一持续出现 kube-proxy 异常的节点。六、最终根因iptables nft 与 legacy 模式兼容性问题经过进一步排查最终确认Node02 使用的 iptables 模式为 nft 兼容模式而当前 Kubernetes/kube-proxy 网络规则环境与 nft 模式存在兼容性问题。Kubernetes 的 kube-proxy 需要通过 iptables 管理Service Pod 转发 NAT DNAT SNAT 负载均衡如果 iptables 后端模式与 Kubernetes 网络组件存在兼容性问题就可能导致iptables 规则异常 ↓ kube-proxy 初始化失败 ↓ 容器退出 ↓ kubelet 自动重启 ↓ CrashLoopBackOff因此最终决定将 Node02 的 iptables 从iptables-nft切换到iptables-legacy七、修复操作1. 切换 Node02 iptables 到 legacy 模式在 Node02 上执行sudo update-alternatives --config iptables选择iptables-legacy同时需要检查 IPv6sudo update-alternatives --config ip6tables选择ip6tables-legacy检查当前模式iptables --version确认输出类似iptables v1.8.x (legacy)2. 重启 kubelet切换 iptables 后需要重新启动 kubeletsudo systemctl restart kubelet这样可以让节点重新加载 Kubernetes 相关配置和 ConfigMap 挂载状态。检查sudo systemctl status kubelet确认Active: active (running)3. 删除旧 kube-proxy Pod查看 kube-proxykubectl get pods -n kube-system -o wide | grep kube-proxy删除 Node02 上旧的异常 Podkubectl delete pod -n kube-system kube-proxy-node02-pod由于 kube-proxy 使用 DaemonSet 管理删除旧 Pod ↓ DaemonSet 自动检测 ↓ 自动创建新的 kube-proxy Pod ↓ 加载新的 iptables 环境 ↓ kube-proxy 正常启动八、最终集群状态经过以上修复后集群所有核心组件恢复正常。组件节点状态kube-proxyk8s-master✅ Runningkube-proxyk8s-node01✅ Runningkube-proxyk8s-node02✅ Running已稳定运行无重启Flannel全部节点✅ 3/3 ReadyCoreDNSk8s-master✅ 2/2 Running控制平面组件k8s-master✅ 全部 Healthy最终 Kubernetes 集群恢复正常。九、本次故障完整时间线本次排障实际上经历了多个独立问题。部署 Nginx ↓ ImagePullBackOff ↓ Docker Hub 网络超时 ↓ 使用 ctr 离线导入镜像 ↓ Ansible 批量分发镜像 ↓ Master 无法访问 Node02 kubelet ↓ 10250 端口网络权限问题 ↓ 放通 10250 ↓ Flannel CrashLoopBackOff ↓ 发现 RBAC nodes 缺少 get 权限 ↓ 修复 Flannel ClusterRole ↓ Flannel 恢复正常 ↓ Node02 kube-proxy 持续 CrashLoopBackOff ↓ 排查 iptables 模式 ↓ 发现 nft 模式兼容性问题 ↓ 切换 iptables-legacy ↓ 重启 kubelet ↓ 删除旧 kube-proxy Pod ↓ DaemonSet 自动重建 ↓ kube-proxy 恢复正常 ↓ 集群全部组件恢复十、本次排障经验总结1. CrashLoopBackOff 不是根因CrashLoopBackOff只是 Kubernetes 告诉我们这个容器正在不断启动和退出。真正的根因需要继续查看kubectl describe pod podkubectl logs pod --previous以及sudo crictl ps -a2. Kubernetes 排障必须从底层组件逐层分析推荐排查顺序业务 Pod ↓ 容器日志 ↓ Kubelet ↓ Containerd ↓ Kube-proxy ↓ CNI 网络 ↓ Flannel ↓ iptables ↓ 节点网络 ↓ RBAC ↓ Kubernetes API不要看到 Nginx 异常就一直排查 Nginx。本次问题最终涉及镜像仓库网络 10250 端口网络权限 Flannel RBAC iptables 模式 kube-proxy3. iptables 模式会直接影响 Kubernetes 网络在 Kubernetes 环境中需要特别注意iptables-nft iptables-legacy如果节点之间 iptables 环境不同或者 Kubernetes 网络组件与当前后端模式不兼容就可能导致kube-proxy 异常 Service 网络异常 Pod 网络异常 NAT 规则异常 节点组件 CrashLoopBackOff因此部署 Kubernetes 前建议统一检查所有节点iptables --version确保集群节点网络环境一致。十一、最终总结这次 Kubernetes 集群故障并不是单一问题而是多个问题叠加导致的。最终排查出的主要问题包括问题一Docker Hub 网络超时使用ctr 导出镜像 Ansible 离线分发解决。问题二Node02 kubelet 10250 网络不通通过检查云服务器网络权限 放通 10250解决。问题三Flannel RBAC 权限不足通过为 nodes 增加 get 权限 删除旧 Flannel Pod解决。问题四Node02 kube-proxy 持续崩溃最终根因是Node02 的 iptables nft 模式与当前 Kubernetes 网络环境存在兼容性问题。最终通过切换 iptables-legacy 重启 kubelet 删除旧 kube-proxy Pod DaemonSet 自动重建成功恢复 kube-proxy。最终结论本次排障让我真正理解了 Kubernetes 的组件依赖关系Docker / Containerd ↓ Kubelet ↓ CNI / Flannel ↓ iptables ↓ kube-proxy ↓ Pod 网络 ↓ 业务应用一个业务 Pod 出现CrashLoopBackOff根因可能并不在业务容器本身。只有按照日志 → Pod 状态 → Kubelet → 网络 → CNI → iptables → RBAC这样的思路逐层排查才能真正定位 Kubernetes 集群中的复杂故障。最终k8s-master、k8s-node01、k8s-node02 三个节点全部恢复正常Flannel、kube-proxy、CoreDNS 和业务 Pod 均稳定运行。
