容器网络故障排查确实是个让人头疼的问题，特别是当SYN包莫名其妙消失在网络迷雾中时。前两天我就遇到一个典型案例：一个跑在Kubernetes集群里的微服务突然无法通信，有趣的是，同一个节点上的其他容器却一切正常。这种”选择性失联”的现象让我不得不重新审视容器网络排查的独特性。
从容器网络命名空间入手
很多人遇到容器网络问题时习惯直接ping或telnet，这其实忽略了一个关键事实：容器有自己的网络命名空间。在我最近处理的案例中，先用nsenter进入容器网络空间发现问题更高效：
# 获取容器PID
docker inspect --format '{{.State.Pid}}' 容器名
# 进入网络命名空间
nsenter -t 容器PID -n ip a这一看不要紧，发现容器的veth接口根本没分配IP！后来才知道是CNI插件抽风导致的。这种事情在宿主机上用常规命令是根本发现不了的。
那些隐藏的iptables陷阱
容器网络里最阴险的莫过于iptables规则了。记得有次遇到K8s Service莫名其妙不通，抓包显示SYN包发出去了但就是收不到响应。折腾大半天才发现是某个Pod的iptables规则被误删了——这条规则本是kube-proxy负责维护的，但因为某个神秘原因消失了。
现在我的排查清单里一定会加上这一项：
- 查看nat表的KUBE-SERVICES链是否存在
- 确认规则里Service的ClusterIP是否被正确映射到Endpoints
- 检查是否有其他自定义规则干扰（比如某些安全团队加的白名单）
云环境下的特殊陷阱
云厂商的虚拟网络总是充满惊喜。上周我遇到个荒谬的情况：AWS上两个EC2节点间的容器通信，同一可用区内延迟竟然高达200ms！最后发现是安全组配置的锅——虽然规则写的是”允许所有内部流量”，但实际只对某些端口生效，导致TCP握手要通过特殊路径绕道。
这类问题的诡异之处在于，基础网络测试（比如ping）完全正常，只有特定协议或端口的流量会出问题。我现在凡是在云环境排查容器网络，第一件事就是检查：
- 安全组规则的源/目标IP范围（注意CIDR格式的严格匹配）
- VPC路由表中是否有冲突的路由规则
- NAT网关或负载均衡器的隐式流量策略
容器网络为啥这么难搞？大概是因为它把传统的网络层次又多加了一层抽象。不过话说回来，掌握这些排查套路后，你会发现再诡异的问题都能找到突破口——至少大部分时候是这样！
评论