Kube‑OVN: Enabling Enterprise Innovation with Cloud‑Native Networking

Recently the Kube‑OVN community partnered with F5 to host an online seminar where Lingque Cloud’s chief architect Du Dongming presented “Cloud‑Native Network Solution: Kube‑OVN Empowers Enterprise Continuous Innovation,” and this article provides a detailed recap of that talk.

The concept of cloud‑native originated in 2010, gained practical footing with Docker in 2013, and Chinese enterprises began experimenting with containers around 2015, focusing on Container‑as‑a‑Service (CaaS) for managing, scheduling, and orchestrating containers.

By 2018 Kubernetes overtook Mesos and Swarm to become the de‑facto standard, prompting many banks and large enterprises to adopt it; the focus then shifted from pure PaaS to full application lifecycle management across development, testing, release, and operations.

Two major trends emerged: the “platformization” trend, where Kubernetes is treated as a platform with demands for DevOps, micro‑services, and data services, and the “sinking” trend, where customers move Kubernetes from virtual machines to bare‑metal to reduce management overhead.

Container networking has always been critical. Early Docker offered only single‑host networks; in 2016 a macvlan solution was created to address overlay limitations, and in 2018 the community turned to OVN for a more robust network stack. Kube‑OVN’s first open‑source version appeared in 2019 and entered CNCF as the first container‑network sandbox project in 2021.

Today the Kubernetes ecosystem lists about 27 CNI plugins, but Kube‑OVN remains one of the few general‑purpose solutions that can serve diverse enterprise needs.

A cloud‑native network must handle external traffic ingress, service‑to‑service communication, dynamic service discovery, IP address management (including fixed, elastic, IPv4/IPv6), security policies, performance at massive scale, and cross‑cluster connectivity.

Traditional container networks face three core problems: limited overlay‑to‑physical network integration, lack of fixed IP support, and insufficient security policy capabilities.

Kube‑OVN addresses these by managing subnets as the smallest unit, mapping subnets to Kubernetes namespaces, supporting VPC‑style multi‑tenant isolation, and enabling direct inter‑cluster communication through overlay or underlay networking.

Architecturally, Kube‑OVN uses Open vSwitch for overlay mode, offering both centralized gateway (traffic exits via a router) and distributed gateway (each node routes directly). Underlay mode leverages physical VLANs and can support multicast, which is valuable for finance and security‑sensitive customers.

Key features include multi‑tenant VPC, fine‑grained subnet management, VLAN and multicast support, fixed IP and Elastic IP, IPv4/IPv6 dual‑stack, multi‑NIC per pod, full NetworkPolicy compliance, cross‑cluster communication, DPDK and smart‑NIC acceleration, traffic mirroring, VM integration, and built‑in observability via Prometheus.

The vision is a dual‑mode IT landscape where stable workloads run on traditional systems while agile, cloud‑native workloads run on Kubernetes; Kube‑OVN aims to be the SDN layer for the agile side, providing VPC, security, and cross‑cloud connectivity, especially through the joint CES solution with F5.

The roadmap focuses on multi‑NIC subnet support, productized VPC, MetalLB integration, pod QoS prioritization, KubeVirt enhancements, continuous performance optimization, and support for white‑box switches to extend Kube‑OVN into full data‑center SDN.

Community resources such as the Kube‑OVN website, GitHub repository, and Slack channel are provided for further engagement.