3. 网络拓扑基础：Pod网络模型、CNI插件原理、Service与EndpointSlice、网络策略
在Kubernetes集群中，网络拓扑是调度决策与流量路径的底层骨架。调度器需要感知Pod的网络模型、CNI插件的连通性、Service的负载分发机制以及网络策略的访问约束，才能做出最优的节点选择。本节从这四个核心维度展开，建立网络拓扑的完整认知。
3.1 Pod网络模型：扁平IP与容器间通信
Kubernetes要求所有Pod之间可以不通过NAT直接通信，所有节点与Pod之间也可以不通过NAT直接通信。这种扁平IP模型是调度与网络拓扑的基础。
| 通信方向 | 要求 | 典型实现 |
|---|---|---|
| Pod → Pod（同节点） | 通过本地网桥或veth对直接转发 | cbr0、docker0、CNI网桥 |
| Pod → Pod（跨节点） | 通过节点路由或overlay隧道可达 | Flannel VXLAN、Calico BGP、Cilium eBPF |
| Pod → Node | Pod源IP可达节点网络接口 | 节点路由表、iptables规则 |
| Pod → Service | 通过Cluster IP或NodePort转发 | kube-proxy (iptables/IPVS/eBPF) |
调度影响： 当Pod使用hostNetwork或特定Multus接口时，调度器必须考虑节点网络接口的可用性与带宽拓扑。例如，使用SR-IOV的Pod只能调度到具备对应VF资源的节点。
3.2 CNI插件原理：从容器创建到网络就绪
CNI（Container Network Interface）是Kubernetes与网络实现之间的标准接口。当kubelet决定在节点上启动一个Pod时，会调用CNI插件完成网络配置。
CNI调用流程
- ADD操作： kubelet调用CNI插件，传入容器ID、网络命名空间、网络配置等参数。
- 创建veth对： 插件创建一对veth设备，一端放入容器网络命名空间（eth0），另一端留在主机网络命名空间。
- 分配IP地址： 插件通过IPAM（如host-local、dhcp）为容器分配IP地址。
- 配置路由： 在容器内添加默认路由，在主机上添加路由规则。
- 返回结果： 插件返回IP地址、MAC地址、DNS等信息给kubelet。
| CNI插件 | 网络模式 | IPAM方式 | 调度感知 | 典型场景 |
|---|---|---|---|---|
| Flannel | VXLAN / host-gw | host-local | 低 | 简单集群，overlay隔离 |
| Calico | BGP / IPIP | host-local / CRD | 中 | 大规模，网络策略严格 |
| Cilium | eBPF / VXLAN | CRD / Kubernetes | 高 | 高性能，可观测性强 |
| Multus | 多网络接口 | 委托给附属插件 | 高 | NFV、DPDK、SR-IOV |
调度陷阱： 使用Multus或SR-IOV时，调度器默认不感知辅助网络的资源容量。必须配合NodeResourceTopology或device plugin才能正确调度。否则Pod可能被调度到没有可用VF的节点，导致启动失败。
3.3 Service与EndpointSlice：服务发现与负载分发
Service是Kubernetes中稳定的网络访问入口，而EndpointSlice是其后端Pod集合的高性能表示。调度器需要理解Service的拓扑约束，才能将Pod调度到最优位置。
Service类型与调度影响
| Service类型 | 访问方式 | 调度约束 | 典型延迟 |
|---|---|---|---|
| ClusterIP | 集群内部虚拟IP | 无直接约束 | 低（iptables规则匹配） |
| NodePort | 节点端口映射 | 需考虑节点端口冲突 | 中（额外DNAT） |
| LoadBalancer | 外部负载均衡器 | 需考虑外部LB与节点连通性 | 高（多跳转发） |
| ExternalName | DNS CNAME | 无网络层约束 | DNS解析延迟 |
EndpointSlice：拓扑感知路由
EndpointSlice是Endpoint的下一代实现，将后端Pod按拓扑域（如节点、可用区）分组。调度器可以利用EndpointSlice的hints字段实现拓扑感知路由，将流量优先转发到同节点或同可用区的Pod。
调度优化点： 当Service启用
topologyKeys或trafficDistribution时，调度器应优先将Pod调度到与客户端同拓扑域的节点，减少跨节点/跨可用区流量。例如，topologyKeys: ["kubernetes.io/hostname"] 强制流量优先发往同节点Pod。
3.4 网络策略：访问控制与调度约束
NetworkPolicy是Kubernetes中基于标签的防火墙规则，控制Pod之间的网络流量。调度器必须考虑网络策略的拓扑影响，避免将Pod调度到策略冲突或连通性受限的位置。
网络策略的核心要素
- podSelector： 选择策略作用的Pod集合。
- policyTypes： Ingress（入站）、Egress（出站）或两者。
- ingress/egress规则： 允许的源/目标IP段、端口、协议。
- namespaceSelector： 跨命名空间选择。
调度影响分析
| 场景 | 网络策略配置 | 调度约束 |
|---|---|---|
| 微服务隔离 | 只允许特定标签的Pod访问 | 需确保同服务Pod调度到策略允许的节点 |
| 合规性要求 | 禁止Pod访问外部网络 | 调度器需避免将Pod调度到有外部网络需求的节点 |
| 多租户隔离 | 租户间完全隔离 | 不同租户的Pod不能调度到同一节点（需配合NodeSelector） |
| 监控/日志采集 | 允许特定Agent访问所有Pod | Agent需调度到所有节点，且网络策略需放行 |
最佳实践： 在调度器中集成网络策略感知插件（如Scheduler Framework的
NodeResourcesFit扩展），在预选阶段过滤掉不满足网络策略约束的节点。例如，如果Pod的Egress规则要求访问特定外部IP，调度器应优先选择有对应路由的节点。
网络策略与CNI的协同
网络策略的执行依赖于CNI插件的能力：
- Calico： 使用iptables或eBPF实现策略，支持全局策略和命名空间策略。
- Cilium： 使用eBPF实现，支持L3/L4/L7策略，性能高。
- Flannel： 默认不支持网络策略，需配合Calico或Antrea使用。
- Antrea： 基于Open vSwitch实现，支持分布式防火墙。
常见问题： 网络策略默认是“白名单”模式，即未显式允许的流量都会被拒绝。调度器如果未感知网络策略，可能导致Pod启动后无法正常通信。例如，Pod A需要访问Pod B，但网络策略只允许来自特定标签的流量，而Pod A没有该标签，则通信失败。
3.5 网络拓扑与调度决策的关联
综合以上四个维度，调度器在做出决策时需要考虑以下网络拓扑因素：
| 网络因素 | 调度影响 | 数据来源 |
|---|---|---|
| Pod IP段容量 | 节点剩余IP地址数量 | CNI IPAM状态 |
| CNI插件类型 | overlay vs 直连，延迟差异 | 节点标签或配置 |
| Service拓扑约束 | 优先同节点/同可用区调度 | EndpointSlice hints |
| 网络策略规则 | 过滤不满足策略的节点 | NetworkPolicy对象 |
| 节点网络带宽 | 避免网络瓶颈节点 | 节点资源指标 |
实战要点： 在大型集群中，建议使用Cilium作为CNI插件，配合其ClusterMesh和NetworkPolicy功能，实现跨集群的网络拓扑感知调度。同时，启用Scheduler Framework的
NodeResourceTopologyMatch插件，将网络资源（如带宽、IP池）纳入调度决策。