Kube-OVN: OVN-based network virtualization for Kubernetes, and when it is the wrong CNI

The problem Kube-OVN solves: Kubernetes networking that behaves like a virtual data center

Kubernetes ships a flat pod network and a thin policy API. That is enough for many clusters. It is not enough when tenants need separate address spaces, when a pod must keep a fixed IP across restarts, or when a virtual machine has to be live migrated without dropping its connection. Kube-OVN's answer is to put OVN, the Open Virtual Network control plane, underneath Kubernetes and expose its logical switches and routers as Kubernetes objects.

The README frames the project as integrating OVN-based network virtualization with Kubernetes, with "enhanced support for KubeVirt and unique Multi-Tenancy capabilities". The audience follows from that. Platform teams running multi-tenant clusters, operators running KubeVirt workloads, and anyone who needs pod IPs reachable from the physical network without NAT are the intended users. A single-tenant cluster running stateless services on a flat overlay is not.

How the OVN control plane maps onto Kubernetes objects

The mapping is the interesting part. A Namespace gets a Subnet, and that Subnet is backed by an OVN Logical Switch. Pods in the namespace draw IPs from that subnet's range, and multiple namespaces can share one subnet when the isolation boundary should be wider than a single namespace. Above subnets sits the VPC: a multi-tenant network with independent address spaces where each tenant has its own eips, NAT gateways, security groups and load balancers.

Gateway behaviour is configurable in two directions. Distributed Gateways let every node act as a gateway for external connectivity, while Namespaced Gateways give a namespace a dedicated egress gateway. Pod IPs can also be exposed outside the cluster directly, or advertised by BGP through a router. The repository layout matches this architecture: cmd/ holds the entry points, pkg/ the controllers and CNI logic, charts/ the Helm packaging, and fastpath/ the data plane pieces. Kube-OVN does not replace OVN; it is the translation layer that keeps OVN's databases in sync with the Kubernetes API.

Installing Kube-OVN and creating a first subnet

The README does not inline installation commands. It points to the project's own installation guide for a one-step install, and the repository carries a Helm chart under charts/. Because the README gives no literal install command, the honest starting point is the documentation site rather than a copied snippet.

What the repository does show is how the project is built and tested. The Makefile pulls in build, unit test, kind, talos and e2e makefiles, so a local development loop runs through those targets. The chart values include networking settings such as tlsMinVersion, tlsMaxVersion and tlsCipherSuites for the OVN database TLS configuration, which tells you the chart expects TLS parameters to be set at install time if you want them. The same Makefile defines the image references used in its test environments, including MULTUS_IMAGE, METALLB_CONTROLLER_IMAGE and FRR_IMAGE, which is a useful signal about what a full-featured deployment is expected to sit next to.

Once installed, the first real use is creating a subnet for a namespace. The README describes the model rather than the YAML, so the object shape has to be confirmed against the reference documentation before applying it. What the README does state is the behaviour to expect: pods within a namespace take addresses from that namespace's Subnet, static IP allocation is available for workloads that need a stable address, and a secondary-CNI setup attaches extra interfaces through Network Attachment Definitions instead of taking over the pod's primary interface.

Where Kube-OVN is the wrong tool

The cost is operational surface. Kube-OVN is not a single daemon that programs a few routes. It runs OVN central components, per-node agents and a controller that reconciles Kubernetes objects into OVN databases. That is a second distributed control plane to upgrade, monitor and back up, sitting next to the Kubernetes control plane. The README does not document rollback of an upgrade or a downgrade path, and it does not state what happens to existing pod IPs if the OVN databases are lost. If you cannot answer those questions for your environment, that is a reason to wait.

The second mismatch is scale of need. If your cluster has one tenant, no virtual machines, and no requirement for pod IPs to be routable from the physical network, the VPC, EIP, NAT gateway and BGP features are unused weight. The README's feature list is long, and every item on it is something an operator may eventually be paged about. A plain overlay CNI with the standard networking.k8s.io/NetworkPolicy API covers that case with fewer moving parts.

Kube-OVN versus Calico and Cilium, and versus ovn-kubernetes

Calico and Cilium are the alternatives people most often weigh, and the difference is in where the routing intelligence lives. Calico programs routes and iptables or eBPF rules and is built around a flat, policy-rich IP fabric; Cilium puts its forwarding and policy enforcement in eBPF at the kernel, with identity-based policy as the centre of gravity. Kube-OVN instead delegates forwarding to OVS and control to OVN, which is why it can offer logical-switch-per-subnet semantics, VPCs with their own NAT and load balancers, and underlay or VLAN modes that connect directly to the physical network. The README lists underlay and VLAN support explicitly as a way to get "better performance and direct connectivity with physical network".

ovn-kubernetes is the closer comparison, since both use OVN. The distinction visible here is product scope: Kube-OVN's README leads with VPC support, namespaced subnets, IPAM for other CNI plugins, embedded load balancers as a kube-proxy replacement, traffic mirroring, hardware offload and multi-cluster L3 networking. Those are features layered on top of OVN rather than OVN itself. If you want OVN semantics with a smaller feature set, the other option exists; if you want the VPC and gateway abstractions, Kube-OVN is the one that documents them.

Release cadence, licence and the upgrade question

The repository is not archived, and the last push was on 2026-08-22, with v1.15.24 released the same day and v1.15.23 and v1.15.22 earlier in August 2026. That is a tight patch cadence on the 1.15 line, which matters because a CNI upgrade touches every node's data path. The practical cost is not the download; it is the drain-and-restart window for the agents and the state of the OVN databases during the transition.

Kube-OVN is licensed under Apache-2.0, which permits commercial use and modification and requires preservation of notices; the repository carries a SECURITY.md and a GOVERNANCE.md, and the project is described as a CNCF Sandbox project. This is a summary of what the repository states, not legal advice. For a regulated environment, the relevant questions are whether your distribution accepts Apache-2.0 components and whether the OVN database backup and restore procedure is documented for your version. The README itself does not cover upgrade or rollback, so that material has to come from the operations documentation.

Editorial conclusion

Adopt Kube-OVN if you need VPC-style tenant isolation, per-namespace subnets, static pod IPs or KubeVirt live migration, and you are willing to run OVN central components alongside Kubernetes. Do not adopt it if you only need a simple overlay with basic NetworkPolicy; Calico or Cilium will be less to operate. Before committing, verify how your cluster's primary CNI is chosen, whether Kube-OVN runs as primary or as a secondary CNI via Network Attachment Definitions, and how the OVN databases are backed up in your environment.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes