容器网络是面试中区分候选人水平的重要模块，单纯会使用 docker run 或 kubectl 命令远远不够。面试官真正想考察的是对 Linux 网络栈、数据包流转路径以及容器编排系统网络模型的掌握程度。本文围绕常见的容器网络面试题，从网络命名空间和 veth pair 的底层机制讲起，逐步延伸到 Docker 多种网络驱动以及 Kubernetes 的 Pod 通信与 Service 实现，帮助读者建立一套可以应对追问的知识体系。
一、网络命名空间与veth pair：容器隔离与通信的底座
Linux 网络命名空间（network namespace）提供了独立的网络栈，包括网卡、路由表、iptables 规则等。每个容器在启动时都会被分配一个独立的网络命名空间，因此容器内部看到的网络设备与宿主机完全不同。这种隔离机制让不同容器可以绑定相同的端口而不会冲突，同时也为精细化的网络策略提供了基础。理解这一点是回答容器网络隔离原理的关键。
但隔离之后还需要通信，veth pair 就是连接容器命名空间与宿主机网络的一座虚拟网桥。veth pair 总是成对出现，数据从一端进入，会立即从另一端发出。典型做法是把 veth 的一端放入容器的网络命名空间并配置为 eth0，另一端留在宿主机上并接入 docker0 或 cni0 之类的网桥。这样容器发出的数据包先经过 veth 到达宿主机网桥，再由宿主机路由或转发到目标位置。面试中如果被问到容器间同主机通信为什么能通，核心答案就是 veth pair 加上二层网桥的转发。
# 创建一个网络命名空间模拟容器 ip netns add netns-demo # 创建一对 veth 设备 ip link add veth0 type veth peer name veth1 # 将 veth1 放入网络命名空间 ip link set veth1 netns netns-demo # 启动两端设备并配置 IP ip link set veth0 up ip netns exec netns-demo ip link set veth1 up ip addr add 10.0.0.1/24 dev veth0 ip netns exec netns-demo ip addr add 10.0.0.2/24 dev veth1 # 在命名空间内 ping 宿主机一端验证连通性 ip netns exec netns-demo ping -c 2 10.0.0.1
上面的命令手动模拟了容器网络的创建过程，实际 Docker 和 Kubernetes 的容器运行时就是按照类似逻辑自动完成这些操作的。在面试回答时如果能主动提到网络命名空间的隔离属性和 veth pair 的数据转发机制，会比只背 docker network 命令更有说服力。
二、Docker 网络驱动对比：bridge、host、none 及跨主机方案
Docker 默认使用 bridge 模式，守护进程会创建一个名为 docker0 的 Linux 网桥，所有未指定网络的容器都会接入这个网桥。容器之间通过 docker0 直接二层互通，但宿主机外部无法直接访问容器 IP。要让外部访问容器服务，需要通过端口映射将宿主机的端口转发到容器的服务端口，底层依赖 iptables 的 DNAT 规则实现。面试官经常追问端口映射的底层原理，答案就在 iptables 的 PREROUTING 链和 DOCKER 链上。
host 模式让容器直接共享宿主机的网络命名空间，容器不会获得独立的 IP，也不需要端口映射，网络性能最好，但端口冲突风险高。none 模式则完全不给容器配置网络，适合需要自定义网络或者安全隔离要求极高的场景。除了这三种基础模式，overlay 网络通过 VXLAN 隧道实现跨主机容器通信，常用于 Docker Swarm 集群；macvlan 驱动则让容器直接获得物理网络中的独立 MAC 地址，适合需要直连底层网络的场景。面试中可以按使用场景来归纳：单机默认 bridge，高性能或特殊需求 host/none，跨主机用 overlay 或 macvlan。
# 查看当前 Docker 网络 docker network ls # 创建自定义 bridge 网络并指定网段 docker network create --driver bridge --subnet 172.18.0.0/16 my-bridge # 运行容器并接入自定义网络 docker run -d --name web --network my-bridge nginx # 查看容器在宿主机上的 veth 对应关系 ip link show | grep veth # 查看 iptables 中 Docker 相关的 NAT 规则 iptables -t nat -L -n | grep DOCKER
上面最后一条命令展示了端口映射时 iptables 规则的关键位置。如果面试中被问到 Docker 网络如何实现隔离与连通，可以结合 docker0 网桥、veth pair 和 iptables 三个层面来回答。需要注意的是，bridge 网络下的容器 IP 在宿主机之外不可路由，必须通过 NAT 转换；而 macvlan 或 overlay 则绕过了这一限制，但实现更复杂。
三、Kubernetes 网络模型：Pod 通信、Service 与 CNI
Kubernetes 对所有容器网络提出了统一要求：每个 Pod 拥有独立 IP，所有 Pod 之间无需 NAT 就能直接通信，节点上的网络代理也能与 Pod 直接通信。Pod 内容器共享同一个网络命名空间，这个命名空间由基础设施容器 pause 创建，业务容器加入其中。因此同一个 Pod 内的容器可以通过 localhost 互相访问，这也是面试中的高频考点。很多候选人容易忽略 pause 容器的作用，实际上它负责固定网络命名空间和 PID 命名空间，保证业务容器重启后 IP 不丢失。
Service 是 Kubernetes 提供稳定访问入口的抽象，但 Service 的 ClusterIP 并不是一个真实存在的网卡地址，它只是 iptables 或 IPVS 规则中的一个虚拟 IP。kube-proxy 组件监听 Service 和 Endpoints 变化，在节点上生成相应的转发规则。iptables 模式下，访问 ClusterIP 的数据包会被 DNAT 到某个后端 Pod 的 IP 和端口；IPVS 模式则使用内核的负载均衡模块，性能更好且支持更多调度算法。因此面试时如果被问到 ClusterIP 为什么 ping 不通，可以回答 ClusterIP 只对 TCP/UDP 流量做转发，ICMP 协议没有对应的规则。
CNI（容器网络接口）插件负责实际配置 Pod 网络，常见的 Flannel 使用 VXLAN 或 host-gw 实现跨节点通信，配置简单但功能相对基础；Calico 基于 BGP 路由协议交换路由信息，不依赖隧道，性能更好，并且支持网络策略。还有 Cilium 使用 eBPF 技术将网络转发下沉到内核，适合大规模集群。面试中回答 CNI 选型时，要综合网络规模、性能要求以及是否需要网络策略来展开，而不是简单说某个插件更好。
# 查看 CNI 配置文件路径 ls /etc/cni/net.d/ cat /etc/cni/net.d/10-flannel.conflist
上面这个文件内容通常是 JSON 格式，包含插件名称、子网配置和委托信息。实际面试中通常不会要求默写配置，但理解 CNI 插件如何被 kubelet 调用、如何为 Pod 分配 IP 并配置路由，是回答容器网络问题的重要加分项。综合来看，从网络命名空间到 CNI 插件，容器网络的知识链是层层递进的，答题时按照数据包的流转路径展开，会显得逻辑清晰且深入。
四、高频面试题答题模板与避坑指南
面试中容器网络问题通常会从容器间通信、跨主机通信、Service 工作原理三个维度切入。回答前两个问题时，先说明网络命名空间隔离，再讲 veth pair 接入网桥或路由，最后根据 Docker 或 Kubernetes 的具体模式补充细节。跨主机通信则要区分隧道方案和路由方案，隧道方案以 VXLAN 为代表，路由方案以 Calico BGP 为代表。
另一个常见误区是把 Docker 的 bridge 网络和 Kubernetes 的 Service 混为一谈。Docker 的 bridge 是单机二层网络，而 Kubernetes Service 是集群范围的负载均衡抽象，底层依赖 iptables 或 IPVS。答题时要结合具体上下文，避免使用模糊的虚拟网络说法。此外，面试官可能追问网络策略，这时可以提到 Kubernetes NetworkPolicy 资源需要 CNI 插件支持，Flannel 默认不开启，Calico 和 Cilium 则原生支持。
最后建议在面试前自己动手做一次实验：用 ip netns 和 veth pair 手动搭建一个容器网络，再用 docker network 和 kubectl 观察不同模式下的路由表与 iptables 规则。亲手操作过之后，很多原理类的题目会变得非常直观，回答时也能举出具体命令和输出，比纯理论更有说服力。
