一、Network Namespace：Linux 内核的网络隔离利器
要理解 Pod 的网络共享，首先必须搞清楚 Network Namespace 是什么。
Network Namespace 是 Linux 内核提供的一种网络隔离机制。它允许在同一台物理主机上创建多个彼此完全独立的网络环境。每一个 Network Namespace 都拥有自己独立的一套网络资源：网络接口（如 eth0、lo）、IP 地址、路由表、防火墙规则（iptables/nftables）等等。换言之，每个命名空间就像一台独立的虚拟主机，拥有属于自己的网络栈。
举个直观的例子：在默认的主机命名空间中，你配置了一个 IP 地址为 192.168.1.1 的网卡。而在另一个命名空间中，你完全可以再配置一个同样是 192.168.1.1 的网卡，两者互不干扰。这就是命名空间的隔离能力——它让不同容器之间的网络配置完全独立，不会产生冲突。
正是基于这种隔离能力，Docker 和 Kubernetes 才得以在同一台宿主机上运行成百上千个容器，而每个容器都觉得自己独占了一套完整的网络环境。
二、Pod 的网络架构：pause 容器的"定海神针"作用
理解了 Network Namespace，我们再来看 Pod。
Pod 本身只是一个逻辑概念，它并非真正运行的实体。真正让 Pod 运转起来的，是其中的一组容器。而这组容器之所以能够共享网络，关键在于一个特殊的容器——pause 容器（也被称为 Infra 容器或基础设施容器）。
pause 容器的镜像极其精简，通常只有几百 KB 大小，它的唯一使命就是：占据一个 Network Namespace，然后"睡"在那里，永远不退出。当 Kubernetes 调度器决定在某个节点上创建一个 Pod 时，它会首先启动这个 pause 容器。pause 容器启动后，Linux 内核会为它创建一个全新的 Network Namespace，并分配一个虚拟网卡（eth0）和一个 IP 地址。
接下来，Pod 中的业务容器才会陆续启动。这些业务容器在创建时，会通过 Docker 的 --net=container:目标容器名 参数，将自己加入到 pause 容器的 Network Namespace 中。注意，这里不是新建一个命名空间，而是加入已有的命名空间。
这就好比：pause 容器先在一间屋子里装好了门窗、铺好了网线，然后其他容器一个个搬进来，共用这间屋子的所有网络设施。所有容器看到的 IP 地址、端口范围、路由表都是完全一样的。它们之间的通信，自然就可以通过 localhost 加端口号来完成，无需任何额外的网络转换。
这种设计巧妙地解决了容器启动顺序的问题。如果让业务容器之间互相依赖对方的网络命名空间，那么谁先启动就成了一个死结。而有了 pause 容器这个"中间人"，所有容器都往它身上靠，启动顺序的问题迎刃而解。
三、从内核到网络：veth pair 如何连接 Pod 与外界
Pod 内部的容器通过共享 Network Namespace 实现了 localhost 互通，但 Pod 本身还需要与外部世界通信。这就轮到 veth pair（虚拟以太网设备对） 登场了。
veth pair 是一种成对出现的虚拟网络设备，可以把它想象成一根虚拟网线的两端。一端放在 Pod 的 Network Namespace 中（作为 eth0），另一端放在宿主机的默认命名空间中。
具体流程是这样的：CNI（容器网络接口）插件在为 Pod 分配完 IP 地址后，会创建一对 veth 设备。其中一端被放入 pause 容器的网络命名空间，并命名为 eth0，配置上分配到的 IP 地址；另一端则留在宿主机上，并被连接到宿主机的网桥（如 cbr0 或 flannel.1 等）上。
通过这根"虚拟网线"，Pod 内部的流量可以到达宿主机的网桥，再经由网桥转发到其他 Pod 或外部网络。而由于同一 Pod 内的容器共享同一个 Network Namespace，它们之间的流量根本不会经过 eth0 接口——它们直接通过 lo（回环）设备通信，效率极高。
这里有一个精妙的设计细节：Pod 的 eth0 接口实际上只具备收发数据包的能力，数据包的转发、丢弃等决策由宿主机上的网桥统一处理。这意味着 Pod 本身不需要维护复杂的路由表，所有的路由决策都交给了底层的网络设施。
四、IP 地址的分配与管理：CNI 与 IPAM 的协作
Pod 的 IP 地址从何而来？这要归功于 CNI 插件与 IPAM（IP 地址管理）组件的默契配合。
当 pause 容器的网络命名空间创建完成后，CNI 插件会调用 IPAM 组件来申请一个可用的 IP 地址。IPAM 维护着整个集群的地址池，确保每个 Pod 分配到的 IP 都是唯一的、不冲突的。拿到 IP 后，CNI 插件会将这个地址配置到 pause 容器的 eth0 网卡上。
从此，这个 IP 就成了整个 Pod 的"门牌号"。Pod 内所有容器共享这个 IP 和端口空间。这也意味着，如果两个容器试图监听同一个端口，就会产生冲突——这正是 Pod 设计理念的体现：Pod 内的容器应该是"超亲密"关系，它们本就应该紧密协作，而非彼此隔离。
值得一提的是，Kubernetes 的网络模型遵循"每个 Pod 拥有唯一 IP" 的原则，这是一个非 NAT 的扁平化地址空间。也就是说，Pod 之间可以直接通过 IP 互访，不需要经过地址转换。这种设计极大地简化了网络拓扑，让服务发现和通信变得更加直接。
五、跨节点通信：当 Pod 分布在不同主机上
上面讨论的都是同一节点内 Pod 的通信。但在实际生产环境中，Pod 往往分布在不同的物理节点上。此时，localhost 无法跨机器使用，那 Pod 之间如何通信？
这就需要借助 overlay 网络或 underlay 路由来实现。以主流的 flannel 方案为例：每个节点上运行一个 flannel 守护进程，它从集中的地址池中为本节点分配一个子网段，并在节点上创建一个虚拟网络接口（如 flannel.1）。当 Pod A 要发送数据包给另一节点上的 Pod B 时，flannel 会将原始数据包封装在 UDP 包中（通常使用 8472 端口），外层源地址是节点 A 的物理 IP，目的地址是节点 B 的物理 IP。节点 B 收到后解封装，将原始数据包交给本地的 Pod B。
另一种方案是 calico 的 direct 模式，它通过 BGP 协议在全网传播容器网段的路由信息，让每个网络设备都知道如何到达每个 Pod 的 IP。数据包无需封装，直接在 underlay 网络上转发，性能更优，但对网络设备的配置有一定要求。
无论哪种方案，核心思路都是一致的：让每个 Pod 的 IP 在整个集群中都是可达的，从而实现真正意义上的端到端通信。
六、为什么选择共享而非独立？
你可能会问：为什么不让每个容器都拥有独立的 Network Namespace，然后通过服务发现来通信？
原因在于 Pod 的设计哲学。Pod 中的容器通常是"协同工作"的关系——比如一个主应用容器搭配一个日志采集容器、一个代理容器。它们之间需要频繁交换数据，如果每个容器都有独立的网络栈，不仅会浪费资源，还会增加通信的复杂度。
共享 Network Namespace 带来了三个显著的好处：
第一，通信效率极高。 容器之间通过 lo 回环设备通信，数据不出内核态，延迟极低，几乎可以忽略不计。
第二，端口协调变得简单。 由于所有容器共享端口空间，开发者可以很自然地用 localhost:端口 来访问同 Pod 内的其他容器，无需配置额外的服务发现机制。
第三，资源开销极小。 只需要一个 pause 容器维护一个网络命名空间，而不是每个容器都维护一套独立的网络栈，大大降低了系统资源的消耗。
当然，这种设计也有代价：同 Pod 内容器之间的网络隔离性降低了，端口冲突的风险需要开发者自行管理。但这恰恰符合 Pod 的定位——它本就不是为了隔离而设计的，而是为了让紧密协作的容器组成一个不可分割的整体。
七、实战中的注意事项
在实际开发中，有几个与 Pod 网络共享相关的要点值得关注：
其一，hostNetwork 模式会打破共享机制。 如果将 Pod 设置为 hostNetwork: true，那么 Pod 将直接使用宿主机的网络命名空间，不再拥有独立的 IP。此时 Pod 内容器虽然仍可通过 localhost 通信，但它们与宿主机上的其他进程共享了网络栈，隔离性大幅下降。这种模式适合对网络性能有极高要求的场景，但在生产环境中应谨慎使用。
其二，Pod 的 IP 不是固定的。 当 Pod 被重调度到其他节点时，它的 IP 会随之改变。因此，不建议直接通过 Pod IP 进行通信，而应该通过 Service 对象来提供稳定的访问入口。Service 会为一组 Pod 提供一个固定的虚拟 IP 和 DNS 名称，客户端只需访问这个地址即可。
其三，pause 容器的镜像必须可达。 在集群初始化阶段，所有节点都需要能够拉取到 pause 容器的镜像（默认为 k8s.gcr.io/pause:3.5）。如果镜像拉取失败，Pod 将一直处于 Pending 状态，因为第一个容器都起不来，后面的容器自然也无法启动。
结语
Pod 内容器之间的 localhost 互通，看似简单，实则是 Linux 内核 Namespace 机制与 Kubernetes 编排逻辑完美结合的产物。pause 容器如同一位沉默的基石，撑起了整个 Pod 的网络世界；veth pair 如同一座座桥梁，将 Pod 连接到广阔的集群网络；CNI 插件则如同一位精明的管家，为每个 Pod 分配独一无二的身份。
理解了这套机制，你就真正读懂了 Kubernetes 网络模型的精髓。下一次当你在 Pod 中用 localhost:8080 访问同伴容器时，不妨会心一笑——这背后，是 Linux 内核数十年演进的智慧结晶。
