2. Kubernetes 网络模型精讲：Pod网络、Service网络、Ingress网络、CNI插件原理

Kubernetes 网络模型是 Serverless 集群的通信基石。本章深入剖析 Pod 网络、Service 网络、Ingress 网络三层模型，并详解 Calico 与 Flannel 两种主流 CNI 插件的实现原理与性能差异。

2.1 Kubernetes 网络模型核心原则

Kubernetes 对集群网络提出了四个必须满足的约束，所有 CNI 插件都必须遵循：

  • Pod 间直接通信：任意 Pod 之间无需 NAT 即可通过 IP 地址直接通信。
  • Node 与 Pod 直接通信：节点上的 kubelet 可以直接访问该节点上的 Pod。
  • Pod 内容器共享网络：同一 Pod 内的所有容器共享同一个网络命名空间（IP 和端口）。
  • 无端口映射：用户无需手动映射主机端口到容器端口。
关键理解： Kubernetes 网络模型本质上是“扁平网络”模型，所有 Pod 都在同一个二层或三层网络中，IP 地址全局可达。

2.2 Pod 网络：集群通信的最小单元

Pod 是 Kubernetes 中可调度的最小单元，每个 Pod 拥有一个独立的 IP 地址。Pod 网络的核心是 容器网络接口（CNI），它负责在 Pod 创建时分配 IP 并配置网络。

2.2.1 Pod 网络通信模型

Pod 网络通信分为三种场景：

通信场景 通信路径 是否经过 NAT
同节点 Pod ↔ Pod 通过节点上的网桥（如 cbr0）直接二层转发 否
跨节点 Pod ↔ Pod 通过节点路由表或隧道（VXLAN/IPIP）转发 否（但可能封装）
Pod ↔ 集群外服务 通过节点 iptables 规则进行 SNAT 是（源 IP 被替换为节点 IP）
性能提示： 同节点 Pod 通信延迟最低（微秒级），跨节点通信因封装/路由开销，延迟通常增加 10%-30%。Serverless 场景下应尽量将相关 Pod 调度到同一节点。

2.3 Service 网络：稳定的服务发现与负载均衡

Pod 的 IP 是动态变化的，Service 提供了一组稳定的虚拟 IP（ClusterIP）和 DNS 名称，用于访问一组 Pod。Service 网络的核心组件是 kube-proxy，它通过 iptables、IPVS 或 userspace 模式实现负载均衡。

2.3.1 Service 类型对比

Service 类型 访问范围 典型用途 是否支持外部流量
ClusterIP 集群内部 内部微服务通信 否
NodePort 集群外部（通过节点端口） 开发调试、简单对外暴露 是（通过节点 IP:Port）
LoadBalancer 集群外部（通过云负载均衡器） 生产环境对外暴露 是（自动分配 LB IP）
ExternalName 集群内部（DNS CNAME） 将外部服务映射为集群内服务 否（仅 DNS 映射）

2.3.2 kube-proxy 模式对比

模式 实现方式 性能 适用场景
iptables 内核 Netfilter 规则链 中等（规则多时延迟增加） 中小规模集群（< 5000 服务）
IPVS 内核 LVS 模块，哈希表查找 高（O(1) 时间复杂度） 大规模集群（> 5000 服务）
userspace 用户态代理（已弃用） 低 不推荐
Serverless 注意事项： 在 Serverless 集群中，Pod 生命周期极短，频繁创建/销毁会导致 iptables 规则大量更新，建议使用 IPVS 模式以降低规则变更延迟。

2.4 Ingress 网络：集群入口的统一网关

Ingress 是 Kubernetes 的 API 对象，用于管理集群外部访问集群内服务的 HTTP/HTTPS 路由。Ingress 网络位于 Service 网络之上，提供七层负载均衡、SSL 终止、虚拟主机路由等功能。

2.4.1 Ingress 架构

Ingress 控制器（如 Nginx Ingress、Traefik、HAProxy）作为反向代理运行在集群中，监听 Ingress 资源的变化并动态更新路由规则。

# 一个典型的 Ingress 配置示例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: serverless-app-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: api.serverless.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 80
  tls:
  - hosts:
    - api.serverless.example.com
    secretName: tls-secret

2.4.2 Ingress 与 Service 的关系

  • Ingress 不替代 Service：Ingress 负责七层路由，Service 负责四层负载均衡。
  • 典型流量路径：客户端 → Ingress Controller → Service（ClusterIP）→ Pod。
  • 性能优化：Ingress Controller 应使用 hostNetwork 模式或 LoadBalancer 类型 Service 暴露，避免二次转发。
最佳实践： 在 Serverless 集群中，建议将 Ingress Controller 部署为 DaemonSet，并使用 hostNetwork 模式，减少网络跳数，降低延迟。

2.5 CNI 插件原理：Calico 与 Flannel

CNI（Container Network Interface）是 Kubernetes 网络插件的标准接口。Calico 和 Flannel 是两种最主流的 CNI 插件，它们在网络模型、性能、安全策略方面有显著差异。

2.5.1 Flannel：简单高效的覆盖网络

Flannel 由 CoreOS 开发，采用 覆盖网络（Overlay Network） 模型，为每个节点分配一个子网，Pod 的 IP 从该子网中分配。Flannel 支持多种后端：

后端类型 封装方式 性能 适用场景
VXLAN UDP 封装（内核 VXLAN） 中等（约 10% 性能损耗） 大多数场景，跨网段通信
host-gw 直接路由（无封装） 高（接近原生性能） 节点二层可达的场景
UDP 用户态 UDP 封装 低 不推荐（已弃用）
Flannel 核心特点： 简单、易部署、无额外依赖。但 不支持网络策略（NetworkPolicy），仅提供连通性。

2.5.2 Calico：高性能的网络策略引擎

Calico 采用 纯三层路由模型，不使用隧道封装，通过 BGP（边界网关协议）在节点间分发路由。Calico 的核心优势在于其强大的 网络策略 能力。

特性 Calico Flannel
网络模型 纯三层路由（BGP） 覆盖网络（VXLAN/host-gw）
封装开销 无（直接路由） 有（VXLAN 约 50 字节头部）
网络策略 支持（基于 iptables/eBPF） 不支持
性能 高（接近原生） 中等（VXLAN 模式）
部署复杂度 中等（需 BGP 配置） 低（一键部署）
大规模集群 优秀（支持 1000+ 节点） 良好（需注意 etcd 压力）

2.5.3 Calico 与 Flannel 架构对比

Calico vs Flannel 架构对比 Flannel（VXLAN 覆盖网络） Node A Pod1: 10.1.1.2 Pod2: 10.1.1.3 flannel.1 (VXLAN) eth0: 192.168.1.10 Node B Pod3: 10.1.2.2 Pod4: 10.1.2.3 flannel.1 (VXLAN) eth0: 192.168.1.20 VXLAN 隧道 UDP 封装（端口 8472） 额外 50 字节头部开销 Calico（纯三层 BGP 路由） Node C Pod5: 10.2.1.2 Pod6: 10.2.1.3 cali 接口 (veth) eth0: 192.168.2.10 Node D Pod7: 10.2.2.2 Pod8: 10.2.2.3 cali 接口 (veth) eth0: 192.168.2.20 BGP 路由 直接路由（无封装） 原生网络性能 关键差异 Flannel 通过 VXLAN 隧道封装跨节点流量，简单但增加开销； Calico 通过 BGP 直接路由，性能更高且支持细粒度网络策略。

2.6 CNI 插件选型建议

在 Serverless 集群中，CNI 插件的选择直接影响 Pod 启动速度、网络延迟和安全隔离能力。

场景 推荐 CNI 理由
需要网络策略（多租户隔离） Calico 原生支持 NetworkPolicy，基于 iptables/eBPF 实现
追求极致性能（低延迟） Calico（BGP 模式） 无封装开销，接近原生网络性能
快速部署、简单运维 Flannel（VXLAN） 一键部署，无需 BGP 基础设施
大规模集群（> 500 节点） Calico BGP 路由收敛快，支持大规模路由表
混合云/多云环境 Flannel（VXLAN） 覆盖网络不受底层网络限制

2.7 网络性能优化要点

针对 Serverless 集群的网络性能优化，以下是最关键的实践：

  • 使用 IPVS 模式：kube-proxy 使用 IPVS 替代 iptables，降低 Service 规则匹配延迟。
  • 启用 eBPF：Calico 支持 eBPF 数据面，可替代 iptables，大幅提升网络策略性能。
  • 调整 MTU：VXLAN 模式需将 MTU 设置为 1450（减去 50 字节头部），避免分片。
  • 使用 hostNetwork：对延迟敏感的应用（如 Ingress Controller）使用 hostNetwork 模式。
  • 优化 DNS：使用 NodeLocal DNSCache 减少 DNS 查询延迟。
性能基准参考： 在同等硬件条件下，Calico（BGP 模式）的跨节点 Pod 通信延迟约为 Flannel（VXLAN）的 70%-80%，吞吐量高出 15%-25%。

2.8 本章小结

Kubernetes 网络模型由 Pod 网络、Service 网络、Ingress 网络三层构成，每层解决不同的通信问题。CNI 插件是实现 Pod 网络的关键组件，Calico 和 Flannel 分别代表了“高性能+策略”和“简单易用”两种设计哲学。在 Serverless 集群中，建议根据安全需求、性能要求和运维能力综合选择 CNI 插件，并针对性地进行网络优化。

← 上一章 📖 返回目录 下一章 →