【K8s】【网络排查】Cluster-IP访问失效？深入解析K8s节点间通信阻断问题

1. 为什么你的Cluster-IP突然不工作了最近在帮客户排查一个典型的Kubernetes网络问题Cluster-IP只能在Pod所在节点访问其他节点完全无法连通。这种问题在实际运维中很常见但排查起来往往让人头疼。今天我就带大家完整走一遍这个排查过程顺便分享几个我在实际工作中总结的网络排查技巧。先来看下这个案例的具体表现在Pod所在节点k8s-03可以通过NodePort192.168.199.203:30692访问服务在其他节点k8s-01/k8s-02使用相同NodePort访问时超时所有节点都无法通过Cluster-IP10.10.42.233访问服务这种症状通常指向节点间的网络通信问题。我遇到过的大多数类似案例最终都跟三个关键因素有关网络策略配置、iptables规则和内核参数。下面我们就从这三个维度展开分析。2. 基础环境检查别让低级错误浪费你的时间2.1 网络拓扑确认首先需要确认集群的基础网络配置是否正常。通过以下命令查看节点和Pod分布kubectl get nodes -o wide kubectl get pods -o wide在这个案例中我们发现集群有三个节点k8s-01/02/03nginx-dep1 Pod运行在k8s-03节点IP 10.122.165.234服务Cluster-IP为10.10.42.233NodePort为306922.2 防火墙状态检查虽然很多人都会先检查防火墙但我想提醒一个细节不同Linux发行版的防火墙服务名称可能不同。以下是常见发行版的检查命令# CentOS/RHEL systemctl status firewalld # Ubuntu/Debian systemctl status ufw # 通用检查 iptables -L -n | grep DROP在本案例中虽然防火墙已经关闭但iptables的FORWARD链默认策略是DROP这会导致节点间的转发包被丢弃。这是很多人在排查时容易忽略的点。3. 深入网络层iptables与内核转发3.1 iptables转发策略分析Kubernetes依赖iptables实现Service的负载均衡和路由。当FORWARD链策略为DROP时节点间的Pod通信会被阻断。检查命令iptables --list | grep Chain FORWARD输出显示Chain FORWARD (policy DROP)这就是问题的直接原因。解决方案iptables -P FORWARD ACCEPT但这样修改只是临时生效重启后会恢复。永久生效的方法是修改sysctl配置echo net.ipv4.ip_forward1 /etc/sysctl.conf sysctl -p3.2 内核参数调优除了ip_forward还有其他几个关键内核参数会影响K8s网络# 检查当前值 sysctl -a | grep -E net.ipv4.conf.all.route_localnet|net.bridge.bridge-nf-call-iptables # 建议设置 cat EOF /etc/sysctl.conf net.ipv4.conf.all.route_localnet1 net.bridge.bridge-nf-call-iptables1 net.bridge.bridge-nf-call-ip6tables1 EOF这些参数确保允许本地网络路由route_localnet让网桥流量经过iptables规则bridge-nf-call4. 进阶排查当基础配置都正常时如果上述检查都正常但问题依旧就需要更深入的排查了。下面分享几个我在实际工作中用到的进阶技巧。4.1 使用tcpdump抓包分析在源节点和目标节点同时抓包对比分析# 在请求发起节点如k8s-01 tcpdump -i any host 10.10.42.233 -w from_source.pcap # 在Pod所在节点k8s-03 tcpdump -i any host 10.122.165.234 -w at_target.pcap通过Wireshark分析这两个文件可以清楚地看到请求包是否到达目标节点回复包是否被正确返回是否存在丢包或拒绝的情况4.2 检查CNI插件状态不同的CNI插件可能有特定的排查方法。以Calico为例# 检查Calico节点状态 calicoctl node status # 查看端点状态 calicoctl get workloadendpoints常见CNI问题包括IP地址池耗尽BGP对等体连接中断网络策略误配置5. 长效预防措施5.1 集群初始化检查清单为了避免类似问题建议在新集群初始化时执行以下检查内核参数检查sysctl -a | grep -E ip_forward|route_localnet|bridge-nf-calliptables默认策略iptables -L | grep Chain FORWARDCNI插件健康状态kubectl get pods -n kube-system | grep -E flannel|calico|cilium5.2 监控与告警配置建议对以下指标设置监控节点间网络延迟TCP重传率iptables规则计数CNI插件健康状态Prometheus示例查询# 节点间网络质量 probe_duration_seconds{jobblackbox-exporter, moduleicmp} # iptables规则变化率 rate(iptables_rules_processed_total[5m])6. 真实案例复盘去年我们遇到过一个生产环境案例Cluster-IP在白天工作正常但每晚固定时间出现访问失败。经过抓包分析发现某安全扫描工具每晚全量扫描触发节点的conntrack表满新建连接被丢弃解决方案是调整内核参数echo net.netfilter.nf_conntrack_max1000000 /etc/sysctl.conf这个案例告诉我们网络问题有时会有隐藏的周期性因素需要结合监控数据综合分析。7. 实用排查工具箱最后分享几个我常用的网络排查工具和命令基础连通性测试# 测试Cluster-IP连通性 curl -v http://cluster-ip:port # 测试NodePort连通性 curl -v http://node-ip:node-port深入诊断工具# 查看kube-proxy生成的iptables规则 iptables-save | grep service-name # 检查服务端点 kubectl get endpoints service-name # 查看kube-proxy日志 kubectl logs -n kube-system kube-proxy-pod网络性能测试# 节点间带宽测试 iperf3 -s # 在一台节点 iperf3 -c server-ip # 在另一台节点记住网络问题排查要遵循从底层到上层的原则先物理连接再网络层最后才是应用层。希望这些经验能帮你少走弯路。