5.6 容器网络与 Kubernetes 原语

第 4 篇讲了包怎么从网卡进内核、怎么从 socket 发出去；这一章讲包的起点和终点被换掉了：容器有自己的网络栈，宿主要把 veth、bridge、路由、NAT 拼起来，才能让容器里的 eth0 看起来像一张真网卡。

容器网络没有专用内核模块。它复用的全是第 4 篇的零件：network namespace 提供独立的网卡/路由/端口空间，veth pair 像一根虚拟网线，bridge 像一台虚拟交换机，iptables/nftables 做 NAT 与 DNAT。Kubernetes 也没有发明新网络，它只是把这些零件按 Pod/Service 的语义组合起来，并约定 CNI 作为「插网线」的标准接口。

这一章先跟一个包从容器走到宿主，再手工搭一套最小网络，然后依次看端口映射、CNI、VXLAN、Service 与 NetworkPolicy。所有网络实验都在 root 下进行，清理命令会删掉 netns、veth、bridge 与 iptables 规则，请按顺序执行。

5.6.1 一个包从容器到宿主

先看 Docker 默认 bridge 网络的结构。容器里只有一张 eth0，它的对端是宿主上的一根 veth，插在 docker0 网桥上：

 container netns（172.17.0.2/16）
 ┌──────────────────────────────┐
 │ eth0 ──────┐                 │
 │ 默认路由 → 172.17.0.1        │
 └────────────┼─────────────────┘
              │ veth pair（一根虚拟网线）
 ┌────────────┼─────────────────┐
 │ vethXXXX   │                 │
 │      ┌─────▼──────┐          │
 │      │  docker0   │ 172.17.0.1/16
 │      └─────┬──────┘          │
 │            │                 │
 │      宿主路由表              │
 │            │                 │
 │      POSTROUTING MASQUERADE  │
 │            │                 │
 │         物理网卡 enp0s3      │
 └────────────┼─────────────────┘
              ▼
           外部网络

读这张图抓住三个「转换」：

1. L2 转换：容器把帧发给 eth0，veth 把帧原样送到宿主侧的 vethXXXX，后者挂在 docker0 上。bridge 根据 MAC 学习决定转发到哪个端口。
2. L3 转换：容器不知道宿主的存在，它按默认路由把包发给 172.17.0.1（docker0 的地址）。宿主打开 ip_forward 后按路由表转发。
3. NAT 转换：包从物理网卡出去前，POSTROUTING 链把源地址 172.17.0.2 改成宿主地址，同时 conntrack 记下映射；回包按 conntrack 反向改回 172.17.0.2。

容器与容器之间同网段通信不经过 NAT：bridge 直接按 MAC 转发。跨网段或出宿主才走路由 + MASQUERADE。

5.6.2 手工搭一套容器网络（root）

先不借助 Docker，用 ip 命令搭出「两个 netns + 一个 bridge + NAT」的最小网络。这样每一步都可验证，出问题也知道该看哪一层。

第一步：建 bridge 与两个 netns

# 需要 root
sudo ip netns add ns1
sudo ip netns add ns2
sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip addr add 10.20.0.1/24 dev br0

第二步：给每个 netns 接一根 veth

# 需要 root；ns1
sudo ip link add veth1 type veth peer name veth1-ns
sudo ip link set veth1 master br0
sudo ip link set veth1 up
sudo ip link set veth1-ns netns ns1
sudo ip -n ns1 addr add 10.20.0.11/24 dev veth1-ns
sudo ip -n ns1 link set veth1-ns up
sudo ip -n ns1 link set lo up
sudo ip -n ns1 route add default via 10.20.0.1

# ns2
sudo ip link add veth2 type veth peer name veth2-ns
sudo ip link set veth2 master br0
sudo ip link set veth2 up
sudo ip link set veth2-ns netns ns2
sudo ip -n ns2 addr add 10.20.0.12/24 dev veth2-ns
sudo ip -n ns2 link set veth2-ns up
sudo ip -n ns2 link set lo up
sudo ip -n ns2 route add default via 10.20.0.1

第三步：验证二层与三层连通

# bridge 已学到两个 MAC
sudo bridge fdb show br br0 | grep -E 'veth1|veth2'

# netns 之间互 ping
sudo ip netns exec ns1 ping -c 2 10.20.0.12

# 看 ns1 的路由与邻居表
sudo ip -n ns1 route
sudo ip -n ns1 neigh

这一步不需要 ip_forward：同一网段内，bridge 直接按 MAC 转发，包不经过宿主路由。ping 通说明 veth、bridge、IP 配置都对。

第四步：加 NAT 让 netns 访问外网

# 需要 root；开启转发并给 10.20.0.0/24 做源地址伪装
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -s 10.20.0.0/24 ! -o br0 -j MASQUERADE

# 如果有外网，验证；没有就跳过
sudo ip netns exec ns1 ping -c 2 1.1.1.1

! -o br0 的作用是「从非 br0 接口出去的包才伪装」；如果不加，netns 互访的包也会被 MASQUERADE，虽然能通，但抓包时看不到原始源地址，排障会变难。

第五步：清理

# 先删规则，再删 netns（veth 会随 netns 一起消失）
sudo iptables -t nat -D POSTROUTING -s 10.20.0.0/24 ! -o br0 -j MASQUERADE
sudo ip netns del ns1
sudo ip netns del ns2
sudo ip link del br0

删除 netns 时，里面的 veth 端会被销毁，宿主侧的 peer 也会自动消失；br0 需要单独删。清理后用 ip netns list 与 ip link show type bridge 确认没有残留。

5.6.3 端口映射：DNAT、docker-proxy 与 hairpin

docker run -p 8080:80 让宿主 8080 的流量进容器 80。它不是「开一个端口转发进程」这么简单：主流路径是 iptables/nftables 的 DNAT，docker-proxy 只在少数场景兜底。

# 不需要 root（用户在 docker 组）
docker run -d --name web -p 8080:80 nginx:alpine
docker port web
# 80/tcp -> 0.0.0.0:8080

# 需要 root：看 nat 表的 DOCKER 链
sudo iptables -t nat -L DOCKER -n -v
# DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80

# 看是否有 docker-proxy 进程
ps -ef | grep docker-proxy | grep -v grep

docker rm -f web

DNAT 发生在 PREROUTING（外部流量）与 OUTPUT（本机流量）之后进入 DOCKER 链。包到达宿主 8080 时，目标地址被改写成 172.17.0.2:80，然后按容器网段路由到 docker0。回包时 conntrack 做反向转换，源地址看起来仍是宿主 8080。

三个容易混淆的点：

• docker-proxy 不是必须的。它处理「本机访问 127.0.0.1:8080」以及某些 hairpin 场景；纯 DNAT 对来自外部的流量已经够用。可以用 --userland-proxy=false 关掉，观察行为差异。
• hairpin NAT：容器自己访问「宿主 IP:8080」时，包从容器出发又回到同一 bridge，DNAT 后目标变成自己或同网段容器。某些配置需要额外 MASQUERADE 才能让回包走对路径；Docker 通过规则与 proxy 组合处理。
• Ubuntu 24.04 的 iptables 是 nft 后端。iptables 命令仍然可用，但底层是 nf_tables；iptables-legacy 与 iptables-nft 的规则不在同一处，排障时先 iptables --version 确认后端。

5.6.4 CNI：插件、配置与调用约定

CNI（Container Network Interface）不是守护进程，也不是网卡驱动，而是一份调用约定：容器运行时在创建/删除 Pod 网络时，执行 /opt/cni/bin 下的插件二进制，通过环境变量与 stdin 传参，插件返回 JSON 结果。

调用时最关键的环境变量：

插件从 stdin 读网络配置，向 stdout 写结果。一个 conflist 可以串联多个插件：第一个负责建网卡与分配 IP，后面的负责端口映射、带宽、防火墙。

{
  "cniVersion": "1.0.0",
  "name": "mynet",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": true,
      "ipam": {
        "type": "host-local",
        "ranges": [[{ "subnet": "10.244.0.0/24" }]]
      }
    },
    {
      "type": "portmap",
      "capabilities": { "portMappings": true }
    }
  ]
}

这段配置的含义是：创建 cni0 网桥，给容器接 veth 并从 10.244.0.0/24 分配 IP，开启 SNAT；再用 portmap 支持 hostPort。实际集群里，Calico、Cilium、Flannel 会用自己的插件替换 bridge，但调用约定相同。

在节点上观察 CNI 的落点：

# 需要 root 或对应读权限
ls /opt/cni/bin
cat /etc/cni/net.d/*.conflist

# kubelet 通过 CRI 调用运行时，运行时再调 CNI；看 Pod 的 sandbox
sudo crictl pods
sudo crictl inspectp "$(sudo crictl pods -q | head -1)" | jq '.status.network'

crictl inspectp 的输出里能看到 Pod 的 network namespace 路径与 IP。这个 netns 由 pause 容器持有；Pod 里的业务容器通过 setns 共享它（5.6.7 展开）。

5.6.5 overlay 网络：VXLAN 与跨主机

单机 bridge 只能让同一宿主的容器互通。跨主机时，要么让底层网络知道 Pod 网段（路由/BGP），要么把二层帧封装进 UDP 里传（overlay）。VXLAN 是后者最常见的形式。

# 需要 root；在两台宿主上各建一个 VXLAN 设备（VNI 必须一致）
sudo ip link add vxlan0 type vxlan id 42 dev enp0s3 dstport 4789
sudo ip addr add 10.244.1.0/24 dev vxlan0
sudo ip link set vxlan0 up
sudo ip link set vxlan0 mtu 1450

# 添加远端 VTEP：目标宿主的外网 IP
sudo bridge fdb append 00:00:00:00:00:00 dev vxlan0 dst 192.168.1.12

# 查看封装参数
ip -d link show vxlan0

四个要点：

1. VNI（VXLAN Network Identifier）是 24 位租户标识，两端必须一致；不一致时包能到但对端解不出正确的网络。
2. dstport 4789 是 IANA 分配的 VXLAN 端口；有些实现用 8472（Flannel 旧默认），两端必须匹配。
3. MTU 要减 50 字节（外层 IP 20 + UDP 8 + VXLAN 8 + 内层以太网 14）。物理 MTU 1500 时，容器网卡通常设 1450，否则大包会被分片或丢弃，表现为「小包能通、大文件传输卡住」。
4. underlay 必须能路由到对端 VTEP。VXLAN 不解决底层连通性；它只是把二层帧塞进 UDP。

跨主机方案的对照：

5.6.6 Service：ClusterIP 是一次 DNAT

Kubernetes 的 Service 给一组 Pod 一个稳定虚拟 IP（ClusterIP）。这个 IP 不属于任何网卡，ping 它可能不通；它的作用是让 kube-proxy 在包路径上装一条 DNAT 规则，把「访问 VIP:port」改写成「访问某个 PodIP:port」。

# 只作观测；需要可用的集群与 kubeconfig
kubectl create deployment web --image=nginx:alpine --replicas=2
kubectl expose deployment web --port=80 --target-port=80
kubectl get svc web
kubectl get endpointslices -l kubernetes.io/service-name=web

# 需要节点 root：看 kube-proxy 装的 nat 规则
sudo iptables -t nat -L KUBE-SERVICES -n | grep web
sudo iptables -t nat -L KUBE-SVC-XXXXXXXX -n -v
sudo iptables -t nat -L KUBE-SEP-YYYYYYYY -n -v

规则的组织方式（iptables 模式）：

KUBE-SERVICES
  └─ 匹配 ClusterIP:port → 跳 KUBE-SVC-<hash>
       ├─ 1/2 概率 → KUBE-SEP-<pod1>
       └─ 其余     → KUBE-SEP-<pod2>
            └─ DNAT --to-destination <podIP>:<targetPort>

KUBE-SVC-* 用 statistic --mode random 在多个 endpoint 之间做选择，KUBE-SEP-* 执行 DNAT。选择发生在每条新连接上；同一条连接后续的包由 conntrack 固定到同一个 Pod，所以不会「一个请求里一半包去 A、一半去 B」。sessionAffinity: ClientIP 则是让 conntrack 按源 IP 保持更久。

不同模式的差别：

Service 的几种类型只是在同一套 DNAT 上多加一层：

• ClusterIP：集群内 VIP，kube-proxy 装 DNAT。
• NodePort：在每个节点开一个端口，KUBE-NODEPORTS 链把 nodeIP:nodePort DNAT 到 Pod。
• LoadBalancer：云厂商分配外部 LB，转发到 NodePort 或 Pod。
• Headless（clusterIP: None）：不分配 VIP，DNS 直接返回 Pod IP，客户端自己做负载均衡；kube-proxy 不装规则。
• ExternalName：CNAME 到外部域名，没有 DNAT。

5.6.7 Pod、Service、Node 与 Linux 原语的映射

Kubernetes 的每个概念都能在 Linux 里找到落点。把这张表记住，排障时就不会在「YAML 层」打转：

Pod 的网络共享方式值得单独说：kubelet 先让运行时创建 sandbox（pause 容器），由 CNI 给 sandbox 的 netns 配好 eth0 与 IP；然后业务容器以 linux.namespaces 里 path: /proc/<sandbox-pid>/ns/net 的方式加入同一个 netns。所以同一个 Pod 里的容器共享 localhost 与端口空间，但各自有独立的 mount namespace 与 rootfs。

# 需要节点 root；观察 Pod 的 sandbox 与业务容器
SANDBOX=sandbox-id CONTAINER=container-id SPID=sandbox-pid   # 换成 crictl 输出里的实际值
sudo crictl pods
sudo crictl ps
sudo crictl inspectp "$SANDBOX" | jq '.status.network'
sudo crictl inspect "$CONTAINER" | jq '.info.runtimeSpec.linux.namespaces'

# 进入 Pod 网络命名空间抓包
sudo nsenter -t "$SPID" -n ip -brief addr
sudo nsenter -t "$SPID" -n tcpdump -i any -nn -c 5

crictl inspect 的 runtimeSpec 就是 OCI config.json 的运行时展开版；你能在里面看到 linux.namespaces、process.capabilities、linux.seccomp。第 5.5 节学的字段，在这里原样出现。

5.6.8 NetworkPolicy 与包过滤

NetworkPolicy 是 Kubernetes 的 L3/L4 防火墙抽象。它的语义是追加允许：只要有一个策略选中了 Pod，该 Pod 的对应方向就变成默认拒绝，然后逐条匹配允许规则。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: demo
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: demo
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

第一条把 demo 里所有 Pod 的入站与出站都设为默认拒绝；第二条只放行到 kube-system 的 UDP 53（DNS）。两条策略叠加后，Pod 只能发 DNS，其他出站与所有入站都被拒绝。

实现方式取决于 CNI：

# 只作观测
kubectl get networkpolicy -n demo
kubectl describe networkpolicy default-deny -n demo
kubectl get pods -n demo --show-labels

排障时先确认「策略是否被 CNI 实现」：kubectl describe 能看到对象，但不代表数据面有规则。到节点上看 iptables/eBPF map，或看 CNI 的日志，才能确认。

5.6.9 veth 与 bridge 的内核路径

这一节回答：一个帧从容器 eth0 发出来后，在内核里经过哪些函数、在哪些结构体上被转发或丢弃。

veth 不是「一根线」，而是一对 net_device，各自属于一个网络命名空间。发送方的 ndo_start_xmit 是 veth_xmit()，它取出 peer，把 skb 交给 veth_forward_skb()，最终用 netif_rx() 或 dev_forward_skb() 注入对端网络栈。整个过程不复制数据，只转移 skb 的所有权。

bridge 是一个软件交换机：br_handle_frame() 在入口处理帧，br_fdb_update() 学习源 MAC，br_forward() 按目的 MAC 查 FDB 并从对应端口发出；查不到就 br_flood() 泛洪。FDB 表项有老化时间，默认 300 秒，由 br_fdb_cleanup() 周期清理。

container eth0（veth1-ns）
  │ dev_queue_xmit
  ▼
veth_xmit() → veth_forward_skb() → netif_rx()
  │ 对端 veth1 在宿主 netns
  ▼
__netif_receive_skb_core() → br_handle_frame()
  │ br_fdb_update() 学源 MAC
  │ br_forward() 查目的 MAC
  ▼
veth2（去 ns2）或宿主路由（去外部）

内核里与这条路径相关的结构体：

对应的内核文件：

观测这套路径不需要抓包器，先看计数器：

# 需要 root；veth 的收发/丢包计数
ip -s link show veth1
ethtool -S veth1 2>/dev/null | head -20

# bridge 的端口状态与 FDB
bridge link show br0
bridge fdb show br br0 | head
bridge -s fdb show br br0 | head     # 带命中计数

# 内核丢包原因（需要 root）
nstat -az | grep -Ei 'drop|no_route|noroute' | head

bridge fdb show 里的 self 表示 bridge 自身的 FDB，master br0 表示学习到的端口项；permanent 是静态项，dynamic 会老化。看到 00:00:00:00:00:00 的项不要惊讶，那是 VXLAN 的默认远端项或未学习时的占位。

用 bpftrace 看一次 ping 走了哪些函数：

# 需要 root；另一个终端在 ns1 里 ping ns2
sudo bpftrace -e '
kprobe:veth_xmit      { @veth[comm] = count(); }
kprobe:br_handle_frame { @br[comm] = count(); }
kprobe:br_fdb_update  { @fdb[comm] = count(); }
interval:s:5          { exit(); }'

如果 veth_xmit 的计数为 0 而 br_handle_frame 有值，说明帧没有从容器发出来（可能是容器内路由/网卡 down）；两者都为零，检查 ip link 与 netns 是否正确。

veth 的 offload 也会影响行为。ethtool -k veth1 里 tx-checksumming、tso、gso 默认开着，抓包时看到的可能是「未校验和的大包」；用 tcpdump -i veth1 -vv 看 bad cksum 不代表链路有问题，而是校验和卸载到对端才计算。排查 MTU 时先 ip link show 看 mtu，再用 ping -M do -s 验证。

5.6.10 CNI 协议深挖与实验一

这一节回答：CNI 插件被调用时到底收到什么、返回什么，以及如何不经过 Kubernetes 手工跑一次 ADD。

CNI 的协议只有「环境变量 + stdin + stdout + 退出码」四件事：

一个 conflist 的每个插件都会被依次执行，前一个插件的输出会作为后一个的输入（通过 prevResult）。ADD 从第一个插件跑到最后一个；DEL 逆序执行；CHECK 与 ADD 同序、逐层校验 prevResult。主插件（bridge、macvlan、ipvlan、ptp）负责建网卡，IPAM 插件（host-local、dhcp、static）负责分配地址，meta 插件（portmap、bandwidth、tuning、firewall）负责附加能力。

host-local 的租约存在 dataDir（默认 /var/lib/cni/networks/<network>）下，每个 IP 一个文件，内容是第一行容器 ID、第二行 IFNAME。这解释了两种常见故障：容器被强杀后租约没释放，新 Pod 可能拿到同一个 IP；DEL 时找不到租约，插件报 failed to delete IP。清理时要同时删租约文件与 netns。

下面的实验直接调用 bridge + host-local，不经过 Docker 或 Kubernetes。需要 root、ip 命令与 CNI 插件（Ubuntu 包 containernetworking-plugins 提供 /opt/cni/bin）。

#!/usr/bin/env bash
# cni-lab.sh — 手工执行 CNI ADD/DEL，验证网卡、IP 与租约
set -euo pipefail
[[ ${EUID:-$(id -u)} -eq 0 ]] || { echo "需要 root"; exit 1; }
CNI_BIN=${CNI_BIN:-/opt/cni/bin}
[[ -x "$CNI_BIN/bridge" && -x "$CNI_BIN/host-local" ]] || {
    echo "缺少 CNI 插件：$CNI_BIN/{bridge,host-local}"; exit 1; }

NS=cni-lab
BR=cni-br0
CID=lab-$$
D=/tmp/cni-lab
cleanup() {
    ip netns del "$NS" 2>/dev/null || true
    ip link del "$BR" 2>/dev/null || true
    rm -rf "$D"
}
trap cleanup EXIT

mkdir -p "$D/ipam"
ip netns add "$NS"
ip netns exec "$NS" ip link set lo up

cat > "$D/netconf.json" <<'JSON'
{
  "cniVersion": "1.0.0",
  "name": "cni-lab",
  "type": "bridge",
  "bridge": "cni-br0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "dataDir": "/tmp/cni-lab/ipam",
    "ranges": [[{ "subnet": "10.88.0.0/24" }]]
  }
}
JSON

export CNI_CONTAINERID="$CID" CNI_NETNS="/var/run/netns/$NS" \
       CNI_IFNAME=eth0 CNI_PATH="$CNI_BIN"

CNI_COMMAND=ADD "$CNI_BIN/bridge" < "$D/netconf.json" > "$D/result.json"
jq '{cniVersion, interfaces, ips, routes}' "$D/result.json"

addr=$(jq -r '.ips[0].address' "$D/result.json")
echo "[ok] 分配地址：$addr"
ip netns exec "$NS" ip -brief addr show eth0
ip netns exec "$NS" ping -c 2 -W 1 10.88.0.1
cat "$D/ipam/cni-lab/"* 2>/dev/null || true

CNI_COMMAND=DEL "$CNI_BIN/bridge" < "$D/netconf.json" > /dev/null
ip netns exec "$NS" ip link show eth0 2>&1 || echo "[ok] eth0 已删除"

预期结果：result.json 的 ips[0].address 是 10.88.0.2/24 之类的地址，interfaces 里同时有宿主侧 vethXXX 与容器侧 eth0；ping 10.88.0.1 通；租约目录里出现以 IP 命名的文件；DEL 后容器里的 eth0 消失。如果 bridge 报 failed to set bridge addr，说明 cni-br0 已存在且地址冲突，先 ip link del cni-br0。

注意 CNI_NETNS 用的是 /var/run/netns/cni-lab，这是 ip netns add 创建的 bind mount 路径；用 /proc/<pid>/ns/net 也可以，但要求进程存活。DEL 必须传与 ADD 相同的 CNI_CONTAINERID 与配置，否则插件找不到缓存，可能留下网卡。

5.6.11 Service 数据面：iptables、IPVS 与 eBPF

这一节回答：KUBE-SVC/KUBE-SEP 这些链具体怎么排、IPVS 模式差在哪、eBPF 又替换了哪一层。

iptables 模式下，kube-proxy 在 nat 表里维护一棵四层链：

一条真实规则的样子（注释与 hash 因集群而异）：

-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "default/kubernetes:https" -m tcp --dport 443 -j KUBE-SVC-XXXX
-A KUBE-SVC-XXXX -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-AAAA
-A KUBE-SVC-XXXX -j KUBE-SEP-BBBB
-A KUBE-SEP-AAAA -s 10.244.1.5/32 -p tcp -m tcp --dport 6443 -j KUBE-MARK-MASQ
-A KUBE-SEP-AAAA -p tcp -m tcp --dport 6443 -j DNAT --to-destination 10.244.1.5:6443

statistic 只作用于新连接：nat 表只对连接的第一个包做 DNAT，后续包由 conntrack 固定到同一 endpoint。最后一个 endpoint 不再写概率，直接跳转，保证所有流量都有归宿；没有 endpoint 时规则改成 REJECT --reject-with icmp-port-unreachable。

IPVS 模式把「按概率跳转」换成内核的 IPVS 哈希表：

# 需要节点 root；IPVS 模式才有 kube-ipvs0
ip addr show kube-ipvs0 | head
sudo ipvsadm -Ln
# TCP  10.96.0.10:443 rr
#   -> 10.244.1.5:6443            Masq    1      0          0
#   -> 10.244.2.7:6443            Masq    1      0          0
sudo ipvsadm -Ln --stats

kube-ipvs0 是一张 dummy 网卡，kube-proxy 把每个 ClusterIP 都挂上去，让本机路由认为 VIP 是本地地址；真正的转发由 IPVS 完成。IPVS 支持 rr、wrr、lc、wlc、sh 等调度器，kube-proxy 默认 rr，可用 --ipvs-scheduler 改。IPVS 模式仍然需要 iptables 做 masquerade、NodePort 的某些路径与防火墙兜底，所以看到 KUBE-* 链不要以为模式没生效。

三种数据面的对照：

eBPF 不是「更快的 iptables」，而是把 hook 点前移：Cilium 在 tc/XDP 处理包，在 socket connect/sendmsg 时就能决定后端，绕过 netfilter 与 conntrack。它用 identity（标签）而不是 IP 做策略，Pod 重建换 IP 不影响策略；代价是内核依赖更强、抓包位置更靠前、排障要熟悉 BPF map。

#!/usr/bin/env bash
# svc-dnat-lab.sh — 在 netns 里复现 ClusterIP 的 DNAT
set -euo pipefail
[[ ${EUID:-$(id -u)} -eq 0 ]] || { echo "需要 root"; exit 1; }
for c in ip iptables python3 curl; do
    command -v "$c" >/dev/null || { echo "缺少 $c"; exit 1; }
done

BR=svc-br0
cleanup() {
    [[ -n ${SRV_PID:-} ]] && kill "$SRV_PID" 2>/dev/null || true
    ip netns del cli 2>/dev/null || true
    ip netns del srv 2>/dev/null || true
    ip link del "$BR" 2>/dev/null || true
}
trap cleanup EXIT

ip netns add cli
ip netns add srv
ip link add "$BR" type bridge
ip link set "$BR" up
ip addr add 10.99.0.1/24 dev "$BR"

for pair in "cli 10.99.0.11" "srv 10.99.0.2"; do
    set -- $pair
    ns=$1; ip4=$2
    ip link add "veth-$ns" type veth peer name "veth-$ns-ns"
    ip link set "veth-$ns" master "$BR"
    ip link set "veth-$ns" up
    ip link set "veth-$ns-ns" netns "$ns"
    ip -n "$ns" addr add "$ip4/24" dev "veth-$ns-ns"
    ip -n "$ns" link set "veth-$ns-ns" up
    ip -n "$ns" link set lo up
    ip -n "$ns" route add default via 10.99.0.1
done

# 后端：8080 上的 HTTP 服务
ip netns exec srv python3 -m http.server 8080 --bind 0.0.0.0 >/dev/null 2>&1 &
SRV_PID=$!
sleep 1

# 客户端：VIP 挂在 lo 上（等价于 kube-ipvs0 的作用），OUTPUT 链做 DNAT
ip -n cli addr add 10.99.0.100/32 dev lo
ip netns exec cli iptables -t nat -A OUTPUT \
    -d 10.99.0.100/32 -p tcp --dport 80 \
    -j DNAT --to-destination 10.99.0.2:8080

code=$(ip netns exec cli curl -s --noproxy '*' -o /dev/null -w '%{http_code}' --max-time 5 \
    http://10.99.0.100:80/)
echo "HTTP code via VIP: $code"
[[ "$code" == 200 ]] || { echo "DNAT 未生效"; exit 1; }

ip netns exec cli iptables -t nat -L OUTPUT -n -v
ip netns exec cli conntrack -L 2>/dev/null | grep 8080 || true

预期输出 HTTP code via VIP: 200，iptables -t nat -L OUTPUT -v 的 DNAT 规则计数增加；如果装了 conntrack-tools，还能看到 10.99.0.100:80 被映射到 10.99.0.2:8080 的连接。这个实验与 kube-proxy 的差别只在「规则由谁维护」：kube-proxy 监听 Service/EndpointSlice 变化，自动增删同样的 DNAT 规则。

5.6.12 Pod、Namespace 与 NetworkPolicy 的语义细节

这一节回答：Kubernetes 的 Namespace 与 Linux namespace 到底怎么区分，Pod 共享哪些命名空间，NetworkPolicy 的「或/与」怎么写。

先彻底分开两个同名概念：

一个 K8s Namespace 下的 Pod 可以分布在任意节点、任意 Linux netns 里；反过来，同一个 Linux netns 里的容器可以属于不同的 K8s Namespace（只要调度到同一 Pod）。排障时不要把 kubectl get ns 的输出当成内核 namespace 列表。

Pod 的共享关系由 sandbox 决定：

hostNetwork 的 Pod 没有独立 IP，kubectl get pod -o wide 显示的是节点 IP；它的 dnsPolicy 通常要设成 ClusterFirstWithHostNet，否则 DNS 解析走宿主配置。shareProcessNamespace 下，业务容器的 /proc/1 是 pause，不是自己的主进程；依赖「自己是 PID 1」做信号处理的应用会受影响。

NetworkPolicy 的匹配规则只有三条，但组合起来容易写错：

策略是追加允许：只要有一个策略选中 Pod 的某个方向，该方向先默认拒绝，再按所有策略的允许规则取并集。没有策略选中时默认全放行。策略没有顺序，也没有 deny 规则；想「只拒绝某个 IP」只能「默认拒绝 + 放行其余」，不能写一条单独的拒绝。

一个常见的漏配：加了 default-deny egress 后忘了放行 DNS，Pod 里所有域名解析都超时。DNS 的出站规则要同时放行 UDP 53 与 TCP 53（大响应会走 TCP），目标可以是 kube-system 的 namespaceSelector，也可以写 CoreDNS 的 Pod 标签。

实现层面对照：

eBPF 的 hook 点决定了它能看到什么：

Cilium 的 kube-proxy replacement 就是在 socket connect 时直接选后端，包还没进 netfilter 就已经决定去向；这让它在大规模 Service 下避免 iptables 的线性遍历。代价是它依赖较新的内核与 BPF 特性，排障要会看 cilium bpf lb list、cilium monitor，而不是 iptables -L。

5.6.13 四个让包静默消失的开关：rp_filter、br_netfilter、conntrack、MTU

Pod 里 ping 得通自己、却连不上 Service；同节点两个 Pod 互相访问正常，跨节点就超时。这类问题经常不是 CNI 配错，而是四个内核开关按默认值工作。它们的共同点是不报错、只计数，所以必须先知道去哪看。

rp_filter 的三个值要分清：0 不检查；1 严格模式，回包必须从「去程使用的同一网卡」进来；2 宽松模式，只要求源地址在任意网卡上可达。容器节点常有多张网卡、VXLAN 设备与策略路由，严格模式会把合法的非对称回包丢掉。内核在 fib_validate_source() 里用 IN_DEV_RPFILTER() 取当前值，失败返回 -EINVAL，上层把它记成输入错误，不发 ICMP。

br_netfilter 是另一类陷阱：Linux bridge 默认是纯二层转发，帧不经过 IPv4 的 FORWARD 链。只有加载 br_netfilter 并把 bridge-nf-call-iptables 设为 1，桥接帧才会被送进 netfilter。Kubernetes 的 NetworkPolicy 实现（Calico、Cilium 的 iptables 模式）依赖这一点；如果 kubelet 的 sysctl 没生效，策略看起来「装了但不拦」。

内核路径：一个转发包经过的钩子

ip_rcv()                              net/ipv4/ip_input.c
  → NF_INET_PRE_ROUTING
      → nf_conntrack_in()             net/netfilter/nf_conntrack_core.c
  → ip_rcv_finish() → ip_route_input_noref()   net/ipv4/route.c
      → fib_validate_source()         net/ipv4/fib_frontend.c   ← rp_filter
  → ip_forward()                      net/ipv4/ip_forward.c
      → NF_INET_FORWARD               ← iptables FORWARD / NetworkPolicy
  → ip_output() → NF_INET_POST_ROUTING
      → nf_conntrack_confirm()        ← 只有确认后才进入 conntrack 表

bridge 路径：
br_handle_frame()                     net/bridge/br_input.c
  → br_pass_frame_up() / br_forward()
      →（br_netfilter 加载且 bridge-nf-call-iptables=1）
        br_nf_pre_routing() → ip_rcv() → 上面的 IPv4 钩子

VXLAN 封装：
vxlan_xmit()                          drivers/net/vxlan/vxlan_core.c
  → vxlan_build_skb() → udp_tunnel_xmit_skb()   （外层 +50 字节）

这张路径图解释了三个现象：rp_filter 在路由决策里执行，所以策略路由和多网卡会让它误判；FORWARD 只在路由转发时经过，纯二层桥接必须靠 br_netfilter 才进得来；conntrack 在 PRE_ROUTING 建表项、在 POST_ROUTING 确认，NAT 只在第一个包上做，后续包靠表项命中。

实验一：br_netfilter 决定 FORWARD 链是否管桥接流量

需要 root、iptables、conntrack 与 br_netfilter 模块。两个 netns 接在同一 bridge 上，用一条 FORWARD DROP 规则观察它是否生效。

ip netns add n1; ip netns add n2
ip link add br0 type bridge; ip link set br0 up
ip link add v1 type veth peer name v1b; ip link set v1 netns n1
ip link add v2 type veth peer name v2b; ip link set v2 netns n2
ip link set v1b master br0; ip link set v2b master br0
ip link set v1b up; ip link set v2b up
ip addr add 10.20.0.1/24 dev br0
ip -n n1 addr add 10.20.0.2/24 dev v1; ip -n n1 link set v1 up
ip -n n2 addr add 10.20.0.3/24 dev v2; ip -n n2 link set v2 up

ip netns exec n1 ping -c1 -W1 10.20.0.3
# 1 packets transmitted, 1 received

modprobe br_netfilter
sysctl -qw net.bridge.bridge-nf-call-iptables=0
iptables -A FORWARD -s 10.20.0.2 -d 10.20.0.3 -j DROP
ip netns exec n1 ping -c1 -W1 10.20.0.3
# 仍然 1 received：纯二层转发不经过 FORWARD

sysctl -qw net.bridge.bridge-nf-call-iptables=1
ip netns exec n1 ping -c1 -W1 10.20.0.3
# 100% packet loss：桥接帧进入 IPv4 钩子，被 FORWARD DROP
conntrack -L 2>/dev/null | grep -c '10.20.0' || true

iptables -D FORWARD -s 10.20.0.2 -d 10.20.0.3 -j DROP
ip netns del n1; ip netns del n2; ip link del br0

三行 ping 输出就是证据链：bridge-nf-call-iptables=0 时规则「存在但不生效」，改成 1 后立刻丢包。这就是为什么 kube-proxy/CNI 的 DaemonSet 要在启动时 modprobe br_netfilter 并写这两个 sysctl；漏掉时 NetworkPolicy 只在跨节点路由的流量上生效，同节点 Pod 之间照常互通。

实验二：MTU 与 -M do 的边界

# 仍在实验一的 netns/网卡上（或重建）
ip -n n1 link set v1 mtu 1400
ip netns exec n1 ping -M do -s 1372 -c1 10.20.0.3   # 1400-20-8=1372，成功
ip netns exec n1 ping -M do -s 1373 -c1 10.20.0.3
# ping: local error: message too long, mtu=1400
ip netns exec n1 ping -c1 -s 1400 10.20.0.3         # 允许分片，仍可能通

-M do 设置 DF 位，让内核在超过 MTU 时直接 EMSGSIZE，而不是分片。VXLAN 场景把 v1 换成 vxlan0 即可复现 overlay MTU 1450：underlay 1500 减去外层 IP(20)+UDP(8)+VXLAN(8)+内层以太网(14)=50 字节。Calico 的 IPIP 是 20 字节，overlay MTU 1480；Geneve 通常 50 字节。MTU 配错时，ping -s 56 永远正常，只有大包或 TLS 握手卡住——这是最难查的一类「网络慢」。

5.6.14 排障顺序与 12 条陷阱

容器网络排障最容易犯的错是「一上来就抓包」。按层往下走，通常三步就能定位：

# 一组常用观测命令（部分需要 root）
ip -brief addr
ip route get 10.244.1.5
sudo conntrack -L | grep 8080
sudo tcpdump -i any -nn -c 20 'port 8080'
sudo iptables -t nat -L -n -v | head -40
sudo bridge fdb show | head

第 8 条与第 7 条经常一起出现：Pod 被 SIGKILL 后 netns 立即消失，CNI 的 DEL 来不及执行，IPAM 租约留在磁盘上；下一次调度可能复用同一个 IP，而旧租约还指向已删除的容器。生产上要给 CNI 配 GC，或定期清理孤儿租约。

5.6.15 本章出口检查

母本对应

下一站：第 5 篇到此结束。你已经把「隔离、限额、镜像、运行时、网络」串成一条链。接下来去项目 A · 云原生主线：用 mycontainer 从零实现一个迷你运行时，把这六章的命令变成代码。