网络排障清单（连通性 / 丢包 / 延迟）

摘要：本文提供一套可操作的分层排障清单，覆盖 K8s 网络最常见的三大类问题——连通性、丢包、延迟，涉及 CNI、conntrack、MTU、DNS 与抓包。覆盖版本：Kubernetes v1.28+。

适用版本与前提

• Kubernetes：v1.28+。
• 工具：kubectl、crictl/ctr、节点 shell、tcpdump、ip、conntrack、iperf3/ping -M。
• 前提：理解网络模型与 Service（见 network.md、service.md）。

排障总原则：分层定位

网络问题不要“一上来就抓包”。按 OSI 从下往上、从内往外的顺序定位，能大幅缩短 MTTR：

一、连通性问题

1. Pod 起不来 / 一直 ContainerCreating

kubectl describe pod <pod>          # 看 Events：CNI 报错？镜像拉取？
kubectl get pods -n kube-system     # CNI DaemonSet 是否 Ready

最常见根因

CNI 未就绪：节点没有可用 CNI，Pod 永远 ContainerCreating。先确认 calico/cilium/flannel 等 DaemonSet 正常运行。

2. Service 访问不通（但 Pod 直连通）

kubectl get svc <svc>
kubectl get endpointslices -l k8s-app=<svc>   # 后端是否为空
kubectl describe svc <svc>                    # Events / Endpoints
# 确认 kube-proxy 模式与健康
kubectl -n kube-system get pods -l k8s-app=kube-proxy

注意：ClusterIP 不能 ping（虚拟 IP，不响应 ICMP），请用 TCP 验证（curl/nc）。

3. DNS 不通

按 coredns.md 清单：确认 CoreDNS Pod 健康、Pod 内 resolv.conf 指向 kube-dns ClusterIP、确认 NetworkPolicy 未挡 53 端口。

二、丢包问题

MTU 不一致（最隐蔽的丢包）

Overlay 网络（VXLAN / IP-in-IP）会封装，通常节点 MTU 1500 时 Pod 网络 MTU 应为 1450（VXLAN 开销 50 字节）。若两端 MTU 不一致，大包会被丢弃且只重传小包——表现为“能握手、传大数据就卡死/重传”。

# 节点物理网卡
ip link show eth0 | grep mtu
# CNI 隧道接口（如 Cilium VXLAN / Calico tunl0 / Flannel.1）
ip link show cilium_vxlan | grep mtu
ip link show tunl0 | grep mtu
ip link show flannel.1 | grep mtu
# Pod 内网卡
kubectl exec <pod> -- ip link show eth0 | grep mtu
# 用不分片大包探测（DF 位）
ping -M do -s 1400 -c 3 <target-ip>    # 逐步增大 size 找到断点

经验判断

Calico IP-in-IP 模式下 tunl0 的 MTU 应与链路一致（常见 1440/1450）。云主机网卡 1500 而隧道 1440 时，大数据包无法送达隧道，应用层表现为持续重传直到超时。对齐链路两端 MTU 即可解决 [未实测，需验证]。

conntrack 表满

连接数极高时 conntrack 表满会导致新建连接被丢：

# 查看 conntrack 使用
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
# 调大（临时）
sysctl -w net.netfilter.nf_conntrack_max=1048576

节点/安全组/防火墙

• 云安全组、节点 iptables/nftables 规则可能挡掉 NodePort 或 Pod 网段。
• kube-proxy 的 Cluster 策略做 SNAT，相关 conntrack 条目需存在。

三、延迟问题

间歇性 5 秒 DNS 延迟

见 coredns.md：根因常为 ndots:5 导致外部查询放大 + conntrack/UDP 丢包重试。缓解：降 ndots、加结尾点、上 NodeLocal DNSCache。

跨节点延迟高

• Overlay 封装有 CPU 开销；高性能场景用 host-gw/BGP（Calico）或 eBPF（Cilium）减少封装 [厂商特定]。
• 用 iperf3 测吞吐与 RTT：

# 一端
kubectl run iperf-srv --rm -it --image=networkstatic/iperf3 -- -s
# 另一端
kubectl run iperf-cli --rm -it --image=networkstatic/iperf3 -- -c <srv-ip> -t 10

四、抓包定位（终极手段）

# 节点上抓某 Pod 流量（找到 Pod 所在节点与 veth）
kubectl get pod <pod> -o wide          # 看 NODE 与 IP
# 在节点上找到对应 veth（cni0 / 容器 veth）
ip link | grep -i veth
tcpdump -n -i <iface> host <pod-ip> -vv
# 抓 DNS
tcpdump -n -i any port 53 -vv
# 抓特定端口
tcpdump -n -i any port 30100 -vv

生产危险

抓包会产生大量数据并消耗节点资源，生产节点上务必加过滤条件并限制时长；避免 tcpdump -i any 长时间全量抓包。抓完及时停止。

排障速查表

症状	优先检查	工具
Pod 一直 ContainerCreating	CNI DaemonSet 状态	kubectl describe pod、kubectl get pods -n kube-system
Service 不通	EndpointSlice / kube-proxy	kubectl get endpointslices、describe svc
DNS 慢/失败	CoreDNS、ndots、Policy	dig、kubectl logs coredns
大数据传输卡死	MTU 不一致	ping -M do -s、ip link show
新建连接偶发失败	conntrack 满	conntrack -C、nf_conntrack_max
跨节点慢	Overlay 开销	iperf3
不明丢包	抓包定位	tcpdump

生产实践

• 预发环境演练：MTU、conntrack、DNS 问题应在预发复现并固化检查脚本。
• 可观测先行：CoreDNS :9153、kube-proxy/CNI 指标、节点 conntrack 用量都纳入监控，问题发生时直接看图表而非临时抓包。
• 变更有回滚：调整 MTU、conntrack、CNI 模式都属于节点级变更，需灰度并准备回滚。

回滚与清理

# MTU / sysctl 临时调整后，重启节点或还原配置即回滚
# 临时 sysctl 还原示例
sysctl -w net.netfilter.nf_conntrack_max=<原值>
# 抓包进程务必停止
pkill -f 'tcpdump'

安全与合规

• 排障使用的临时调试 Pod（netshoot 等）含大量网络工具，生产用完即删，避免成为攻击跳板。
• 抓包内容可能含敏感载荷，注意合规与留存范围。

常见坑

• 用 ping 验证 ClusterIP：不通是正常，别误判。
• 忽略 MTU：小包通、大包挂，最易被误判为“应用问题”。
• 只看单点：跨节点问题要在两端同时抓包对比。
• 忘记 conntrack 容量：连接密集服务（如网关）容易被表满拖垮。

参考资料

• Kubernetes 官方文档 - Cluster Networking，访问日期：2026-10-08。
• k8s.guide - DNS and Service Discovery（ndots / 5s 延迟），访问日期：2026-10-08。
• Kubernetes Recipes - Debug DNS Resolution Failures，访问日期：2026-10-08。
• 搜狐 - Kubernetes 网络排错中文指南（MTU 案例），访问日期：2026-10-08（社区经验，交叉验证后引用）。