Red Hat于8月5日公布OpenShift 4.22的EVPN网络能力，让Kubernetes集群能够直接加入企业现有的EVPN-VXLAN数据中心网络。集群内部的工作负载不再只能通过独立网关接入外部网络，而是可以使用标准化控制平面交换可达信息。
这项能力主要面向大型虚拟化迁移、混合基础设施和电信网络。企业在把虚拟机与应用迁移到OpenShift时，可以保留原有二层或三层网络设计，减少为Kubernetes另建一套专用网络体系的压力。
EVPN把集群边界向外延伸
传统Kubernetes网络通常在集群内部完成服务发现、地址分配和流量转发，离开集群后再交给企业路由器与交换机。两套体系之间需要额外网关、路由配置或厂商专用集成。
OpenShift 4.22把OVN-Kubernetes网络进一步连接到客户管理的外部网络。管理员可以选择需要延伸的用户自定义网络，让对应工作负载成为数据中心网络中的直接参与者。
这种方式不会自动把所有Pod暴露到外部。哪些网络能够跨越集群边界、使用二层还是三层连接，仍由管理员按业务与隔离要求配置。
BGP负责控制平面，VXLAN承载数据
EVPN使用BGP分发MAC地址与IP地址的可达信息，再通过VXLAN隧道承载实际数据。逻辑网络因此可以跨越多个路由域、叶脊网络或分布在不同位置的数据中心。
OpenShift 4.18已经引入用户自定义网络，为集群内应用提供隔离的二层和三层网络域。4.19.12加入BGP后，集群能够参与企业路由体系，4.22的EVPN则在此基础上增加更完整的MAC与IP路由传播。
Red Hat表示，该方案支持通过标准化的MAC-VRF和IP-VRF路由公告连接二层与三层用户网络。对网络团队而言，这些协议和概念与现有数据中心架构一致，减少学习另一套封闭控制面的成本。
虚拟化迁移可保留原有网络设计
企业从传统虚拟化平台迁移工作负载时，IP规划、VLAN、路由策略和安全区域往往已经与业务绑定。强制改变网络结构可能比迁移虚拟机本身更复杂，也会增加停机和回滚难度。
EVPN允许OpenShift中的虚拟机、容器与外部网络保持一致的二层或三层连接方式。工作负载可以跨物理网络通信，同时继续使用企业已有的叶脊交换架构和运维流程。
不过，保留网络设计不代表迁移无需测试。MAC地址学习、MTU、VXLAN封装、路由收敛、广播范围和故障切换都可能影响生产业务，尤其需要避免把过大的二层故障域直接延伸到多个集群。
标准协议减少专用网关依赖
Red Hat强调，OpenShift 4.22可以直接接入现有EVPN网络，不需要依赖专有网关或定制集成。这样更容易把交换机、路由器、集群网络和自动化配置放在统一的标准体系中管理。
对于多集群环境，标准协议也便于复用已有监控与故障排查方法。网络团队可以从BGP邻居、EVPN路由、VRF与VXLAN隧道逐层定位，而不是只能从Kubernetes内部日志判断外部链路问题。
直接集成同时扩大了配置影响范围。错误的路由公告或网络延伸可能进入企业核心网络，因此部署前需要建立路由过滤、变更审查和回滚机制，并明确集群团队与网络团队的责任边界。
托管OpenShift支持仍在后续路线中
Red Hat在公告中表示，未来计划把这套架构扩展到Red Hat OpenShift Service on AWS、Microsoft Azure Red Hat OpenShift和OpenShift Dedicated等托管服务。
这意味着当前公告的重点是OpenShift 4.22平台能力，不能直接推断所有托管OpenShift环境已经开放相同功能。云平台的底层网络、权限与服务边界不同，实际可用时间仍要等待对应产品公告。
对自建OpenShift集群而言，EVPN提供了一条更贴近现有数据中心的网络整合路线。它的价值不在于替代所有集群网络，而是在需要虚拟化迁移和二三层延伸时，减少Kubernetes与企业网络之间的割裂。
