容器网络核心机制与算法：从命名空间到VXLAN与负载均衡

容器网络这个话题，放到技术群里永远是热门。凡是上手过容器的人，十有八九都在这里栽过跟头：容器明明跑起来了，互相之间却 ping 不通；服务都部署好了，负载均衡就是不生效；换一套网络插件，整个集群的流量直接卡死。这些问题的根源，往往不在容器本身，而在容器背后那套网络算法和模型。

这篇文章要聊的，是容器网络的核心机制与算法：从网络命名空间隔离、Bridge 桥接与端口映射，到 IPAM 地址分配、VXLAN 封装转发，再到服务发现与负载均衡。也正好对应“网络的主要算法”这个系列里最具当代意义的容器网络部分。适合两类人看：一是刚接触容器、准备系统打基础的后端开发者，二是已经在跑容器服务、遇到网络问题只会“重启大法”的运维新手。把底层逻辑想清楚之后，你会发现排障不是靠试，而是靠推理。

1. 容器网络到底在解决什么问题

1.1 从“单机单服务”到“单机几十个容器”的跃迁

传统服务器部署一个服务，流程非常简单：装好操作系统，绑定一个 IP，开放 80、3306、6379 这些端口，防火墙按端口放行就行了。一台物理机通常只跑一个或少数几个应用，端口冲突很少发生，网络配置基本是一次性的。

容器化之后，这个前提被彻底打破了。一台物理机上能同时跑几十个甚至上百个容器，每个容器在逻辑上都是一个独立的小系统。如果所有容器都直接共用宿主机的 IP 和端口，那 80 端口就只能给一个容器用，其他容器都得排队，这显然不可接受。

所以容器网络要回答一个根本问题：如何让软件自动创建的每一个容器，在几秒钟内拿到正确的网络身份，包括独立 IP、路由规则、DNS 配置，既能与同一台机器上的邻居通信，也能跨机器通信，还能受控地访问外网。这里说的每一个细节，背后都是算法在支撑。

1.2 网络命名空间：容器网络的独立王国

想理解容器网络，绕不开 Linux 的网络命名空间（Network Namespace）。这是一个很朴素但极其重要的机制：内核允许你创建出多个互相隔离的网络栈，每个栈都拥有自己独立的网卡、回环接口、路由表和 iptables 规则。

容器就是靠这个机制实现网络隔离的。你可以把网络命名空间想象成一个个一模一样的“独立房间”，房间之间原本没有门，互不打扰。Docker 这类容器引擎的职责，就是在这些房间之间修路、架桥。你执行docker run的时候，引擎会做这么几件事：创建一个全新的网络命名空间，给这个命名空间分配一个虚拟网卡，再创建一对 veth 虚拟网线，一头插进容器的命名空间变成 eth0，另一头插进宿主机上的虚拟交换机（也就是 Bridge）。

容器看到的网络拓扑，跟宿主机是完全不同的两张地图。因为每个容器都有自己的 IP，所以两个容器同时监听 8080 端口也互不冲突。这就是隔离带来的好处。但坏处也很明显：跨容器通信、跨主机通信的复杂度全上来了，必须由额外的网络模型和算法来弥补。

1.3 容器网络里到底涉及哪些经典算法

把容器网络拆开看，里面的算法其实都是计算机网络的“熟人”，只不过换了个场景重新登场。第一类是二层算法，比如 MAC 地址学习、ARP 请求与应答，负责解决同一链路里“谁是谁”的问题。第二类是三层算法，比如最长前缀匹配的路由查询、IP 地址分配与回收，负责解决“数据包往哪走”的问题。第三类是四层的连接与转发算法，比如 NAT 端口映射、conntrack 连接跟踪、IPVS 调度器里的轮询和哈希哈希，负责解决“服务怎么被人稳定访问”的问题。

后面几个部分，我会按这个脉络逐个展开。你会发现，容器网络并不是一套全新发明的技术，而是把传统网络算法在虚拟化环境里重新组合了一遍。理解了这个角度，很多现象就能解释通了。

2. 四大基础网络模型的算法基因

2.1 Bridge 模式：MAC 自学习与 DNAT 映射

Docker 默认的网络模式是 Bridge 模式。docker run出来的容器，默认会连到宿主机上的docker0这个虚拟网桥上，拿一个类似 172.17.0.x 的私有 IP。这个网桥在 Linux 内核里实现的就是一个标准二层交换机，它遵循的算法跟物理交换机一模一样：MAC 地址自学习。

我给你还原一下这个过程。假设容器 A（172.17.0.2）想和容器 B（172.17.0.3）通信。A 首先检查自己的 ARP 缓存，如果不知道 B 的 MAC，就发一个广播 ARP 请求。这个请求会经过 veth 网线到达 docker0 网桥。网桥一开始并不知道 B 的 MAC 在哪个端口，于是把广播帧向所有端口转发。B 收到之后应答自己的 MAC，网桥就把“B 的 MAC 对应哪个端口”记进自己的 MAC 地址表里。后续 A 和 B 之间的数据帧，网桥查一下 MAC 表就能精确转发，不再广播。这个叫“MAC 地址自学习”的算法，是二层交换的核心，也是同一台宿主机上容器互通的基础。

容器要访问外网时，就没这么简单了。172.17.0.2 是一个私有地址，外面的网络根本不认它。Docker 的处理方式是：容器发出的数据包先在宿主机上做一次源地址转换（SNAT / MASQUERADE），把源 IP 换成宿主机的公网或物理网卡 IP，回来的时候再反向转换回去。这里起作用的是 iptables 规则。

反过来，外部访问容器需要使用端口映射，也就是你常见的-p 8080:80。这个参数背后的算法是一条 DNAT 规则：当外部数据包到达宿主机的 8080 端口时，内核会查找 iptables 的 NAT 表，命中之后把目的 IP 和端口改写成 172.17.0.2:80，再转发进容器网络。为了让应答包能原路返回，内核还有一个连接跟踪机制（conntrack），它维护一张“连接状态表”，把这条改写前后的五元组信息记下来。这就是为什么你不需要为每一个返回包再写一条规则，连接跟踪算法帮你做了状态对称性处理。

2.2 Host 模式与 None 模式：两个极端

Host 模式是另一个极端：容器不创建新的网络命名空间，直接共享宿主机的网络栈。容器里的 eth0 就是宿主机的物理网卡，容器监听 8080 端口，就相当于宿主机监听 8080 端口。

这种模式的好处很明显，没有 veth 转发，没有 NAT，没有额外的封装，性能几乎和裸机进程一样高。很多对网络延迟极其敏感的场景，比如高性能缓存、实时数据处理，会倾向于用 Host 模式。但代价也很大：端口隔离彻底失效，一个容器占用了 8080，另一个容器就不能再用。生产环境里除非你很清楚自己在做什么，否则不建议大规模使用 Host 模式，否则端口冲突会让你怀疑人生。

None 模式则最干净：容器里只有一个回环接口，没有任何外部网卡。这种模式适合纯粹做计算的临时容器，不需要网络访问；也适合那些后续需要自己手工接入复杂网络环境的场景，先用 None 模式把容器创建出来，再由外部工具把网卡和路由配置进去。它把“网络配置”这件事完全交给了你的脚本或编排系统，算是一种把控制权最大化的模式。

2.3 Overlay 网络：VXLAN 封装与 VTEP 学习算法

单机上的 Bridge 模式解决不了跨主机通信的问题。容器 A 在宿主机 X 上，容器 B 在宿主机 Y 上，两个宿主机之间隔着一张物理网络，A 的 172.17.0.2 这个地址在 Y 上完全没有意义。

Overlay 网络（叠加网络）的思路是：在已有的物理网络之上，再虚拟出一张覆盖所有容器的逻辑网络。最主流的实现是 VXLAN。它的核心算法看起来复杂，拆开其实就三步。

第一步，容器 A 发一个二层帧给容器 B，这个帧到达宿主机 X 上的 VTEP（VXLAN 隧道端点）。第二步，VTEP 查自己的转发表，发现目的 MAC 在宿主机 Y 后面，于是把原始二层帧整个装进一个 UDP 包里，外层目的地址写成宿主机 Y 的物理 IP，通过物理网络发出去。第三步，宿主机 Y 的 VTEP 收到 UDP 包，解封装还原出原始二层帧，再投递给容器 B。

这里有两个关键算法。一个是 VTEP 的地址学习：它跟普通交换机一样需要学习“哪个 MAC 藏在哪个远端 VTEP 后面”，只不过学习结果不是一层 MAC 表，而是一张“MAC 到远端主机 IP”的映射表。另一个是 VNI 隔离：VXLAN 报文里有一个 24 位的 VXLAN Network Identifier，相当于二层网络里的 VLAN，但数量从 4000 多直接跳到 1600 万，不同 VNI 之间的流量天然隔离。

你必须记住的代价是封装开销。VXLAN 会额外增加大约 50 字节的头部，如果物理网络 MTU 是 1500，那 overlay 网络里的内层报文就必须把 MTU 降到 1450 或者更小。很多“能 ping 通但传大文件失败”的诡异问题，罪魁祸首就是 MTU，后面排查部分我会细说。

3. IPAM：地址分配里的算法设计

3.1 单机地址池的分配与回收

每个容器都要有唯一的 IP，谁来给？谁来保证不重复？这就是 IPAM（IP Address Management，地址管理）要做的事。

单机场景下，Docker 守护进程会在创建容器时从配置好的子网里挑一个空闲 IP。这个分配过程用到的算法，本质上就是一个位图管理：把 172.17.0.0/24 里的 254 个可用地址当成一张位图，每个 bit 表示对应地址是否被占用。容器创建时，按顺序扫描位图找到第一个空闲地址，把 bit 置 1；容器销毁后，把 bit 清 0。这个算法简单、快速、确定性高，非常适合单点的场景。

但如果你以为生产环境就是这么做 IPAM 的，那就太小看规模问题了。试想一下：一个集群有几千个节点，每个节点同时在创建和销毁容器，如果所有分配请求都集中到一个中心服务，那这个服务就是性能瓶颈，而且一旦它抖动，整个集群新增容器的速度都会被拖垮。

3.2 多主机场景下的子网划分与协调

为了解决中心化分配的瓶颈，主流方案选择了“按节点划分网段”的策略。以 Flannel 为例，它给整个集群设置一个大网段，比如 10.244.0.0/16，然后给每个节点划分一个 /24 的子网。节点 A 拿到 10.244.1.0/24，节点 B 拿到 10.244.2.0/24，以此类推。

划分好之后，节点内部的容器从哪个网段取 IP，就完全由本节点的本地 IPAM 决定，不需要再向中心服务逐个申请。这样做的算法优点非常明显：把全局的地址申请压力分散到了每个节点，只有节点上线时才会做一次子网分配，平时的容器创建销毁都是本地操作，延迟极低，也不存在中心瓶颈。

代价是地址利用率下降。比如一个节点实际只跑了 3 个容器，但它独占了一个 /24 网段，254 个地址里有 251 个是浪费的。好在 IPv4 私有地址本来就规划了比较大的范围，对于绝大多数集群规模来说，这点浪费是完全可以接受的。这里面的权衡逻辑值得反复体会：分布式系统里，用空间换时间、用冗余换确定性，是极其常见的手法。

3.3 地址冲突与分布式一致性

多节点各拿各的网段，看起来完美，但它依赖一个前提：节点之间分配子网时不能发生冲突。两个节点如果同时拿到了 10.244.1.0/24，那这个网段里的所有容器 IP 都会撞车，网络立刻变得不可用。

为了防止这种情况，节点领取子网这个动作必须被严格串行化。Kubernetes 和 Flannel 的做法是把分配记录写入 etcd，利用 etcd 的分布式一致性能力和租约机制，保证一次只有一个节点能成功领取某个子网。这背后的算法是分布式锁和租约（lease）：节点领取成功后获得一个租约，租约到期前节点持续持有这个网段；如果节点挂了，租约超时后这个网段才会被回收重新分配。

这里有一个在生产环境里很常见的坑：如果你在排障时发现两个节点上报了完全相同的 Pod 网段，千万不要只盯着网络层看，先查 etcd 一致性和节点租约状态。网络分层之间的问题常常是上层算法失序导致的，这个方向错了，排查多久都是白费。

4. 服务发现与负载均衡：算法的主战场

4.1 DNS 服务发现与轮询算法

容器 IP 是短时间内频繁变化的资源。一个服务从 3 个副本扩容到 10 个副本，旧容器销毁新容器创建，地址一直在变。如果客户端直接写死某一个 Pod IP，副本一换就失联。于是就有了服务发现：通过一个稳定名字找到一组随时变化的后端地址。

最基础的实现是 DNS。在 Kubernetes 里，Pod 可以把服务的全限定域名（例如 svc-name.namespace.svc.cluster.local）交给 CoreDNS 解析，得到的答案是服务的稳定虚拟 IP。如果服务是 Headless Service，DNS 会直接返回所有后端 Pod 的真实 IP 列表。客户端拿到多个 IP 之后，轮流使用，这就是最简单的轮询算法（Round-Robin）。

轮询算法实现成本极低，它的问题在于状态感知能力弱。DNS 客户端会缓存解析结果，如果某个 Pod 已经挂了，但缓存里还有它的 IP，请求就可能打到不存在的地址上。所以生产环境一般不会拿普通 DNS 轮询做唯一负载均衡手段，而是把它和 TTL 策略、健康检查机制结合起来使用。

4.2 iptables 与 IPVS 的负载均衡算法

当请求到达集群的 Service 层时，真正干活的是 kube-proxy。它有两种主流转发模式，对应两套完全不同的算法。

iptables 模式的工作原理是：kube-proxy 为每个 Service 生成一组 iptables 规则，规则用 statistic 模块做概率匹配，让每个新连接按近似等概率被 DNAT 到某一个后端 Pod。这里用的是随机选择算法，配合 conntrack 做到连接级别的粘滞：同一个连接一旦被选中某个后端，后续包都走同一个后端，不会被中途换掉。iptables 模式的优点是简单、兼容性好；缺点是大规则集下查找是线性的，后端数量一多，规则数量膨胀，性能和稳定性都会变差。

IPVS 模式则内置了完整的内核级调度算法。通过kube-proxy --mode=ipvs启动后，你可以在节点上用ipvsadm -L -n查看它为每个 Service 建立的虚拟服务以及调度策略。可用的算法很多，常用的几个是：

• rr：轮询，请求依次分发到每个后端，适合后端性能均等的场景。
• wrr：加权轮询，给高性能后端配更大的权重，让它承担更多流量。
• lc：最少连接，优先把请求分给当前活跃连接数最少的后端，适合长连接场景。
• wlc：加权最少连接，在最少连接基础上叠加权重因子，也是 LVS 默认算法。
• sh：源地址哈希，同一来源的请求永远打到同一个后端，适合需要会话保持的业务。

下面这个对比表能帮你更直观地做选择：

选算法从来不是越快越好。很多团队把默认调度从 rr 改成 lc 之后发现响应时间反而上升了，原因就在于业务是短连接，每条请求的生命周期极短，连接数算法还没来得及发挥统计优势。理解业务连接特征，再选调度算法，才是正确顺序。

4.3 一致性哈希：从缓存到容器网关

在网关、服务网格或者分布式缓存组件的实现里，经常会看到一个比轮询和连接数都更聪明的算法：一致性哈希。

普通哈希取模有一个大缺陷。假设后端从 4 个扩容到 5 个，按hash(key) % N计算，绝大多数请求的映射结果都会改变，意味着缓存全部失效，后端之间要发生大量数据迁移。这对容器环境尤其致命，因为扩缩容是常态。

一致性哈希的思路是把所有哈希值组织成一个环，节点按自己的哈希值分布在环上，请求也按哈希值落位，然后顺时针找到最近的节点。新增一个节点时，只有环上它前后那一小段范围内的请求会受影响，其他请求完全不动。再配合虚拟节点机制，让哈希环更均匀，就能比较好地解决数据倾斜问题。

在容器网络里，这个算法的应用很多：Ingress 网关做基于 URI 的会话保持、服务网格里的定向路由、Redis 集群的 key 分布，底层都在用一致性哈希。理解它的核心思想“影响最小化”，你就知道为什么容器世界这么偏爱它了——因为容器世界里，节点生生死死本来就是常态。

5. CNI 与主流容器网络方案对比

5.1 CNI 接口与插件调用流程

Docker 有自己的一套网络实现，但容器编排生态真正广泛使用的，是 CNI（Container Network Interface）。CNI 是一套标准接口，定义了一种简单的命令协议：容器引擎需要给容器配网时，就调用 CNI 插件的ADD命令；容器销毁时调用DEL命令；查询状态用CHECK。

整个调用链是这样一个流程：Kubernetes 的 kubelet 想启动一个 Pod，它通过 CRI 接口通知 containerd 这类容器运行时，运行时发现这个 Pod 需要加入网络，就按照配置调用 CNI 插件。插件拿到 Pod 的网络命名空间和网络配置后，会创建 veth、配置路由、分配 IP，最终返回一份标准的网络结果。这份结果里包含了容器的接口名称、IP 地址、网关等关键信息。这套标准化协议的意义在于：网络方案和容器运行时解耦了，你可以把 Flannel 换成 Calico，容器运行时完全不需要重新适配。

5.2 Flannel、Calico、Cilium 的算法视角

主流方案非常多，但从算法和数据平面的角度，可以分成三大类。

Flannel 走的是 VXLAN overlay 路线。它简单易用，默认情况下每个节点分一个子网，节点之间用 VXLAN 隧道通信。它的转发路径是：Pod → veth → cni0 网桥 → flannel.1 → VXLAN 封装 → 物理网卡 → 目标节点。多了封装解封装这一层，吞吐量和延迟会有一点折损，但部署和运维门槛最低，非常适合中小集群。

Calico 走的是纯三层路由路线。它不封装流量，每个 Pod 的网段被当作一条路由，通过 BGP 协议在集群内外传播。数据包路径是：Pod → veth → 宿主机路由表 → 物理网卡 → 目标节点。没有额外封装，转发路径短，性能好；代价是需要管理和维护 BGP，网络层排查复杂度更高。它更适合对性能有要求，且团队有网络基础的大规模集群。

Cilium 是新一代的 eBPF 方案。它的数据包路径不再依赖 iptables 和传统路由表，而是让数据包在挂载于内核的 BPF 程序里完成转发、负载均衡和策略控制。算法层面，它用 BPF map 做哈希查找，把 Service 的负载均衡从规则遍历变成了 O(1) 的查表，性能和扩展性都领先。代价是新东西的学习曲线陡峭，对内核版本要求也比较高。

三者对比可以浓缩成这张表：

5.3 路由查询：最长前缀匹配算法

无论用哪种方案，最终在宿主机的路由表里都会出现成百上千条路由规则。数据包到了宿主机之后，内核怎么从这么多条路由里快速选出正确的出口？答案是 LPM，最长前缀匹配算法。

这个算法的精髓一句话就能说透：多条路由都能匹配时，前缀最长的那条获胜。比如有三个网段的路由，10.244.0.0/16 指向一个方向，10.244.1.0/24 指向另一个方向，10.244.1.128/25 再指向第三个方向。现在有一个目的地为 10.244.1.200 的包，它同时匹配这三个前缀，但内核只会选择 /25 那条。

这个规则对容器网络有一个很实际的影响：你必须谨慎设计网段和路由发布范围。大规模集群里如果无意中写了一条过宽的汇总路由，所有本来该走细分路由的流量都会被错误引导。我见过不止一次，因为某节点上手工加了一条 0.0.0.0/0 或者过宽的网段路由，导致整个节点的容器出网异常。排查到最后，问题不是方案本身，而是路由算法里“最长前缀匹配”的优先级被忽略了。

6. 实操：还原容器网络的关键算法细节

6.1 创建 Bridge 网络并验证容器间通信

理论部分说了这么多，不如直接动手验证一遍。下面的操作在安装了 Docker 的 Linux 环境下就能复现。

先创建一个自定义的 Bridge 网络，指定子网：

docker network create -d bridge --subnet=172.20.0.0/24 demo-net

接着启动两个容器并加入这个网络：

docker run -itd --rm --network demo-net --name c1 busybox docker run -itd --rm --network demo-net --name c2 busybox

进入 c1，尝试 ping c2：

docker exec -it c1 sh -c "ping c2"

你会惊讶地发现，c2这个名字在容器里直接被解析成了 172.20.0.3。这不是 Linux 系统自带能力，而是 Docker 内置的 DNS 服务在做解析：容器名到 IP 的映射被自动注册并下发。这意味着你不需要记住任何 IP，直接按名字访问容器即可。这就是一个简化版的服务发现，理解这一点，再去看 Kubernetes 的 Service 和 DNS，逻辑就是同一个套路的升级版。

6.2 查看端口映射背后的 iptables 规则

启动一个带端口映射的容器：

docker run -d --rm -p 8080:80 --name web nginx

然后在宿主机上查看 NAT 表规则：

iptables -t nat -L -n | grep 8080

你会看到一条 DNAT 规则，类似下面这种：

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80

这条规则就是端口映射的算法实体：所有目的端口为 8080 的数据包，目标地址都被改写成 172.17.0.2 的 80 端口。你还可以再看一下 POSTROUTING 链里针对 172.17.0.0/16 的 MASQUERADE 规则，那就是容器出网的源地址转换。

6.3 用 tcpdump 抓一次 VXLAN 封装包

如果你的环境里有 Flannel 或其他 VXLAN 方案的集群，在节点上执行：

tcpdump -i eth0 udp port 4789 -nn -vv

然后从 Pod A ping Pod B（跨节点），你会看到大量目的端口为 4789 的 UDP 包。这些包里内层才是真正的 ICMP 报文，外层只是普通的 UDP/IP 头。这一刻你就能直观感受到 Overlay 的算法路径：原始二层帧被装进了一个“信封”，靠着外层的宿主 IP 穿越物理网络，到了目标节点再拆开。没有这个抓包过程，你很难真正相信容器数据包在网络上原来是长这个样子的。

6.4 用 ipvsadm 验证不同调度算法

如果你有节点开启了 kube-proxy 的 IPVS 模式，可以直接用ipvsadm -L -n查看当前所有 Service 对应的虚拟服务和调度算法。想手动验证不同算法的行为差异，也可以在节点上直接用 LVS 模拟：

ipvsadm -A -t 10.0.0.1:80 -s wrr ipvsadm -a -t 10.0.0.1:80 -r 172.20.0.2:80 -w 2 ipvsadm -a -t 10.0.0.1:80 -r 172.20.0.3:80 -w 1

接着用连续请求打到 10.0.0.1:80，再观察连接统计。你会发现权重为 2 的后端拿到的连接数大约是权重为 1 的后端的两倍。看到这个分布之后，再回看前面那张算法表，就能记住 wrr 的核心是“按权重配比”，而不是绝对平均。

7. 常见问题与排查技巧实录

7.1 容器网络修不好？先按数据包的路径拆解

遇到容器网络故障，最容易犯的错误是“头痛医头”：ping 不通就反复重启容器，或者直接重刷网络插件。正确的思路是像一个数据包一样，沿着它的完整路径一段一段排查。

以跨主机 Pod 通信为例，典型路径是：Pod 内 veth → 节点 cni0 网桥 → 路由表 → VXLAN 隧道（或物理网卡）→ 目标节点 → 目标 Pod。每一段都可以用一条命令验证。先看 Pod 内的 IP 和路由：kubectl exec -it pod -- ip addr，再看节点上的网桥和路由：ip addr show cni0、ip route，再看隧道是否存在：ip link show flannel.1，最后用 tcpdump 确认数据包是否真的到达了物理网卡。按照这条链路逐段排查，问题总能定位在某一段区间里，而不是在某一个模糊的现象里。

7.2 连接一多就随机不通：conntrack 满的坑

这个坑我踩过，而且印象非常深刻。某次集群运行一段时间后，开始出现零星的连接超时，ping 大部分时间是通的，但 curl 经常随机失败。一开始以为是负载均衡或者 DNS 的问题，排查一圈都没找到原因。最后在宿主机上执行dmesg | grep conntrack，看到了“nf_conntrack: table full, dropping packet”的报错。

原因很清晰：conntrack 连接跟踪表的容量是有限的，当表的条目写满后，内核只能丢弃新连接的数据包。容器环境里连接生命周期短、量大，非常容易把这张表打爆。查看当前状态可以这样：

sysctl net.netfilter.nf_conntrack_max sysctl net.netfilter.nf_conntrack_count

如果count已经接近甚至等于max，说明表快满了。解决办法是调大上限、优化连接复用参数，或者缩短超时时间释放空闲记录。但最关键的还是监控：把 conntrack 的使用率加入日常告警，比事后排障有效十倍。这也是我后来一直坚持的底线。

7.3 MTU 引发的“能 ping 通但传大文件失败”

另一个高发问题跟 MTU 有关。现象非常有迷惑性：小包数据正常，应用能连上，ping 也能通，但一旦传输大文件或者下载大对象，就极速超时或断开。

原因是 VXLAN 这类 overlay 网络引入了额外封装头，内层报文的最大长度必须相应缩减。如果容器内部的 MTU 仍然是 1500，物理链路的 MTU 也是 1500，那加上 VXLAN 的 50 字节后，大包在物理网络上就直接被丢弃了。小包能过，是因为它们本来就没超限；大包会触发分片，而很多场景下分片包被直接丢弃，于是表现为大流量传输失败。检查方法很简单：在容器里 ping 宿主机，先发 1472 字节的数据，再发 1473 字节的数据，如果前者通后者不通，基本就是 MTU 超限的问题。把 Pod 和隧道接口的 MTU 统一调成 1450 或更小，这个问题通常立刻消失。

7.4 地址冲突与重启失效的排查

还有一个容易被误判的问题是容器重启后网络反复异常。表象是：某个 Pod 重启了很多次，每次都能成功启动，但集群里总有人反馈访问该服务有时失败。如果一查，发现这个 Pod 的 IP 在 ETCD 状态里显示归属正常，但实际网络上这个地址被两个 Pod 同时使用，那问题大概率出在 IPAM 层：节点本地状态与中心存储之间不一致，旧 Pod 的地址没有被及时回收，新 Pod 又把同一地址分配了出去。

遇到这种情况，先看 CNI 插件的日志，确认 ADD 和 DEL 操作是否成对出现。如果发现异常中断导致 DEL 没执行，优先清理节点上的残留网络设备，再让 kubelet 重新创建 Pod。平时养成好习惯：查看 ETCD 中节点的子网分配记录，比对各节点上报的子网是否重叠。地址冲突在容器环境里比传统环境更容易被隐藏，不要太依赖“一定不会分配重了”的假设。

我个人在这些年的容器网络维护里，最深的一个体会就是：遇到网络问题不要急着动容器，先把数据包路径在脑子里画一遍，再按图索骥逐段验证。容器网络看起来复杂，但它并没有发明全新的规则，MAC 自学习、最长前缀匹配、NAT 连接跟踪、哈希与轮询，这些算法每一层都是成熟的、可验证的。真正要练的，是把现象映射到算法层的能力。下次再遇到诡异的网络故障，不妨先问自己一句：这一步用的是哪个算法，这个算法的正常行为应该是什么？答案往往就在这个问题里。