1. 为什么你的Cluster-IP突然不工作了？
最近在帮客户排查一个典型的Kubernetes网络问题：Cluster-IP只能在Pod所在节点访问，其他节点完全无法连通。这种问题在实际运维中很常见，但排查起来往往让人头疼。今天我就带大家完整走一遍这个排查过程，顺便分享几个我在实际工作中总结的网络排查技巧。
先来看下这个案例的具体表现：
- 在Pod所在节点（k8s-03）可以通过NodePort（192.168.199.203:30692）访问服务
- 在其他节点（k8s-01/k8s-02）使用相同NodePort访问时超时
- 所有节点都无法通过Cluster-IP（10.10.42.233）访问服务
这种症状通常指向节点间的网络通信问题。我遇到过的大多数类似案例，最终都跟三个关键因素有关：网络策略配置、iptables规则和内核参数。下面我们就从这三个维度展开分析。
2. 基础环境检查：别让低级错误浪费你的时间
2.1 网络拓扑确认
首先需要确认集群的基础网络配置是否正常。通过以下命令查看节点和Pod分布：
kubectl get nodes -o wide kubectl get pods -o wide在这个案例中，我们发现：
- 集群有三个节点（k8s-01/02/03）
- nginx-dep1 Pod运行在k8s-03节点（IP 10.122.165.234）
- 服务Cluster-IP为10.10.42.233，NodePort为30692
2.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_forward=1" >> /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_localnet=1 net.bridge.bridge-nf-call-iptables=1 net.bridge.bridge-nf-call-ip6tables=1 EOF这些参数确保：
- 允许本地网络路由（route_localnet）
- 让网桥流量经过iptables规则（bridge-nf-call）
4. 进阶排查：当基础配置都正常时
如果上述检查都正常但问题依旧，就需要更深入的排查了。下面分享几个我在实际工作中用到的进阶技巧。
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-call'iptables默认策略：
iptables -L | grep 'Chain FORWARD'CNI插件健康状态：
kubectl get pods -n kube-system | grep -E 'flannel|calico|cilium'
5.2 监控与告警配置
建议对以下指标设置监控：
- 节点间网络延迟
- TCP重传率
- iptables规则计数
- CNI插件健康状态
Prometheus示例查询：
# 节点间网络质量 probe_duration_seconds{job="blackbox-exporter", module="icmp"} # iptables规则变化率 rate(iptables_rules_processed_total[5m])6. 真实案例复盘
去年我们遇到过一个生产环境案例：Cluster-IP在白天工作正常，但每晚固定时间出现访问失败。经过抓包分析发现：
- 某安全扫描工具每晚全量扫描
- 触发节点的conntrack表满
- 新建连接被丢弃
解决方案是调整内核参数：
echo "net.netfilter.nf_conntrack_max=1000000" >> /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> # 在另一台节点
记住，网络问题排查要遵循从底层到上层的原则：先物理连接，再网络层，最后才是应用层。希望这些经验能帮你少走弯路。
