Kubernetes在CentOS上的故障排查技巧

Kubernetes 在 CentOS 上的故障排查技巧

一 快速定位路径

• 查看节点与系统资源
  • 执行：kubectl get nodes、kubectl describe node 、kubectl get pods -A -o wide、kubectl top nodes/pods -A，先确认是否有节点 NotReady、Pod CrashLoopBackOff/ImagePullBackOff、资源紧张等共性问题。
• 查看事件与日志
  • 执行：kubectl get events -A --sort-by=.metadata.creationTimestamp，聚焦 Warning/Error；对异常 Pod 用 kubectl describe pod -n 看 Events；容器日志用 kubectl logs -c -n ；系统组件日志用 journalctl -u kubelet -f、必要时 journalctl -xe。
• 检查网络连通与 CNI
  • 验证节点间 ping/traceroute；检查 CNI（如 Calico/Flannel）Pod 状态与日志；按 CNI 要求测试端口（如 Flannel UDP 8472），跨节点 nc -u 测试；必要时查看 iptables/firewalld 规则与云上安全组。
• 检查存储与 DNS
  • 存储：kubectl get pv,pvc,storageclass 与 kubectl describe pvc ；DNS：kubectl get pods -n kube-system -l k8s-app=kube-dns、kubectl logs -n kube-system -c kubedns、kubectl get svc kube-dns -n kube-system 与 kubectl get endpoints kube-dns -n kube-system。

二 常见故障与修复要点

• 节点 NotReady
  • 常见根因：kubelet 未就绪、CNI 未就绪、系统资源不足、内核/驱动异常。
  • 处置：查看 kubelet 与容器运行时状态与日志；确认 CNI DaemonSet Running 且节点污点无异常；用 kubectl describe node 看 Conditions（如 MemoryPressure/DiskPressure/PIDPressure/Ready）；必要时检查 dmesg、/var/log/messages 的系统级异常。
• Pod CrashLoopBackOff/ImagePullBackOff
  • 处置：用 kubectl logs 与 kubectl describe pod 定位启动命令、就绪探针、镜像拉取密钥/仓库；若镜像拉取慢或失败，考虑镜像仓库可达性与镜像加速。
• 跨节点 Pod 不通
  • 处置：确认 CNI 插件与 Pod CIDR 规划正确；按 CNI 要求放通端口（如 Flannel UDP 8472）；检查 iptables/firewalld 与云安全组；做跨节点 UDP 8472 连通性测试；排查 NetworkPolicy 是否拦截。
• Service 不通或 DNS 解析失败
  • 处置：确认 Service 的 ClusterIP/Port/Selector 与后端 Endpoints 一致；检查 kube-proxy 是否 Running；排查 iptables/IPVS 规则；对 CoreDNS 检查 Pod/Service/Endpoints 与日志，必要时用临时调试容器 kubectl-debug 进入网络命名空间抓包/排障。
• 节点资源耗尽
  • 处置：用 kubectl top 与 free/df/iostat 定位 CPU/内存/磁盘/IO 瓶颈；清理无用镜像/日志，调整 requests/limits，必要时驱逐或扩容节点。

三 CentOS 系统层面的关键检查

• 防火墙与安全组
  • 建议仅对集群网段放行，示例（按 CNI/组件需求调整）：firewall-cmd --permanent --zone=trusted --add-port=6443/tcp（API）、10250/tcp（kubelet）、10251/tcp（scheduler）、10252/tcp（controller-manager）、以及 8472/udp（Flannel VXLAN）；变更后 firewall-cmd --reload。
• iptables 与 nftables 一致性
  • CentOS 8+ 默认使用 nftables，若与 kube-proxy 的 iptables 规则不一致，可能导致 Service/Endpoints 异常。可通过将 iptables 切换到 legacy 模式 解决：执行 update-alternatives --set iptables /usr/sbin/iptables-legacy，并确保 ip6tables 一致；同时优先升级 Kubernetes ≥ 1.16.10 或 内核 ≥ 5.0 以避免历史兼容性问题。
• 内核与系统参数
  • 确认 bridge-nf-call-iptables 与 ip_forward 已启用：
    • echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
    • echo 1 > /proc/sys/net/ipv4/ip_forward
  • 按需加载 ip_vs/ip_vs_rr/ip_vs_wrr 等模块（IPVS 模式）。
• 资源与系统日志
  • 用 free -g、iostat -x 1、dmesg -T、tail -f /var/log/messages 排查内存、磁盘 IO、内核与系统级告警。

四 高效工具与命令清单

五 安全变更与回退建议

• 变更前：对 firewalld/iptables/nftables、kube-proxy 模式、内核参数 等变更做好快照/备份与变更记录，先在测试环境验证。
• 回退路径：
  • iptables 模式回退：update-alternatives --set iptables /usr/sbin/iptables-nft；
  • 集群级回退：执行 kubeadm reset 后按清单重建（注意数据持久化与云盘快照）。
• 风险提示：生产环境变更请避开业务高峰，按 灰度/滚动 方式进行，并准备回滚预案。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！