3. K8s网络模型与CNI基础：Pod网络模型、Service与Endpoint、Ingress/Egress流量路径、常见CNI插件（Calico, Cilium）对比
3.1 Pod网络模型：IP-per-Pod 与扁平网络
Kubernetes 网络模型的核心原则是 IP-per-Pod：集群中每个 Pod 都拥有一个独立的、集群内可路由的 IP 地址，Pod 内的所有容器共享该 IP 和网络命名空间。这消除了端口分配冲突，简化了应用迁移。
- 扁平网络：所有 Pod 之间无需 NAT 即可直接通信，无论它们是否在同一节点。
- 通信约束：Pod 与 Pod、Pod 与 Node、Pod 与 Service 之间均通过原生 IP 直连。
- 网络命名空间：每个 Pod 拥有独立的 netns，通过 veth pair 连接到宿主机 cbr0/bridge 或 CNI 插件管理的虚拟交换机。
运维要点：IP-per-Pod 模型要求底层网络基础设施（VPC、路由表、Overlay 隧道）支持大规模 IP 分配与路由收敛，否则容易导致 IP 冲突或路由黑洞。
3.2 Service 与 Endpoint：抽象与负载均衡
Service 是 Kubernetes 中稳定的网络抽象层，为一组动态变化的 Pod 提供固定的虚拟 IP（ClusterIP）和 DNS 名称。其核心组件包括：
- ClusterIP：虚拟 IP，仅在集群内可达，通过 iptables/IPVS 规则实现负载均衡。
- Endpoints / EndpointSlice：记录 Service 背后所有就绪 Pod 的 IP:Port 列表，由 kube-controller-manager 自动维护。
- kube-proxy：在每个节点上运行，监听 API Server 的 Service/Endpoint 变化，更新本地转发规则。
| Service 类型 | 访问范围 | 实现机制 | 典型场景 |
|---|---|---|---|
| ClusterIP | 集群内部 | iptables / IPVS | 内部微服务调用 |
| NodePort | 集群外部（节点端口） | NodePort → ClusterIP | 开发调试、简单对外暴露 |
| LoadBalancer | 集群外部（云 LB） | 云控制器 + NodePort | 生产环境对外服务 |
| ExternalName | 集群内部（DNS CNAME） | CoreDNS 返回 CNAME | 对接外部数据库/中间件 |
性能对比：IPVS 模式相比 iptables 模式在大规模 Service（>1000）场景下具有更低的规则更新延迟和更高的吞吐量，推荐在生产集群中启用 IPVS 模式。
3.3 Ingress / Egress 流量路径
3.3.1 Ingress 入站流量路径
Ingress 是集群入口流量的管理对象，通常由 Ingress Controller（如 Nginx、Traefik、HAProxy）实现七层路由。典型流量路径如下：
- 外部请求 → DNS 解析到 Ingress Controller 的 LoadBalancer IP 或 NodePort。
- Ingress Controller 根据 Host/Path 规则匹配对应的 Service。
- Service 通过 ClusterIP 将请求转发到后端 Pod（kube-proxy 规则）。
- Pod 处理请求并返回响应。
3.3.2 Egress 出站流量路径
Pod 访问集群外部资源（如外部 API、数据库）时，流量路径涉及 SNAT 和网络策略：
- Pod → 外部 IP：默认通过节点 SNAT（MASQUERADE），源 IP 转换为节点 IP。
- Egress 网关：企业级场景中，通过 Egress Gateway（如 Cilium Egress Gateway、Calico Egress）将流量导向固定出口 IP，便于审计和防火墙白名单。
- NetworkPolicy：控制 Pod 的出站目标 CIDR 或 DNS 域名。
3.4 常见 CNI 插件对比：Calico vs Cilium
CNI（Container Network Interface）是 Kubernetes 网络插件的标准接口。当前生产环境最主流的两个 CNI 插件是 Calico 和 Cilium，它们在数据平面、安全策略和可观测性方面有显著差异。
| 对比维度 | Calico | Cilium |
|---|---|---|
| 数据平面 | Linux 内核路由 + iptables / eBPF（可选） | eBPF（原生，自研 BPF 数据路径） |
| 网络模式 | BGP（无 Overlay）、IPIP、VXLAN | VXLAN、Geneve、直接路由（eBPF） |
| 安全策略 | NetworkPolicy（iptables / eBPF） | NetworkPolicy + L7 HTTP/gRPC/DNS 策略 |
| 可观测性 | Felix 指标、Flow 日志（需额外组件） | Hubble（原生 eBPF 流量可视化 + 服务拓扑） |
| 性能 | BGP 模式接近原生，Overlay 模式有封装开销 | eBPF 模式低延迟、高吞吐，优于 iptables |
| 集群规模 | 支持 500+ 节点（BGP 路由需规划） | 支持 1000+ 节点（eBPF 无路由表膨胀问题） |
| 运维复杂度 | 中等（BGP 配置、Felix 调优） | 中等偏高（eBPF 内核版本依赖、调试工具链） |
| 生态集成 | 与云原生广泛兼容（Istio、Prometheus） | 与 eBPF 生态深度集成（Tetragon、KubeArmor） |
选型建议：如果团队对 eBPF 技术栈熟悉且内核版本 ≥ 5.10，优先选择 Cilium 以获得更好的性能、安全策略和可观测性；如果团队更倾向于传统路由方案或需要与现有 BGP 基础设施集成，Calico 是更成熟稳定的选择。
3.5 本章小结
- Kubernetes 网络模型基于 IP-per-Pod 和扁平网络，所有 Pod 可直接通信。
- Service 提供稳定的虚拟 IP 和负载均衡，EndpointSlice 管理后端 Pod 列表。
- Ingress 处理七层入站流量，Egress 流量需关注 SNAT 和出口 IP 管理。
- Calico 和 Cilium 是主流 CNI 插件，Cilium 在 eBPF 数据平面和可观测性方面更具优势，Calico 在传统路由场景中更成熟。