Docker容器网络演进分为四个阶段：默认bridge→自定义bridge→多机overlay→Service Mesh+eBPF加速；分别解决IP易变、跨机通信、流量治理与性能瓶颈问题，核心锚点包括命名空间、veth、网桥、NAT、VXLAN、DNS和eBPF。
Docker 容器网络架构不是一成不变的，它的演进本质是从单机隔离走向跨节点协同、从手动配置走向自动编排、从 IP 依赖走向服务抽象。学它不能只背命令，得顺着真实场景痛点走。
先搞清四个关键跃迁阶段
-
默认 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
- 必须初始化 Swarm：
-
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的规则规模
- 在支持 eBPF 的内核（≥5.8）上启用 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
不复杂但容易忽略
