3. 网络拓扑基础：Kubernetes网络模型
在深入Helm Values动态注入优化网络拓扑之前，必须建立对Kubernetes网络模型的扎实理解。Kubernetes的网络模型设计遵循一套严格的通信约束，所有网络拓扑模式（扁平网络、Overlay网络）都是围绕这些约束构建的。本章将系统梳理CNI、Pod网络、Service网络的核心概念，并对比两种主流拓扑模式的架构差异。
3.1 Kubernetes网络模型的核心约束
Kubernetes对集群网络提出了三个必须满足的硬性要求，任何CNI插件都必须实现：
- Pod间直接通信：任意两个Pod（无论是否在同一Node）必须能够直接通过IP地址通信，无需NAT转换。
- Node与Pod通信：Node上的进程（如kubelet）必须能够直接访问该Node上的PodIP。
- Pod内容器共享网络：同一Pod内的所有容器共享同一个网络命名空间（IP、端口、网络栈）。
3.2 CNI（容器网络接口）
CNI是Kubernetes与网络插件之间的标准接口协议。它定义了如何为Pod分配网络资源、配置网络接口以及管理IP地址。CNI插件是Kubernetes网络模型的具体实现者。
| CNI插件 | 网络模式 | 关键特性 | 适用场景 |
|---|---|---|---|
| Calico | 纯三层（BGP） | 高性能、原生网络策略、支持IPIP/VXLAN | 大规模生产、需要精细网络策略 |
| Flannel | Overlay（VXLAN/Host-GW） | 部署简单、轻量、性能适中 | 中小规模、快速搭建 |
| Cilium | eBPF驱动 | 超高性能、可观测性、安全策略 | 高性能需求、云原生安全 |
| Weave Net | Overlay（fastdp） | 加密通信、跨云混合部署 | 多云/混合云环境 |
3.3 Pod网络
Pod网络是Kubernetes集群中Pod之间通信的底层网络。每个Pod被分配一个唯一的Cluster IP（通常来自CNI管理的IP池），这个IP在Pod的整个生命周期内保持不变。Pod网络的核心组件包括：
- veth pair：连接Pod网络命名空间和宿主机网络栈的虚拟网线。
- 网桥（Bridge）：在宿主机上模拟二层交换机，连接同一Node上的多个Pod。
- 路由表：Node上的路由规则，决定Pod流量如何转发到其他Node。
- IPAM：负责分配和回收Pod IP地址，避免冲突。
3.4 Service网络
Service网络是Kubernetes提供的一个抽象层，用于为一组Pod提供稳定的访问入口。Service拥有一个虚拟IP（ClusterIP），该IP在Service的生命周期内保持不变，而后端Pod的IP可能会因扩缩容或故障而动态变化。Service网络的核心机制包括：
- ClusterIP：Service的虚拟IP，仅在集群内部可达。
- kube-proxy：运行在每个Node上的代理组件，负责将发往ClusterIP的流量转发到后端Pod。
- iptables/IPVS：kube-proxy使用的底层转发规则引擎。
- Endpoints/EndpointSlice：维护Service与后端Pod IP的映射关系。
3.5 常见的网络拓扑模式
根据CNI插件的实现方式，Kubernetes网络拓扑主要分为两大类：扁平网络和Overlay网络。两种模式在性能、复杂度、可扩展性上存在显著差异。
3.5.1 扁平网络（Flat Network）
扁平网络模式下，每个Pod直接从Node所在的物理网络或VPC中获取IP地址，Pod之间通过底层网络设备（路由器、交换机）直接路由。典型实现：Calico（BGP模式）、AWS VPC CNI。
| 维度 | 扁平网络 | Overlay网络 |
|---|---|---|
| IP分配 | Pod IP与Node IP在同一网络平面 | Pod IP独立于Node IP（通常为私有段） |
| 转发路径 | 直接路由（BGP/静态路由） | 封装-解封装（VXLAN/IPIP/Geneve） |
| 性能损耗 | 接近裸机性能（无封装开销） | 有封装开销（约5%-15%吞吐损失） |
| 网络策略 | 原生支持（利用iptables/eBPF） | 依赖CNI插件实现 |
| 基础设施依赖 | 需要底层网络支持路由（如BGP） | 无特殊要求（纯软件实现） |
| 典型场景 | 自建IDC、公有云VPC、高性能计算 | 多云、混合云、快速部署 |
3.5.2 Overlay网络
Overlay网络在现有物理网络之上构建一个虚拟的L2/L3网络。Pod IP被封装在底层网络的数据包中传输，对底层网络设备透明。典型实现：Flannel（VXLAN）、Calico（IPIP模式）、Weave Net。
3.6 拓扑模式对Helm Values注入的影响
网络拓扑模式直接影响Helm Chart中网络相关Values的设计。在后续章节中，我们将通过动态注入Values来优化不同拓扑下的数据传输路径。以下是关键影响点：
- IP地址管理：扁平网络下Pod IP与Node IP在同一平面，Values中可能需要配置IP池大小和路由表；Overlay网络下则需关注隧道端点配置。
- 性能调优参数：Overlay网络需要调整MTU（通常为1450，减去VXLAN头部50字节）、封装类型（VXLAN/IPIP/Geneve）等Values。
- 网络策略注入：不同CNI的网络策略语法不同，Values需要根据CNI类型动态生成对应的NetworkPolicy资源。
- Service拓扑感知：在扁平网络中，可以启用topology-aware routing（拓扑感知路由）来减少跨Node流量，这需要在Values中注入节点拓扑标签。
.Values.network.topology），并根据该值条件渲染CNI配置、MTU设置、路由规则和网络策略。这样，运维人员只需修改一个Values即可切换整个集群的网络行为。
3.7 本章小结
Kubernetes网络模型通过CNI插件实现了Pod间直接通信、Node与Pod通信以及Pod内容器共享网络三大约束。Pod网络提供底层IP连通性，Service网络提供稳定的服务发现和负载均衡。扁平网络和Overlay网络是两种主流的拓扑实现，前者性能优异但依赖底层基础设施，后者灵活通用但引入封装开销。理解这些基础概念是后续通过Helm Values动态注入优化网络数据传输的前提。