Kube-OVN 混合网络场景最佳实践

关注

原创最新推荐文章于 2026-06-28 16:48:54 发布 1.4k 阅读 AI 写同款· GEO 优化 ›

Kube-OVN 工作原理与应用场景 Kube-OVN 是一款 CNCF 旗下的企业级云原生网络编排系统，将 SDN 的能力和云原生结合，提供丰富的功能，极致的性能以及良好的可运维性。 Kube-OVN 在底层使用 Open Virtual Network（OVN）和 OpenVswitch 来实现网络的编排，并将其丰富的能力暴露给 Kubernetes 网络。阅读详情

在近期的技术分享中，灵雀云技术专家刘梦馨与现场网络专家深入探讨了Kube-OVN在混合网络场景下的最佳实践。本次分享详细介绍了Overlay和Underlay网络的特点及其在实际应用中的混用场景，并展示了Kube-OVN项目如何通过自身的解决方案应对混合网络的挑战。以下是本次分享的详细内容回顾。

01Overlay 与Underlay 网络为什么要混用

Overlay 网络

Overlay网络是一种在Kubernetes中通过隧道技术实现的网络类型，允许容器拥有独立于宿主机的IP地址。这种网络提供了隔离性和灵活性，适用于需要安全隔离和自定义网络配置的场景。主流的K8s网络解决方案如Flannel、Calico和Cilium等都支持Overlay网络。

优点

网络依赖低：通过隧道封装技术，容器网络与宿主机网络逻辑隔离，不依赖底层网络。
配置灵活：可以自由配置网关、DNS等，易于管理。
功能可拓展性：软件封装的网络，易于扩展。
安全隔离：容器IP不直接暴露，增强安全性。

缺点

额外的性能开销：封装和解封装操作增加延迟。
运维复杂度增加：涉及两层网络，问题排查复杂。
与底层网络的互通问题：需要额外配置实现互通。

Underlay 网络

Underlay网络是一种逻辑上更简单的网络架构，通过直接桥接物理网卡，使容器网络与底层物理网络相连。容器的IP和MAC地址直接映射到物理网络，避免了复杂的封装和软件定义规则，提供了一种更直接和易于管理的网络解决方案。

优点

性能好：直接使用物理网络，减少封装开销。
天然与底层网络互通：无需额外配置即可实现互通。
运维类似传统网络：易于传统网络管理员理解和管理。

缺点

对底层网络有依赖：管理成本高，地址空间占用大。
变更复杂：网络变更需要底层网络支持。
功能可拓展性小：受限于物理网络。
混部场景：Overlay与Underlay混部

在Kubernetes环境中，根据应用的具体需求，往往需要同时采用Overlay和Underlay网络。对于不需要高性能但需要隔离的内部服务，Overlay网络提供了灵活性和安全性；而对于需要高性能和直接外部访问的应用，如数据库和中间件，Underlay网络则更为合适。这种混合网络模式正成为越来越多复杂应用场景下的部署趋势。

02混合网络存在的问题

Multus

Multus是由英特尔开源并由Kubernetes社区托管的多网络平面管理工具。它扩展了Kubernetes的CNI，允许Pod配置多块网卡和多个IP地址，尽管K8s最初设计时只支持单网卡。

Multus的两种模式

多网卡模式：Pod可以配置多个CNI插件，实现多网卡。主网卡（如eth0）提供主要网络连接，而附属网卡（如net0, net1）通过CRD添加，支持额外的网络连接需求。
单网卡模式：Pod只有一块网卡，但可以选择使用不同的CNI插件来管理其网络连接，尽管只有一个物理网卡，但可以利用不同的网络策略和配置。

1、多网卡

优点

网络需求满足：每个容器都可以访问Overlay和Underlay网络。
实现互通：每个Pod的两块网卡使得业务能够同时访问Overlay和Underlay网络，实现网络互通。

缺点

地址资源浪费：无论业务是否需要，每个Pod都会被分配两块网卡和两个地址，导致地址资源的浪费。
服务发现和安全策略问题：K8s的网络相关概念如Service、DNS域名、Network Policy等只针对第一块网卡，导致服务发现和安全策略存在隐患。
额外监控管理复杂度：需要在两个网卡上进行监控，增加了管理的复杂性。
应用感知问题：应用可能需要感知多网卡的存在，并进行相应的调整，增加了应用层面的复杂性。

多网卡相关辅助项目

在Kubernetes社区中，为了应对多网卡环境带来的挑战，各个组织正在推进一些辅助项目。其中包括一个名为multi-networkpolicy的API，这是一个早期的API，专门设计用于处理多网卡情况下的网络策略，提供了通过IP table和TC（Traffic Control）的样例实现。此外，还有一个多网卡服务发现项目，虽然目前维护不活跃，但其基础功能仍然可以满足基本需求。对于已经部署多网卡并需要网络策略或服务发现功能的用户，这些项目提供了可行的解决方案。

例如：

multi-networkpolicy API：

https://github.com/k8snetworkplumbingwg/multi-networkpolicy
multi-networkpolicy-iptables
multi-networkpolicy-tc
multi-service：

https://github.com/k8snetworkplumbingwg/multus-service-archived

2、单网卡

优点

应用无感知：Pod只有一块网卡，简化了网络配置，应用不需要感知复杂的网络设置。
兼容性：兼容原生的Service和NetworkPolicy，无需额外配置。
资源节省：节约Underlay的IP资源，简化了资源管理。

缺点

互通性问题：Underlay和Overlay之间的Pod无法直接互通，需要额外配置。
管理复杂度：需要管理多个网络插件，增加了复杂性。

03Kube-OVN的解决方案

Kube-OVN简介

Kube-OVN是灵雀云在2019年开源的网络项目，利用成熟的OVS（Open vSwitch）技术作为数据平面的基础，并结合Kubernetes原生设计，针对企业级容器网络的需求开发。该项目通过整合OVN（Open Virtual Network）的逻辑路由器和逻辑交换机，构建了一个灵活的SDN网络，支持Overlay和Underlay网络的集成。

Kube-OVN解决方案

Kube-OVN的解决方案通过以下方式实现Overlay和Underlay网络的互通：

网络实现：Overlay网络通过逻辑交换机与逻辑路由器相连，形成SDN网络；Underlay网络则通过逻辑交换机与物理交换机桥接，实现数据平面的直接传输。
互通策略：通过在Underlay网络中创建逻辑端口并连接到Overlay的逻辑路由器，实现网络互通。同时，在逻辑路由器上配置路由规则，区分访问Overlay和非Overlay网络的流量。
默认网关设置：在Underlay网络的Pod中，设置默认网关指向与逻辑路由器相连的端口，确保流量正确路由。
简化配置：避免了复杂的NAT和额外路由配置，通过逻辑路由器的规则实现直接互通。