pod网络隔离本质是linux网络命名空间的标准化封装：每个pod独占一个network namespace，内部容器共享ip、端口、路由及iptables，通过127.0.0.1通信；跨节点通信则依赖cni插件在宿主机网络层建立隧道打通。
Pod 的网络隔离，本质上是 Linux 网络命名空间（Network Namespace）在 Kubernetes 场景下的标准化封装和扩展。理解这一点，关键不是从 Kubernetes API 层往下猜，而是从 Docker 启动一个容器时内核实际创建了什么开始——那正是 Pod 网络行为的底层起点。
一、Docker 容器启动时，网络命名空间发生了什么
当你执行 docker run -d nginx，Docker 引擎会调用内核接口创建一个新的 Network Namespace。这个命名空间里包含：
- 一张独立的虚拟网卡（如
vethXXXXXX），一端连入容器内部，另一端挂载到宿主机的docker0网桥上 - 专属的回环设备
lo和 IP 地址（如172.17.0.2/16） - 独立的路由表（默认只有一条指向
docker0的直连路由） - 空的 iptables 规则链（除非你显式配置）
- 完全隔离的端口空间：两个容器都能监听
80，互不影响
此时，该容器就像一台拥有自己网络栈的“轻量虚拟机”，和其他容器天然不互通——这是隔离的起点，也是 Pod 网络模型的基石。
二、Kubernetes Pod 复用了这套机制，但做了关键增强
K8s 并没有重新发明网络栈，而是直接复用并规范了 Network Namespace 的使用方式：
- 每个 Pod 对应一个 Network Namespace，所有容器共享它（即共用同一套网卡、IP、路由、iptables）
- Pod IP 就是该命名空间中主网卡（通常是
eth0）的 IP，由 CNI 插件在 Pod 创建时注入 - 容器间通过
127.0.0.1通信，是因为它们同处一个 Network Namespace，协议栈看到的是同一个本地环回 - 不同 Pod 即使在同一节点，也因 Network Namespace 隔离而无法直接访问对方的
127.0.0.1
换句话说：Docker 容器 = 1 容器 + 1 Network Namespace；K8s Pod = N 容器 + 1 Network Namespace（共享）。差异不在隔离强度，而在共享粒度的设计意图。
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
三、跨节点通信靠的是“命名空间+外部连通”组合
单个 Network Namespace 只能实现本节点隔离。要让 Pod A（Node1）和 Pod B（Node2）通信，K8s 不破坏隔离，而是借助外部网络层打通：
- CNI 插件（如 Calico、Flannel）在宿主机网络中建立隧道或 Overlay 网络，把不同节点上的 Pod 子网逻辑连通
- 数据包离开 Pod 的 Network Namespace 后，经 veth pair → 网桥 → 隧道设备（如
vxlan0或caliXXXX）→ 物理网卡，最终到达目标节点 - 目标节点的 CNI 组件再将包送入对应 Pod 的 Network Namespace，完成交付
整个过程对 Pod 内部透明：它只知道自己有 IP、能发包、收到回应——背后是命名空间隔离 + 宿主机网络协同的结果，不是绕过隔离，而是尊重隔离前提下的智能互联。
四、验证方法：动手看一眼真实的命名空间
在运行着 Pod 的节点上，你可以直接观察其 Network Namespace：
- 查出 Pod 对应的 pause 容器 PID：
crictl ps | grep <pod-name></pod-name>，再crictl inspect <pause-pid> | grep pid</pause-pid> - 进入该命名空间查看网络设备：
nsenter -n -t <pid> ip a</pid>（你会看到eth0、lo，但看不到宿主机的ens33） - 对比宿主机：
ip a，你会发现两者接口列表完全不同 - 检查路由：
nsenter -n -t <pid> ip route</pid>，通常只有default via <gateway></gateway>和本地子网直连路由
这种“所见即隔离”的实感，比任何文档都更能说明问题：Pod 的网络边界，就是 Network Namespace 的边界。
