3. K8s 网络模型基础：Pod 网络、CNI 插件与 Service 原理
Kubernetes 网络模型是集群内所有通信的基石。它不依赖底层物理网络，而是通过一套严格的抽象规则，确保 Pod、节点和 Service 之间能够透明、高效地通信。理解 Pod 网络、CNI 插件以及 kube-proxy 的工作原理，是部署 eBPF 网络观测方案的前提。
3.1 Pod 网络：IP-per-Pod 模型
Kubernetes 为每个 Pod 分配一个唯一的集群内 IP 地址，且该 IP 在 Pod 生命周期内保持不变。这个模型被称为 IP-per-Pod，它消除了端口分配冲突，简化了应用设计。
核心原则：
- Pod 内的所有容器共享同一个网络命名空间（Network Namespace），包括 IP 地址、端口和网络栈。
- Pod 之间可以直接通过 IP 地址通信，无需 NAT 转换。
- 节点上的 Pod 与节点自身的网络是隔离的，但通过虚拟网卡（veth pair）和网桥（Bridge）连接。
下图展示了单个节点上 Pod 网络的典型拓扑结构：
关键洞察： eBPF 程序可以挂载在 veth 对、网桥或路由表上，实现对 Pod 网络流量的零侵入观测。例如，通过
tc (traffic control) 或 XDP 钩子，可以捕获 Pod 发出的每一个数据包。
3.2 CNI 插件：Calico / Flannel / Cilium
容器网络接口（CNI）是 Kubernetes 与网络实现之间的标准协议。CNI 插件负责为 Pod 分配 IP 地址、配置网络接口和路由规则。不同的 CNI 插件在性能、安全性和功能上差异显著。
| 特性 | Flannel | Calico | Cilium |
|---|---|---|---|
| 数据平面 | VXLAN / Host-GW / UDP | BGP (路由) / VXLAN / IPIP | eBPF (XDP / TC) |
| 网络策略 | 不支持原生策略 | 支持 (iptables / eBPF) | 支持 (eBPF 原生) |
| 性能 | 中等 (封装开销) | 高 (纯路由模式) | 极高 (eBPF 内核态转发) |
| 可观测性 | 基础 (依赖外部工具) | 中等 (FlowLogs / 策略审计) | 原生 (Hubble / 7层可观测) |
| 适用场景 | 小型集群、快速部署 | 中大型集群、安全合规 | 高性能、云原生网络、eBPF 观测 |
选型建议： 对于本课程关注的 eBPF 网络观测，Cilium 是最佳选择。它原生支持 eBPF，无需 iptables 即可实现 Service 转发和网络策略，并且内置 Hubble 观测平台。Calico 也支持 eBPF 数据平面，但功能集成度不如 Cilium。
3.3 Service 与 kube-proxy 原理
Service 是 Kubernetes 中用于暴露一组 Pod 的抽象。它提供了一个稳定的虚拟 IP（ClusterIP）和 DNS 名称，客户端无需关心后端 Pod 的 IP 变化。kube-proxy 是负责实现 Service 功能的组件，它运行在每个节点上，监听 API Server 中 Service 和 Endpoint 的变化，并更新节点的网络规则。
kube-proxy 支持三种代理模式：
- Userspace 模式（已弃用）： 在用户态代理，性能差，仅用于早期版本。
- iptables 模式（默认）： 利用 Linux 内核的 iptables 规则实现 DNAT 和负载均衡。规则数量随 Pod 规模线性增长，更新时存在延迟。
- IPVS 模式： 利用内核的 IP Virtual Server 模块，使用哈希表实现高效转发，支持更多负载均衡算法（如 wrr、lc）。
下图对比了 iptables 和 eBPF（Cilium）两种 Service 转发路径：
性能对比：
- iptables： 规则链遍历 O(n)，更新时全量刷新，大规模集群下延迟抖动明显。
- IPVS： 哈希查找 O(1)，更新效率高，但依赖内核模块，且缺乏 7 层能力。
- eBPF： 在套接字层或 XDP 层直接处理，绕过 iptables 链，延迟最低，且支持 7 层协议解析（如 HTTP/gRPC）。
理解这些底层机制后，eBPF 观测工具（如 Cilium Hubble）可以精确捕获 Service 到 Pod 的流量路径，识别丢包、延迟和连接异常，而无需修改应用代码或重启 Pod。