4. OpenShift网络模型与CNI配置

OpenShift 的网络体系建立在 Kubernetes 基础网络模型之上，但通过 CNI 插件做了大量增强。理解这一层的关键，是先分清三个彼此独立又相互衔接的平面：Pod 网络负责 Pod 之间以及 Pod 与节点之间的东西向通信；Service 网络提供稳定的虚拟 IP 与负载均衡；集群外部访问网络则通过 Route、Ingress 或 NodePort 把流量引入集群。本节聚焦前两者，并延伸到网络策略、多网络与 SR-IOV 场景。

一、OVN-Kubernetes 的工作原理

OpenShift 4.x 默认使用 OVN-Kubernetes 作为 CNI。它把网络控制逻辑集中到 ovn-kubernetes 控制器，把数据转发下沉到每个节点上的 ovnkube-node 与 Open vSwitch（OVS）。可以把它理解为“集中式控制面 + 分布式数据面”的组合：北向数据库（NB DB）保存逻辑网络意图，南向数据库（SB DB）把意图翻译成流表，最终由 OVS 在节点上执行。

每个节点会创建一个名为 br-int 的集成网桥，Pod 通过 veth pair 接入网桥，节点上的 OVN 逻辑交换机负责二层转发，逻辑路由器负责跨子网三层转发。Pod 的 IP 由集群 CIDR 分配，节点之间通过 Geneve 隧道封装跨节点流量。这意味着 Pod IP 在整个集群内可直接路由，无需 NAT，这也是网络策略能够基于 Pod 身份生效的基础。

二、Pod 网络与 Service 网络规划

安装集群前必须规划两个 CIDR，且二者不能重叠，也不能与节点所在物理网络、外部路由网段重叠。常见规划如下（示例参数，非实测）：

Pod CIDR 的掩码决定了单节点可分配的 Pod 数量。例如 10.128.0.0/14 配合每节点 /23 子网，可提供约 510 个 Pod IP/节点，最多支持约 64 个节点。Service CIDR 则决定可创建的 Service 数量，/16 约 6.5 万个地址，通常足够。

Service 的实现依赖 OVN 的逻辑负载均衡器。创建 Service 时，kube-proxy 的角色被 OVN 取代：ClusterIP 被写入逻辑流表，访问该 VIP 的流量在源节点就被 DNAT 到某个后端 Pod IP。因此 Service 网络本身不占用真实接口，只是逻辑地址空间。

三、网络策略基础

NetworkPolicy 是 Pod 级别的防火墙规则，默认拒绝所有入站和出站，再按需放行。它作用于 Pod 选择器匹配的 Pod，规则中的 from/to 可以引用命名空间、Pod 标签或 CIDR 块。OVN-Kubernetes 会把策略翻译成 ACL 流表，在 br-int 上执行。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-db
  namespace: prod
spec:
  podSelector:
    matchLabels:
      app: mysql
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 3306

该策略表示：仅允许 prod 命名空间中带 app=web 标签的 Pod 访问 app=mysql 的 3306 端口，其余入站流量全部丢弃。验证时可用 oc exec 从 web Pod 执行 nc -zv mysql 3306，成功返回即策略生效；从其他 Pod 执行应超时。

四、多网络与 SR-IOV 场景认知

默认情况下，一个 Pod 只有一张网卡（eth0），接入集群默认网络。但在高性能、多租户或需要二层直连的场景中，需要为 Pod 附加额外网络。OpenShift 通过 NetworkAttachmentDefinition（NAD）定义附加网络，由 Multus CNI 负责把多张网卡挂到同一个 Pod 上。

SR-IOV 是其中性能最高的一种：它把物理网卡的虚拟功能（VF）直接透传给 Pod，绕过内核协议栈，获得接近线速的转发和极低延迟。典型场景包括 5G UPF、DPDK 转发、高性能数据库互联。使用前需要节点具备支持 SR-IOV 的网卡，并部署 SR-IOV Network Operator 与相应的 SriovNetworkNodePolicy。

配置 SR-IOV 附加网络的大致过程是：先创建 SriovNetworkNodePolicy 声明 VF 数量与驱动类型，Operator 会生成对应的 SriovNetwork 和 NAD；然后在 Pod 注解中引用该 NAD，Pod 启动后即可看到额外的 net1 接口。判断是否成功，可进入 Pod 执行 ip link show net1，若显示 VF 对应的 MAC 与状态 UP，说明透传生效。

综合来看，OVN-Kubernetes 提供了默认的东西向与 Service 网络能力，NetworkPolicy 提供安全边界，Multus 与 SR-IOV 则在需要时扩展出多网络与高性能数据面。规划阶段把 CIDR、策略模型和附加网络需求一并考虑，能显著减少后期返工。