同节点容器通信靠宿主机上的Linux网桥做二层转发，跨节点容器通信则靠VXLAN隧道或BGP路由把不同宿主机的网段连起来；理解这两条路径，基本就抓住了容器网络模型的主干。
同节点容器通信过程：一根虚拟网线的旅程
容器一启动，Linux内核就会给它分配独立的网络命名空间，这个命名空间里只有自己的网卡、路由表、ARP表，看起来像一台单独的小机器，但在同一台宿主机上，两个容器之间并不直接连网线,它们通过宿主机内部的一台虚拟交换机完成通信。
同节点容器通信过程详解
以Docker默认的桥接网络为例,同节点两个容器互相ping的链路是这样的：
- 容器A发出ICMP请求,目标IP是容器B的地址。
- 容器A查路由表，发现目标不在自己的网段,把包交给默认网关。
- 默认网关通常就是Docker网桥的地址，比如172.17.0.1。
- 容器A的eth0通过veth pair连到宿主机上的docker0网桥,数据从veth一端进入docker0。
- docker0作为Linux bridge做二层转发，查询MAC地址表后,把包送到连向容器B的那根veth上。
- 容器B的eth0收到包，内核协议栈处理,回包反向走一遍。
整个过程中，容器A和容器B的流量没有离开宿主机，这就是为什么同节点容器通信延迟低、带宽高,多数情况下只受宿主机CPU和内存带宽限制。
实操命令可以直接验证这条路径：
docker network ls查看现有网络。docker inspect bridge查看docker0的网段和网关。brctl showmacs docker0或bridge fdb show docker0查看网桥学到的MAC地址表。docker inspect -f '{{.State.Pid}}' 容器名获取容器进程PID。nsenter -t PID -n ip addr进入容器网络命名空间查看eth0地址。
如果容器用的是自定义网络，docker network create demo-net，Docker会创建独立网桥 br-网络ID，并把连接的容器挂到这个网桥上，同节点通信逻辑不变,只是网桥隔离性更好。
Docker网络模式对比：桥接、主机与容器共享
单机上Docker提供几种网络模式,理解差异对排查同节点问题很有帮助。
| 网络模式 | 网络命名空间 | 隔离性 | 同节点互访方式 | 适用场景 |
|---|---|---|---|---|
| bridge | 每个容器独立 | 强 | 通过网桥二层转发 | 默认单机容器 |
| host | 与宿主机共享 | 弱 | 直接使用宿主机端口 | 性能敏感、端口少 |
| container | 与指定容器共享 | 中 | 共享同一套协议栈 | 边车、日志采集 |
| none | 独立但无网卡 | 强 | 无法直接通信 | 特殊隔离需求 |
生产中不建议长期使用默认docker0网络，自定义桥接网络的DNS解析更友好，容器名可以直接当主机名用,这条也是容器网络模型基础里容易忽略的细节。
跨节点容器通信原理是什么：从隧道到路由
同节点靠网桥就能解决，但容器一旦分布到两台宿主机，问题就变了，宿主机A上的容器网段通常是10.244.1.0/24，宿主机B上的容器网段是10.244.2.0/24，两个网段中间隔着物理网络，而物理网络通常不感知容器的IP地址，跨节点容器通信原理是什么？本质上就是让不同宿主机之间的容器IP路由可达。
常见跨节点通信路径
- VXLAN隧道模式：把容器原始二层帧封装进UDP包，通过宿主机的IP网络传输，对物理网络来说,只看到宿主机之间的UDP流量。
- IPIP隧道模式：把容器IP包再包一层IP头，开销比VXLAN小,但只支持IPv4。
- 直连路由模式：宿主机之间直接交换容器网段的路由，不需要隧道封装,Calico的BGP模式就是典型。
- 混合模式：同一子网内直连，跨子网走隧道,主流CNI插件都支持这种策略。
在Flannel VXLAN模式下，每台宿主机上会创建一个VTEP设备，通常叫flannel.1，容器流量到达宿主机路由表后，匹配到远端容器网段的路由，下一跳指向对端VTEP地址，内核封装VXLAN后，从宿主机物理网卡发出去，对端宿主机收到UDP包，解封装后把原始二层帧交给本地网桥,再转发给目标容器。
操作验证：
ip route查看宿主机上到远端容器网段的路由，下一跳通常是flannel.1或tunl0。ip -d link show flannel.1查看VXLAN设备的远程VTEP地址和VNI。bridge fdb show dev flannel.1查看MAC地址与VTEP的映射关系。- 抓包可看UDP端口，Flannel VXLAN常用8472,标准VXLAN用4789。
CNI插件怎么选：Flannel、Calico、Cilium对比
据CNCF公开资料，CNI规范已经成为Kubernetes容器网络的接入标准，kubelet在创建Pod时，会调用CNI插件完成IP分配和网络接入,不同插件对跨节点通信的实现差异很大。
| 插件 | 数据平面 | 封装方式 | 性能表现 | 网络策略 | 运维复杂度 | 适用场景 |
|---|---|---|---|---|---|---|
| Flannel | 内核VXLAN | 有封装 | 中等 | 弱 | 低 | 中小规模、快速落地 |
| Calico BGP | 路由直连 | 无封装 | 较高 | 强 | 中 | 私有数据中心、自建机房 |
| Calico IPIP | 隧道 | 轻封装 | 中高 | 强 | 中 | 云上跨网段 |
| Cilium | eBPF | 视模式 | 高 | 最强 | 高 | 大规模、安全策略密集 |
国内K8s网络插件哪个好：结合场景看成本
国内生产环境选型时，很少有“最好”的插件,只有更匹配的方案。
- 团队规模小、节点几十台以内、没有复杂网络策略需求：Flannel VXLAN多数情况下够用，配置少,排障简单。
- 自建机房、底层交换机可以放行BGP或愿意部署路由反射器：Calico BGP模式性能更好,还能直接使用NetworkPolicy。
- 云上跨可用区部署：部分云环境不支持裸BGP，Calico IPIP或VXLAN更容易落地。
- 需要细粒度安全策略、可观测性：Cilium功能强,但运维门槛也高。
成本方面，主流CNI插件都是开源免费，差别主要在运维人力，行业共识认为，网络插件不是越新越好，稳定性和团队熟悉程度往往决定生产故障率，国内地域分散部署时，跨节点容器通信的链路会更长,优先选择封装模式兼容性好的方案。
容器网络模型基础：CNI规范与网络命名空间
容器网络模型之所以能统一，主要靠CNI规范把“创建网络”这件事标准化了，CNI插件不负责容器运行时,只负责在容器网络命名空间和宿主机网络之间建立连接。
CNI插件工作流程
- kubelet创建Pod时，先起pause容器,拿到网络命名空间路径。
- 读取
/etc/cni/net.d/下的配置文件,按顺序选择插件。 - 调用
/opt/cni/bin/下的插件二进制,命令为ADD。 - 插件分配IP、建立veth、配置路由,返回结果给kubelet。
- Pod删除时调用DEL命令,回收IP和网络资源。
手动测试CNI插件的命令可以这样写：
CNI_COMMAND=ADD CNI_CONTAINERID=test-id CNI_NETNS=/var/run/netns/test CNI_PATH=/opt/cni/bin /opt/cni/bin/bridge < /etc/cni/net.d/10-test.conflist
这个操作会模拟Pod接入网络的过程,排查CNI问题时很实用。
网络命名空间与veth pair：排障时先看这三处
- 容器内网卡是否拿到IP：
nsenter -t PID -n ip addr。 - 宿主机veth是否连到网桥：
ip link找vethxxxx，bridge link看对应关系。 - 路由是否指向正确网关：
nsenter -t PID -n ip route。
同节点不通多数卡在网桥没学到MAC，或iptables FORWARD链拦截，跨节点不通多数卡在宿主机的ip_forward未开启,或CNI插件没有下发远端路由。
容器网络模型基础Q&A：同节点和跨节点通信常见问题
同节点容器通信过程里，为什么两个容器ping不通？
先查容器内路由，确认默认网关是网桥IP，再查宿主机iptables FORWARD链，Docker权默认允许，但自建CNI或自定义防火墙规则可能拦截，还要检查内核参数 net.ipv4.ip_forward 是否为1，以及 net.bridge.bridge-nf-call-iptables 是否导致二层包被iptables处理，最后看网桥的MAC地址表,确认veth是否在正确的网桥上。
跨节点容器通信原理是什么？VXLAN和BGP路由模式怎么选？
VXLAN把容器二层帧封装在UDP包，对底层网络透明，适合跨机房、跨可用区，BGP路由模式直接交换容器网段路由，不做封装，性能更好，但要求底层网络支持路由协议或部署路由反射器，云上环境多数情况下VXLAN兼容性更稳,自建机房且网络设备可控时BGP更合适。
国内K8s网络插件哪个好？按什么标准选？
没有统一答案，节点少、无策略需求用Flannel；有网络策略需求且自建机房用Calico BGP；云上跨网段用Calico IPIP或VXLAN；安全要求高、团队能力强用Cilium，真实选型先跑通跨节点容器通信，再逐步增加策略和可观测性,比一开始上最复杂方案更可靠。
同节点查网桥和veth，跨节点查路由和隧道，容器网络排查只要顺着这两条路径往下走,多数问题都能定位到具体设备。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641219.html
