容器运行时云原生【免费下载链接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:项目地址https://gitcode.com/gh_mirrors/do/docker-ce点击查看免费下载导读在 libnetwork 出现之前Docker 的容器网络完全由 Docker Engine 与 libcontainer 两个组件分工完成——前者负责网络栈配置与策略后者负责设备创建与命名空间装配。本文以 legacy.md 为骨架结合 docker-ce 仓库内 bridge 驱动与命名空间实现的真实源码还原这套前 libnetwork 时代的单主机网络方案linux bridge iptables NAT 端口映射并梳理它如何演化为今天的 CNMContainer Network Model。1. 背景一篇 TLDR 式的历史档案legacy.md在 libnetwork 文档目录中的定位非常特殊它并不是 libnetwork 自身的设计文档而是对 Docker v1.6 时代网络设计的太长不看版TLDR速记。该文档开篇就说明若想了解更详细的运维级设计需要查阅原始官方文档它保留在这里的核心意义正如 design.md 所明确指出的——libnetwork 的诸多设计决策正是从 Docker v1.6 网络设计的学习中获得的灵感。因此理解这篇 legacy 文档就等于理解 libnetwork 诞生的历史动因一套什么架构、存在什么问题才催生了后来模块化的容器网络模型。2. 双组件分工Engine 负责策略libcontainer 负责装配在 libnetwork 之前Docker 容器网络由两个组件协同完成Docker Enginedaemon 进程负责生成并持有容器网络栈的配置——包括选择哪种网络方案、如何分配地址、如何连通容器、如何开放端口。libcontainer容器运行时库作为 Engine 的执行器读取这份配置创建必要的网络设备并把它们移入网络命名空间network namespace。这个命名空间随后在容器启动时被真正投入使用。这条调用链的关键在于配置与执行的分离Engine 只做抽象层面的网络规划libcontainer 只做内核层面的网络对象装配。两者的交界处就是一份网络配置描述——它决定了 veth 对、地址、路由最终以什么形态出现在容器的隔离网络栈里。3. Engine 侧Bridge Driver、linux bridge 与 iptableslegacy 文档明确指出Docker Engine 借助Bridge Driver提供单主机single-host网络方案底层依赖两样东西linux bridge一个内核级二层交换机把所有接入同一主机网络的容器虚拟网卡桥接在同一个二层域内iptables负责三类关键工作——容器间隔离filter 表、出站流量的地址伪装nat 表 MASQUERADE、入站流量的端口转发nat 表 DNAT。这套机制的雏形在今天的 libnetwork bridge 驱动源码中依然可以精确对上号默认网桥名docker0定义于 drivers/bridge/interface.goDefaultBridgeName docker0iptables 侧的DOCKER链nat 与 filter 两张表、用于桥接网络间隔离的DOCKER-ISOLATION-STAGE-1/STAGE-2链全部创建于 drivers/bridge/setup_ip_tables.go出站 NAT 规则的本质见 setup_ip_tables.go当配置了HostIP时使用显式SNAT --to-source否则退化为MASQUERADE——让内核依据路由表自动挑选出口地址。如上图摘自 network.md 的 bridge 模式流程示意所示这套拓扑正是 legacy 文档所描述的架构的完整落地形态容器被装入独立的网络命名空间一端 veth 挂到宿主机docker0另一端进容器容器获得docker0子网内地址并以docker0为默认网关出站流量经 POSTROUTING 链 MASQUERADE 伪装入站则靠 DOCKER nat 链 DNAT 到容器地址。4. 面向用户的抽象--link、--expose与完全透明legacy 文档强调了一个非常重要的设计取向Docker Engine 通过--link、--expose这类简单配置让同一主机内的容器互相连通把网络配置完全从容器视角中抽象掉——容器本身不需要关心自己的 IP、网关、路由一切由 Engine 在背后打理。--expose声明容器内部的服务端口为后续端口映射做准备--link在两个容器间建立链接关系通过容器名/别名在目标容器的网络栈中注入对方的连接信息实现同主机内容器互联端口映射port mapping把容器内端口映射到宿主机端口供外部访问。值得注意的一个细节legacy 链接--link在今天已是历史特性仓库源码明确标注其适用范围被严格限制。见 daemon/container_operations.go 的注释Legacy Link 特性仅支持默认 bridge 网络Legacy Link 只能通过docker run --link使用。也就是说--link从诞生起就与默认 bridgedocker0网络深度绑定属于单主机、单默认网络的产物——这也是多主机时代它迅速让位于自定义网络与服务发现的原因。5. 外部连通性NAT 与端口映射单主机模式下容器的 IP 是网桥子网内的私有地址天然不可被外部访问。legacy 文档指出外部连通性完全依赖 NAT网络地址转换与端口映射Port-mapping出站容器访问外网时流量在路由后被 MASQUERADE 规则改写源地址为宿主机出口接口的 IP入站宿主机上监听特定端口publishedPort命中该端口的流量经 DNAT 规则改写目的地址/端口转发到容器内部的监听端口targetPort。这套私有子网 双 NAT的模式在源码中同样可以溯源DNAT 规则被编程进DOCKERnat 表链而接受转发的规则进入DOCKERfilter 表链端口映射的宿主端绑定信息由OptionPortMapping传入相关逻辑集中在 drivers/bridge/port_mapping.go 与 daemon 侧 container_operations.go。局限性也随之而来这套方案本质上是单主机 网桥 伪装的组合端口映射是宿主机粒度的——集群中多个节点、多副本服务之间的负载均衡与跨主机寻址它完全无能为力。这为后面 swarm/overlay 模式同样由 iptables、独立网桥与 VXLAN 组合实现见 network.md以及 libnetwork 的模块化架构埋下了伏笔。6. libcontainer 侧设备创建与网络命名空间legacy 文档勾勒了执行侧的职责libcontainer 依据 Engine 提供的配置创建必要的网络设备并把这些设备移入网络命名空间该命名空间在容器启动时被使用。这里的核心概念是network namespace——Linux 内核的隔离机制让每个容器拥有独立的网络栈视图接口、路由表、iptables 规则、DNS 配置互不影响。这套为容器建立隔离网络栈的思想在 libnetwork 中被完整继承并抽象为Sandbox概念。在 design.md 中 Sandbox 被明确定义为容器网络栈配置的载体包含接口、路由表与 DNS 设置的托管。其 Linux 实现直接落在命名空间层面libnetwork 的networkNamespace类型注释明确写着——是 Sandbox 接口的 linux 实现代表一个 linux 网络命名空间每个 sandbox 通过宿主文件系统上的唯一路径标识接口在命名空间间的移动与路由表管理依赖 netlink 调用。见 libnetwork/osl/namespace_linux.go命名空间基路径默认挂载于/var/run/docker/netns。从源码结构可以推断legacy 时代libcontainer 装配命名空间的执行模式正是后来 libnetwork 中 oslOperative System Layer操作系统层抽象与 sandbox 机制的原始形态——职责相同只是从单一运行时库的职责升级为可插拔网络模型的标准构件。7. 传承与演进从 v1.6 架构到 Container Network Modellegacy.md 不是一篇孤立的历史档案它与 libnetwork 的现代架构构成直接的因果链条问题驱动v1.6 架构把网络策略Engine与网络实现bridge/iptables耦合在一起驱动能力不可插拔多主机场景无从扩展目标libnetwork 追求 Docker 与 Linux 的哲学——小而模块化、可独立工作、可组合将容器网络变为可满足的可组合需求产出Container Network ModelCNM用Sandbox / Endpoint / Network三个构件与 NetworkController、Driver 两类对象把 legacy 架构中隐式的分工显式化、插件化。如上图所示CNM 的核心抽象可以看作 legacy 架构的理论化重建legacyDocker v1.6CNM / libnetwork关系libcontainer 移入容器网络命名空间Sandbox命名空间实现成为 Sandbox 的一种具体实现Linux netnsveth 对 网桥端口Endpoint端点被抽象为服务接入点可先于容器创建docker0 网桥linux bridgeNetwork网桥成为 Network 的一种驱动实现bridge driverEngine 内嵌的网络逻辑Drivernull / bridge / overlay / remote可插拔、可远程承载daemon 的 CreateNetwork 流程NetworkController.NewNetwork()见 daemon/network.go 的调用链其中Endpoint 先于容器存在的设定值得一提CNM 生命周期文档design.md解释了为什么要CreateEndpoint与Join两步——因为 Endpoint 代表的是服务而非某个具体容器创建时即保留资源任何容器随后接入都能获得一致的网络行为。这与 legacy 时代容器即网络单元的朴素模型形成了清晰的分层进步。8. 结语历史文档的当代阅读价值legacy.md只有十几行却是理解 docker-ce 网络体系的关键钥匙它是设计源头libnetwork 的 CNM 决策直接受其启发design.md 开篇即引用它是概念索引linux bridge、iptables、NAT、端口映射、网络命名空间这五个词几乎概括了 Docker 单主机网络的全部物理机制而这些机制至今仍是 bridge 驱动与 swarm ingress 的底层事实对照 drivers/bridge 目录与 network.md 即可验证它是演进参照系只有先看懂Engine libcontainer 的紧密耦合才能真正理解 CNM 的 Sandbox / Endpoint / Network 三分模型与驱动插件化设计解耦了什么、抽象了什么、增强了什么。若想继续深入建议按此顺序阅读仓库内文档design.mdCNM 完整设计→ bridge.mdbridge 驱动→ network.mdbridge 与 overlay 模式数据流→ overlay.md跨主机实现。对照源码时优先阅读 drivers/bridge/ 下的interface.go、setup_ip_tables.go、port_mapping.go以及 libnetwork/osl/ 的命名空间实现即可把这篇历史档案的每一句话还原成可运行的内核行为。赞分享容器运行时云原生【免费下载链接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:项目地址https://gitcode.com/gh_mirrors/do/docker-ce点击查看免费下载相关推荐Moby 遗留网络架构详解libnetwork 之前基于 Bridge iptables 的单主机容器网络设计Moby 遗留网络架构详解libnetwork 之前基于 Bridge iptables 的单主机容器网络设计 本文围绕 MobyDocker 引擎仓云原生容器运行时虚拟化容器编排终极指南Flutter混合架构网络层设计——WebView与原生HTTP客户端的深度协同方案终极指南Flutter混合架构网络层设计——WebView与原生HTTP客户端的深度协同方案 在现代Flutter应用开发中混合架构已成为构建复杂应用的常见网络后端WebSocketDocker网络模型深度解析Libnetwork如何实现容器网络隔离Docker网络模型深度解析Libnetwork如何实现容器网络隔离 Docker网络隔离是容器技术中至关重要的功能它通过libnetwork项目为容器提供云原生容器运行时虚拟化容器编排上一篇告别权限管理混乱Accompanist权限组件的终极集成指南下一篇kube-bench完全指南基于CIS基准的Kubernetes安全检测工具终极解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考