1. OpenShift网络架构总览
OpenShift 的网络体系并不是“一张网”，而是由三层相互叠加的抽象共同构成：集群网络模型定义“Pod 与 Service 应该具备什么样的连通语义”，CNI 插件体系定义“这些语义由谁来实现、如何被 kubelet 调用”，网络组件拓扑与数据流路径则决定“一个数据包从源到目的究竟经过哪些节点、哪些内核转发点”。理解这三层，是后续排查跨节点不通、Service 访问异常、NetworkPolicy 不生效等问题的前提。
一、集群网络模型：三条基本约定
OpenShift 遵循 Kubernetes 的网络模型，核心是三条约定。第一，每个 Pod 拥有独立 IP，同一 Pod 内所有容器共享该 IP 与网络命名空间，因此容器之间通过 localhost 通信。第二，Pod 之间可直接通信，无需 NAT，无论它们是否在同一节点。第三，节点与 Pod 之间可双向通信，节点上的进程能直接访问 Pod IP，Pod 也能访问节点。
在这三条之上，OpenShift 额外提供 Service 抽象：Service 拥有一个稳定的虚拟 IP（ClusterIP），通过 kube-proxy 或 OVN 的分布式负载均衡把流量转发到后端 Pod。因此实际存在两套地址平面——Pod 网络（真实 IP，可路由）与 Service 网络（虚拟 IP，仅集群内有效），二者由不同的 CIDR 段承载，规划时必须避免与节点网络、外部网络重叠。
二、CNI 插件体系：谁在真正配置网卡
CNI（Container Network Interface）是一套规范：kubelet 在创建或销毁 Pod 沙箱时，按顺序调用 CNI 插件二进制，插件负责在容器的网络命名空间内创建接口、分配 IP、写入路由。OpenShift 中真正承担这一职责的是集群网络 Operator 部署的 CNI 插件，它同时还要完成节点间的隧道或路由编程。
OpenShift 历史上提供两种主流实现：OpenShift SDN（基于 Open vSwitch，模式有 ovs-subnet、ovs-multitenant、ovs-networkpolicy）与 OVN-Kubernetes（基于 OVN/OVS，是当前默认与推荐方案）。二者都实现了 CNI 规范，但内部数据模型、策略能力和可观测性差异明显。
三、OVN-Kubernetes 与 OpenShift SDN 对比
| 维度 | OpenShift SDN | OVN-Kubernetes |
|---|---|---|
| 底层转发 | Open vSwitch 流表 | OVN 逻辑流 + OVS 数据面 |
| 网络隔离 | ovs-multitenant 按项目隔离 | NetworkPolicy / AdminNetworkPolicy，语义更完整 |
| Service 实现 | iptables 或 OVS 流表 | OVN 分布式负载均衡，无需 kube-proxy 逐节点编程 |
| 跨节点路径 | VXLAN 隧道为主 | Geneve 隧道，支持直连路由模式 |
| 可观测性 | ovs-ofctl 查看流表 | ovn-trace、ovn-sbctl 逻辑追踪 |
| 扩展能力 | 功能趋于冻结 | 持续演进，支持 EgressIP、EgressFirewall、多网络 |
选择建议很直接：新集群一律使用 OVN-Kubernetes；仅在从旧版本升级、且存在强依赖 ovs-multitenant 隔离语义的场景下才保留 OpenShift SDN。需要注意的是，二者不能在同一集群混用，迁移需通过受支持的迁移流程完成。
四、组件拓扑与数据流路径
控制面上，ovnkube-control-plane 运行在 master 节点，负责分配 Pod 子网、维护逻辑网络与策略；每个节点上的 ovnkube-node 负责本节点的接口配置、流表下发与状态上报。数据面上，每个节点有一个 br-int 集成网桥，Pod 的 veth 对一端接入其中；跨节点流量经 br-ex 或隧道端口封装后发出。
下面这张图给出同一集群内“Pod A 访问 Service B”的完整路径，重点标出 Pod 网段与 Service 网段的切换点，以及 OVN 在何处完成 DNAT 与负载均衡。
图中可以看到三个关键判断点。第一，DNAT 发生在源节点：Pod A 发出的目标地址是 Service IP 172.30.0.10，OVN 在 br-int 上依据逻辑流把它改写为后端 Pod B 的 10.129.0.7，因此隧道中传输的已经是 Pod IP。第二，策略校验在两端都可能发生：源节点检查出向 NetworkPolicy，目的节点检查入向策略，任一侧拒绝都会导致连接超时而非立即报错。第三，回程依赖连接跟踪：Pod B 看到的源地址是 Pod A 的真实 IP，回包由目的节点按 conntrack 记录还原为 Service IP，从而保证 Pod A 侧连接状态一致。
五、排障时的观察入口
当出现“Pod 之间不通”时，可按路径逐段验证。先确认 Pod IP 与所在节点：oc get pod -o wide。再在源节点查看 OVN 逻辑流是否命中：ovn-trace --source=10.128.0.5 'inport=="pod-a" && eth.dst==...'。若怀疑隧道问题，检查 ovs-vsctl show 中 Geneve 端口状态与 ovnkube-node 日志。若 Service 不通但 Pod 直连正常，重点看 Service 的 Endpoints 是否为空、以及 DNAT 流是否存在。