Kubernetes 网络一出事，先别重启：一条从 Pod 打到内核的排查路线图
说句掏心窝子的话：
Kubernetes 里，十个疑难杂症，八个最后都能追溯到“网络”。
服务超时、探针失败、Pod 起不来、节点 NotReady、偶发 502……
你去翻日志，啥也没有；
你问开发，人家说“我代码没改”；
你一看监控，CPU、内存都挺健康。
最后，锅往往落在一句很抽象的话上：
“网络好像不太稳定。”
而 Kubernetes 的网络，恰恰是最容易被“想当然”对待的东西。
今天我想干一件事：
给你一条真正能落地的、从 Pod 一路查到 Linux 内核的排查路径。
不是技巧合集，而是一种系统化思维方式。
一、先说结论：K8s 网络不是“一个东西”
很多人一排查就犯的第一个错是：
把 Kubernetes 网络，当成一个整体问题。
但在我眼里，它至少分 5 层：
- Pod 内部网络
- Pod ↔ Pod（同节点 / 跨节点）
- Service / kube-proxy
- Node 网络 & CNI
- 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
你都必须搞清楚三件事：
- Pod IP 怎么来的
- 跨节点流量怎么走
- 策略在哪一层生效
以 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 网络这玩意儿，说难是真难，
但一旦你脑子里有了分层模型，
很多“玄学问题”会突然变得特别理性。
