3. 网络拓扑设计：扁平网络、Overlay网络、Underlay网络、混合拓扑场景

Kubernetes 网络拓扑的选择直接决定了集群的转发效率、故障隔离粒度以及运维复杂度。在生产环境中，没有一种拓扑能适用于所有场景；理解扁平、Overlay、Underlay 及混合拓扑的底层原理与性能特征，是进行 Helm 参数协同调优的前提。

3.1 四种核心拓扑模型对比

3.2 扁平网络拓扑

扁平网络是最原始的 K8s 网络模型：每个 Pod 被分配与 Node 同网段的 IP，Pod 之间通过宿主机的路由表直接通信，无需额外封装。这种拓扑在小型集群（< 50 节点）中表现优异，延迟接近物理网卡性能。

• 优势： 零封装开销，吞吐量可达线速；tcpdump 可直接抓取 Pod 流量，排障直观。
• 劣势： IP 地址规划受限，Pod 数量受限于子网大小；跨子网通信需要外部路由配合，扩展性差。
• 适用 CNI： macvlan、ipvlan、host-gw 模式（Calico）。

# 扁平网络下 Pod 与 Node 同网段示例
Node IP:      10.0.1.10/24
Pod IP:       10.0.1.20/24
Gateway:      10.0.1.1
# 无隧道封装，直接二层转发

3.3 Overlay 网络拓扑

Overlay 网络通过在现有三层网络之上构建虚拟化隧道层，使 Pod 可以拥有独立于物理网络的 IP 空间。这是当前公有云和多租户场景中最主流的方案。

Overlay 网络的核心性能瓶颈在于 隧道封装/解封装 的 CPU 开销以及 MTU 链式降低。以 VXLAN 为例：

• 物理网络 MTU = 1500 → Pod 网卡 MTU 必须 ≤ 1450（50 字节 VXLAN 头）。
• 若物理网络启用 jumbo frame（MTU 9000），Pod MTU 可设为 8950，吞吐量提升显著。
• 封装操作在 VTEP（VXLAN Tunnel Endpoint）上进行，内核态处理延迟约 2~5 μs，DPDK 加速可降至亚微秒级。

# Overlay 网络 MTU 链式调整示例（Helm values）
cni:
  type: calico
  mtu: 1450          # 物理 MTU 1500 - 50 封装头
  overlay: vxlan
  vxlanPort: 4789

# 若物理网络支持 jumbo frame
cni:
  mtu: 8950          # 物理 MTU 9000 - 50 封装头

3.4 Underlay 网络拓扑

Underlay 网络让 Pod 直接“挂载”到物理网络接口上，Pod IP 与 Node IP 处于同一路由域。这种拓扑消除了封装开销，但要求底层网络设备支持大量 MAC/IP 学习，对交换机规格有较高要求。

• 性能特征： 延迟接近裸机，P99 延迟通常 < 10 μs；吞吐量可达 40Gbps 线速。
• 运维代价： 每个 Pod 的 IP 都需要在物理交换机上注册，大规模集群（> 200 节点）可能导致 MAC 表溢出。
• 典型实现： macvlan bridge 模式、SR-IOV、Calico BGP 直连模式。

3.5 混合拓扑场景

混合拓扑在同一集群内同时运行 Overlay 和 Underlay 网络，通常通过 多 CNI 插件 或 NetworkAttachmentDefinition（NAD） 实现。这种设计在金融、实时音视频、AI 训练等场景中越来越普遍。

混合拓扑的 Helm 参数协同需要为不同工作负载设置独立的 values.yaml 覆盖：

# 全局默认使用 Overlay
global:
  network:
    mode: overlay
    mtu: 1450

# 数据库 StatefulSet 使用 Underlay
statefulset:
  db:
    network:
      mode: underlay
      mtu: 1500
      interface: eth1
      ipam:
        type: host-local
        subnet: "10.100.0.0/24"

3.6 拓扑选择决策流程

3.7 Helm 参数协同要点

无论选择哪种拓扑，Helm 部署时都需要通过 values 文件精确控制网络参数。以下是不同拓扑下的关键参数对照：