Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图

说句掏心窝子的话：

Kubernetes 里，十个疑难杂症，八个最后都能追溯到“网络”。

服务超时、探针失败、Pod 起不来、节点 NotReady、偶发 502……
你去翻日志，啥也没有；
你问开发，人家说“我代码没改”；
你一看监控，CPU、内存都挺健康。

最后，锅往往落在一句很抽象的话上：

“网络好像不太稳定。”

而 Kubernetes 的网络，恰恰是最容易被“想当然”对待的东西。

今天我想干一件事：
给你一条真正能落地的、从 Pod 一路查到 Linux 内核的排查路径。
不是技巧合集，而是一种系统化思维方式。

一、先说结论：K8s 网络不是“一个东西”

很多人一排查就犯的第一个错是：

把 Kubernetes 网络，当成一个整体问题。

但在我眼里，它至少分 5 层：

1. Pod 内部网络
2. Pod ↔ Pod（同节点 / 跨节点）
3. Service / kube-proxy
4. Node 网络 & CNI
5. Linux 内核网络栈

你要是没分层，排查一定是乱的。

二、第一层：Pod 内部，别急着甩锅给集群

网络不通？
先别怪 CNI，先看 Pod 自己。

你第一步该干啥？

kubectl exec -it pod-a -- sh

然后在 Pod 里做三件事：

ip addr
ip route
ping 127.0.0.1

你要确认的只有几件小事：

• Pod 有没有 IP？
• 默认路由是不是指向 eth0？
• 本地 loopback 通不通？

我见过真实事故：

Pod 用的是 distroless 镜像，
容器里连 ip 命令都没有，
最后靠猜查了一晚上。

结论很扎心：

你连 Pod 自己是不是“醒着的”都没确认，就开始怀疑整个集群。

三、第二层：Pod ↔ Pod，先区分“同节点”还是“跨节点”

这是一个90% 的人忽略、但极其关键的分叉点。

怎么快速判断？

kubectl get pod -o wide

看 NODE 列。

情况 A：同一个 Node 上 Pod 不通

优先怀疑：

• CNI bridge / veth
• iptables / eBPF 规则异常
• Pod 网卡被删了

你可以在 Node 上看：

ip link | grep veth

如果 veth 对不上，那基本已经接近真相了。

情况 B：跨 Node 才不通

那你要开始怀疑：

• Node 间路由
• Overlay 网络（VXLAN / Geneve）
• 防火墙 / 安全组

一个很实用的命令：

kubectl exec pod-a -- traceroute pod-b-ip

看包卡在哪一跳，比你盲猜一小时都有用。

四、第三层：Service 不通？别急着骂 kube-proxy

我见过太多人，一遇到 Service 问题就一句话：

“kube-proxy 又抽风了。”

但事实是：
Service 只是 iptables / IPVS 规则的“外壳”。

你该确认三件事：

1️⃣ Endpoints 对不对？

kubectl get endpoints svc-name

如果这里是空的，那网络再好也没用。

2️⃣ kube-proxy 模式是啥？

kubectl -n kube-system get cm kube-proxy -o yaml

iptables 还是 IPVS？
排查方式完全不一样。

3️⃣ Node 上规则是否存在？

iptables 模式：

iptables -t nat -L | grep svc-name

IPVS 模式：

ipvsadm -Ln

我踩过一个很典型的坑：

kube-proxy 在
Node 上 OOM 被杀了，
规则还在，但不再更新。

结论：

Service 出问题，很多时候是“数据面还在，控制面已经死了”。

五、第四层：CNI 网络，问题集中营

说句大实话：

Kubernetes 网络 80% 的复杂度，都在 CNI。

无论你用的是：

• Calico
• Flannel
• Cilium

你都必须搞清楚三件事：

1. Pod IP 怎么来的
2. 跨节点流量怎么走
3. 策略在哪一层生效

以 Calico 为例

你至少得会看：

calicoctl node status
calicoctl get ippool -o yaml

我遇到过一个很经典的事故：

IPPool CIDR 改了，
老节点没同步，
新 Pod 分配的 IP 根本路由不到。

表面现象：

• Pod 偶发不通
• 重启“有时好，有时坏”

这类问题，不系统排查，你根本抓不到。

六、第五层：Linux 内核，真·终极形态

当你走到这一步，说明：

你已经比 80% 的 K8s 使用者走得更深了。

几个你必须掌握的工具：

conntrack 表爆了

conntrack -L | wc -l

再看看最大值：

sysctl net.netfilter.nf_conntrack_max

真实线上事故：

高并发短连接
conntrack 满
新连接直接被 DROP
应用层只看到 timeout

丢包？别光看网卡

ethtool -S eth0
netstat -s

再配合：

tcpdump -i eth0

抓包不是为了装逼，是为了终止争论。

七、我自己的一个“血泪总结”

干了这么多年运维，我越来越坚定一个观点：

Kubernetes 网络排查，拼的不是命令多，而是路径清楚。

如果你愿意记住一句话，那就是：

从 Pod 开始，一层一层往下，不要跳步。

• 不要一上来重启节点
• 不要一上来升级 CNI
• 不要一上来甩锅云厂商

因为：

重启解决的问题，通常不是被你解决的，而是被你“掩盖”的。

写在最后

Kubernetes 网络这玩意儿，说难是真难，
但一旦你脑子里有了分层模型，
很多“玄学问题”会突然变得特别理性。