How Kube-OVN Transforms Kubernetes Networking for Cloud‑Native Environments

Motivation

Kubernetes’ default networking model assumes a fully connected, homogeneous environment, which does not meet enterprise requirements such as integration with legacy infrastructure, fixed IP/MAC for high‑security workloads, multi‑VPC, multi‑cluster federation, and cross‑cloud connectivity. Kube‑OVN was created to address these gaps.

What is Kube‑OVN?

Kube‑OVN is a Kubernetes CNI built on Open vSwitch (OVS), a mature data‑plane used by OpenStack. It runs as an Operator with custom resources (CRDs) and provides VPC, fixed IP/MAC, NetworkPolicy, ACL, and other enterprise‑grade features through OVS.

Component Architecture

The core components are: /opt/cni/: CNI binary installed on each node. kube-ovn-cniserver (DaemonSet): Handles CNI requests and programs OVS flows. kube-ovn-controller (DaemonSet): Watches CRDs, updates annotations, and synchronises state to the OVN northbound database.

Prometheus exporter on each component for metrics.

Overlay Network

Kube‑OVN creates an overlay using Geneve encapsulation. Each subnet (or VPC) is isolated, and a cluster router interconnects subnets. Pods receive IP/MAC from the OVN northbound database, and subnets can be bound to namespaces for address‑space management.

Underlay Network

Pods may bypass the overlay and attach directly to the physical or virtual underlay. OVS tags each pod’s traffic with a VLAN ID and forwards it through a trunk interface, preserving fixed IP/MAC while allowing overlay and underlay to coexist.

Multi‑NIC Management

Using the Multus Attachment Subnet mechanism, Kube‑OVN supports multiple network interfaces per pod. Desired NIC configurations are expressed in pod annotations; the CNI server and OVN‑IPAM monitor these annotations and provision the additional interfaces, enabling use‑cases such as vertical gateways, VNFs, or database connections across separate networks.

External Connectivity

Two patterns are supported for pod‑to‑external traffic:

Distributed SNAT on each node, where OVS performs source NAT locally.

A dedicated pod gateway that forwards all outbound traffic, optionally performing NAT before exiting the cluster.

Both patterns can leverage VLAN‑tagged underlay paths or overlay paths that interoperate with OpenStack OVN, allowing pods and VMs to share the same VPC.

Basic Usage

Static IP/MAC Assignment

Assign a fixed IP and MAC by adding the following annotation to a pod (or to a Deployment’s pod template):

kube-ovn/ipv4: "10.0.0.10"
kube-ovn/mac: "aa:bb:cc:dd:ee:ff"

The CNI server reads the annotation, reserves the address in the OVN database, and programs OVS. The pod can be rescheduled to any node while retaining the same IP.

Network Security

Kube‑OVN enforces security through:

Standard Kubernetes NetworkPolicy objects.

Per‑subnet and per‑pod ACLs defined in OVN.

Traffic mirroring for audit and analysis.

Dynamic QoS rules in OVS to limit bandwidth and set priority.

Performance Characteristics

OVN scales to roughly 200 nodes and 10,000 pods. To avoid iptables overhead, Kube‑OVN implements DNAT via OVS flow tables (replacing kube‑proxy). For high‑throughput workloads, DPDK offload can be enabled on compatible NICs to accelerate packet processing.

Monitoring

A DaemonSet‑based pod runs an OVN/OVS monitor that checks connectivity between pods, nodes, services, and DNS. Metrics are exposed on /metrics for Prometheus scraping. A kubectl plugin can invoke trace or tcpdump on any pod or node. Example documentation is available at:

https://github.com/alauda/kube-ovn/blob/master/docs/ovn-ovs-monitor.md

Open‑Source Status

Kube‑OVN is released under the Apache 2.0 license. The community edition and the commercial edition provide identical functionality; the latter adds professional support services.

Resources

Official website: https://www.kubeovn.io

GitHub repository: https://github.com/kubeovn/kube-ovn

Slack community: https://kube-ovn-slackin.herokuapp.com