容器网络排障 6 层模型

来源：微信公众号「Linux性能技术栈」 | 发布时间：2026-04-29 10:20

绝大多数容器网络不通并不是网络真的坏了，而是链路上某一层状态与预期不一致。本模型将容器网络拆成 6 层，每层只问一个问题，覆盖 K8s/Docker/containerd 三类环境。

六层网络模型

30 秒速查（极速收敛）

1. K8s Pod 状态 — kubectl get pod -A -o wide → 看 STATUS / IP / NODE 字段
2. Service 与 Endpoint — kubectl get svc,ep -A → 看 CLUSTER-IP / PORT(S) / ENDPOINTS 是否为空
3. 节点网桥与路由 — ip -br addr + ip route → cni0/docker0 是否 UP，default via 可达
4. 转发开关 — sysctl net.ipv4.ip_forward → 值是否为 1
5. NAT 命中 — iptables -t nat -L -n -v → pkts/bytes 增长，MASQUERADE 是否存在

容器网络共性

无论 Docker 还是 containerd，本质都一样：容器在独立 netns 里，与宿主机通过 veth pair 连接，主机侧接网桥（docker0/cni0），再通过路由/NAT 出去。

Docker（bridge）常见断点： docker0 MTU 不一致、DOCKER-USER 链策略过严、daemon 重启后规则丢失 K8s + CNI 常见断点： Pod IP 分配失败、Service → Endpoint 映射不一致、NetworkPolicy 默认拒绝 containerd/crictl： 无 Docker CLI，用 crictl + ctr + nsenter 看真实运行态

K8s 四种常见网络故障

案例复盘：rp_filter 导致 30% 超时

升级后调用下游接口 30% 超时，排查发现超时 Pod 集中在 Node-B，该节点 rp_filter=1 而 Node-A 为 2。回包到宿主机后被 rp_filter 丢弃，未进入容器 veth。修复后恢复，后续做持久化基线治理。

排障 SOP

1. 先判影响面： 单 Pod / 单节点 / 全局
2. 再判链路层级： 容器内 → 宿主机 → 集群策略
3. 命令必须带字段观察点
4. 每次只改一个变量，改完立即验证
5. 临时修复后必须做持久化和基线固化

容易被带偏的误区

DNS 问题当网络问题 / 监听地址当连通性问题 / NetworkPolicy 当 CNI 故障 / 单节点内核参数漂移当全局故障 / MTU 不一致当偶发超时

常用命令速查

• 容器内： ip addr · ip route · ss -lntp
• 宿主机： ip -br link · bridge fdb show · iptables -L -n -v
• K8s 控制面： kubectl get pod,svc,ep -A -o wide · kubectl get netpol -A
• containerd： crictl inspect <cid> · nsenter -t <pid> -n ip route

关联页面