容器网络故障如何排查?

话题来源: 如何快速排查TCP握手超时处理流程

容器网络故障排查确实是个让人头疼的问题,特别是当SYN包莫名其妙消失在网络迷雾中时。前两天我就遇到一个典型案例:一个跑在Kubernetes集群里的微服务突然无法通信,有趣的是,同一个节点上的其他容器却一切正常。这种”选择性失联”的现象让我不得不重新审视容器网络排查的独特性。

从容器网络命名空间入手

很多人遇到容器网络问题时习惯直接pingtelnet,这其实忽略了一个关键事实:容器有自己的网络命名空间。在我最近处理的案例中,先用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网关或负载均衡器的隐式流量策略

容器网络为啥这么难搞?大概是因为它把传统的网络层次又多加了一层抽象。不过话说回来,掌握这些排查套路后,你会发现再诡异的问题都能找到突破口——至少大部分时候是这样!

评论