K8S 网络故障排查实战：从CNI配置到资源限制的深度解析

1. CNI配置错误引发的coredns启动失败实战刚接手K8S集群运维时最让我头疼的就是coredns反复崩溃的问题。记得有次凌晨两点收到告警整个集群的DNS解析全挂了查日志发现满屏都是NetworkPlugin cni failed to set up pod的报错。这种CNI插件配置错误导致的网络故障在集群重置后尤为常见。具体报错信息通常会显示cni0 already has an IP address different from 172.21.0.1/24这就像给路由器配置了错误的网关地址。根本原因是flannel网络插件残留的旧配置与新集群的IP段冲突。我常用的解决三板斧是# 清理旧网络配置 ifconfig cni0 down ip link delete cni0 rm -rf /var/lib/cni/*然后重新部署flannelkubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml这里有个坑要注意flannel的默认内存限制可能太小。有次生产环境OOM崩溃查了半天发现是flannel的memory request只有50Mi。建议修改部署文件中的resources配置containers: - name: kube-flannel resources: requests: cpu: 100m memory: 100Mi limits: memory: 200Mi2. DNS解析故障的隐蔽陷阱你以为解决了CNI问题就完事了太天真了有次集群迁移后coredns虽然显示Running状态但所有服务发现都失效了。最终发现是节点上的/etc/resolv.conf配置被清空了这就像手机没了信号基站。排查时可以用这个命令快速验证DNS解析kubectl run -it --rm --imagebusybox test-dns -- nslookup kubernetes.default正确的处理流程应该是检查节点DNS配置验证CoreDNS的ConfigMap查看kubelet的--resolv-conf参数我常用的修复命令组合echo nameserver 114.114.114.114 /etc/resolv.conf systemctl daemon-reload systemctl restart kubelet对于生产环境建议在kubelet配置中固定DNS参数--resolv-conf/etc/resolv.conf --cluster-dns10.96.0.103. cgroup驱动冲突的血泪教训凌晨三点被告警吵醒的经历让我对cgroup驱动冲突刻骨铭心。报错信息kubelet cgroup driver: systemd is different from docker cgroup driver: cgroupfs看似简单实则暗藏杀机。这就像用柴油给汽油车加油短期能跑但迟早爆缸。官方推荐使用systemd驱动因为避免双cgroup管理器资源视图不一致减少内存压力下的系统不稳定更好的与systemd集成配置方法分两步走首先是docker配置/etc/docker/daemon.json{ exec-opts: [native.cgroupdriversystemd] }然后是kubelet配置/var/lib/kubelet/config.yamlapiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cgroupDriver: systemd改完后必须按顺序重启systemctl restart docker systemctl daemon-reload systemctl restart kubelet4. 节点资源限制引发的调度故障那次大规模Pod创建失败的事故让我记忆犹新。报错信息OCI runtime state failed: fork/exec /usr/bin/runc: resource temporarily unavailable看似是运行时错误实则是系统资源耗尽。排查这类问题要像侦探破案查看节点资源使用情况kubectl describe node检查系统进程数限制cat /proc/sys/kernel/pid_max查看dmesg日志dmesg -T | grep oom常见诱因包括docker默认进程数限制默认226系统fd数量限制内存碎片化严重我的解决方案是调整docker服务配置# /etc/systemd/system/docker.service.d/limits.conf [Service] TasksMaxinfinity LimitNOFILE1048576 LimitNPROCinfinity然后执行systemctl daemon-reload systemctl restart docker对于内存问题建议在kubelet配置中添加evictionHard: memory.available: 500Mi nodefs.available: 10%5. 证书问题导致的节点注册失败在新节点加入集群时经常遇到open /var/lib/kubelet/pki/kubelet.crt: no such file or directory这类证书问题。这就像员工没有工牌就被拦在公司门口。正确的处理流程应该是在主节点重新生成证书kubeadm alpha certs renew all将生成的证书拷贝到问题节点scp /etc/kubernetes/pki/ca.crt worker-node:/etc/kubernetes/pki/在worker节点重置kubeletkubeadm reset systemctl restart kubelet对于长期运行的集群建议配置证书自动续期kubeadm init phase upload-certs --upload-certs kubeadm init phase control-plane all6. 网络策略导致的跨节点通信故障有次微服务调用频繁超时排查半天发现是NetworkPolicy配置不当。这类问题就像防火墙规则阻止了合法流量。诊断步骤检查Pod网络连通性kubectl run -it --rm --imagenicolaka/netshoot test-net -- bash查看网络策略kubectl get networkpolicy -A验证iptables规则iptables-save | grep pod-ip常用的临时解决方案是创建允许所有流量的NetworkPolicyapiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} ingress: - {} egress: - {} policyTypes: - Ingress - Egress7. 内核参数优化实战经历过大规模网络抖动后我养成了优化内核参数的习惯。就像给操作系统装上减震器这些调整能显著提升网络稳定性。必须调整的参数包括# 增加连接跟踪表大小 echo 2097152 /proc/sys/net/netfilter/nf_conntrack_max # 优化TCP堆栈 echo net.ipv4.tcp_tw_reuse1 /etc/sysctl.conf echo net.ipv4.ip_local_port_range1024 65000 /etc/sysctl.conf # 提升容器性能 echo vm.swappiness10 /etc/sysctl.conf echo vm.overcommit_memory1 /etc/sysctl.conf加载配置后别忘记sysctl -p systemctl restart kubelet这些经验都是从真实故障中总结出来的。记得有次性能问题排查三天最后发现是conntrack表满了。现在我的运维手册里这些优化项都是必做步骤。