docker容器网络演进分为四个阶段：默认bridge→自定义bridge→多机overlay→service mesh+ebpf加速；分别解决ip易变、跨机通信、流量治理与性能瓶颈问题，核心锚点包括命名空间、veth、网桥、nat、vxlan、dns和ebpf。

Docker 容器网络架构不是一成不变的，它的演进本质是从单机隔离走向跨节点协同、从手动配置走向自动编排、从 IP 依赖走向服务抽象。学它不能只背命令，得顺着真实场景痛点走。

先搞清四个关键跃迁阶段

Docker Ctl

使用 podman 检查容器、日志和镜像

下载

• 默认 bridge（docker0） → 自定义 bridge
  默认网桥用起来简单，但容器重启 IP 就变、不能按名字通信、端口容易冲突。自定义 bridge 解决了 DNS 自发现（ping app2 能通）、子网可规划、支持 --ip 固定地址。这是生产单机部署的起点。
  ✅ 建议动手：

  • docker network create --subnet 10.10.1.0/24 mynet
  • 启两个容器连进去，docker exec -it c1 ping c2 看是否通
  • docker inspect c1 | grep IPAddress 对比默认 bridge 和自定义的 IP 分配差异

• 单机 bridge → 多机 overlay（Swarm 模式）
  容器跨物理机通信时，bridge 不再适用。Overlay 驱动用 VXLAN 封装二层帧，通过 UDP 隧道穿透主机网络，让不同机器上的容器像在同一个局域网里。Swarm 内置服务发现和负载均衡（VIP + DNS RR）。
  ✅ 关键点：

  • 必须初始化 Swarm：docker swarm init
  • 创建 overlay 网络需加 --attachable 才能被独立容器使用
  • 容器名解析依赖 Swarm 内置 DNS（127.0.0.11），不是 /etc/hosts

• overlay → Service Mesh（如 Istio + CNI 插件）
  Overlay 解决了“连通”，但没解决“可控”——比如灰度流量、mTLS 加密、细粒度策略。这时需要把网络能力下沉到数据平面（如 Envoy），由控制平面统一下发规则。Docker 原生不提供，得靠 Calico、Cilium 等 CNI 插件对接 Kubernetes 或 Swarm。
  ✅ 注意区别：

  • Docker 的 overlay 是集群级网络，Service Mesh 是应用级通信治理
  • Cilium 用 eBPF 替代 iptables，性能更高，策略更灵活

• 传统网络驱动 → eBPF 加速的现代网络栈
  旧方案靠 iptables 做 NAT 和防火墙，规则多时性能下降明显。Cilium、Katana 等基于 eBPF，在内核层面高效处理连接跟踪、负载均衡、安全策略，无需修改内核模块。
  ✅ 实践提示：

  • 在支持 eBPF 的内核（≥5.8）上启用 Cilium，观察 cilium status
  • 对比 iptables -t nat -L | wc -l 和 bpftool prog list | grep cilium 的规则规模

学的时候盯住三个锚点

• 看清每层解决什么问题：命名空间隔离网络视图、veth pair 连通两端、网桥交换、NAT 出外网、VXLAN 跨机封装、DNS 做服务发现、eBPF 做高性能转发
• 每个命令背后对应哪个组件：docker network create 调 libnetwork；docker service create 触发 Swarm 控制器生成 VIP 和 endpoint；cilium install 注入 eBPF 程序到内核
• 故障一定从路径拆解：容器→veth→网桥→iptables/eBPF→宿主网卡→物理网络→对端，逐段 ping、tcpdump、cilium monitor

不复杂但容易忽略