Introduction
As Kubernetes continues to dominate container orchestration, the networking layer has become increasingly critical to cluster performance and functionality. OVN-Kubernetes (Open Virtual Network for Kubernetes) has emerged as a sophisticated Container Network Interface (CNI) plugin that leverages Open vSwitch (OVS) and its control plane, OVN, to provide advanced networking capabilities. Recently accepted as a CNCF Sandbox project (late 2024), it is the default networking provider for Red Hat OpenShift and is widely adopted in telecommunications and high-performance computing environments due to its unique architectural choices. Understanding what sets OVN-Kubernetes apart from other CNI solutions is essential for architects and cluster operators making infrastructure decisions.
What is OVN-Kubernetes?
OVN-Kubernetes is a CNI plugin that implements Kubernetes networking using OVN (Open Virtual Network), which itself is built on top of Open vSwitch.
Open vSwitch is a mature, production-grade virtual switch that has been used in datacenters and cloud environments for over a decade. Think of it as a software-based network switch that runs on Linux servers, capable of forwarding network packets between virtual machines, containers, and physical networks. OVS supports advanced networking features like VLANs, tunnelling protocols, and quality of service controls, essentially bringing enterprise switch capabilities to software-defined environments.
OVN builds on top of OVS by adding a control plane that manages the network configuration across multiple hosts. While OVS handles the actual packet forwarding (the "data plane"), OVN provides the intelligence to coordinate networking across an entire cluster (the "control plane"). This separation allows for sophisticated network topologies and centralized management while maintaining high performance for packet processing.
The plugin implements all required Kubernetes networking features, including pod-to-pod communication, service networking, network policies, and ingress/egress traffic management. What distinguishes it is the underlying architecture that uses proven datacenter networking technology rather than simpler overlay approaches.
Core Architecture
OVN-Kubernetes can be deployed in two modes: default mode with a centralized control plane, or interconnect mode with a distributed control plane architecture. The default mode is the traditional deployment, while interconnect mode distributes the databases across nodes for improved stability and scalability. Below, we'll focus on the default mode architecture, which is simpler to understand and widely deployed.
Default Mode OVN-Kubernetes Components
In default mode, OVN-Kubernetes operates through several key components:
ovnkube-master: The OVN-Kubernetes controller that watches the Kubernetes API server for network-relevant changes (pods, services, network policies) and translates these into OVN logical network configurations that are stored in the NBDB. It also manages pod subnet allocation to nodes.
OVN Northbound Database (NBDB): Stores the logical elements created by ovnkube-master. This represents the desired state of the network. In default mode, the NBDB runs on control plane nodes using RAFT for high availability with 3 replicas.
ovn-northd: A native OVN component that acts as a translator, converting the logical network elements from the Northbound Database into logical flows that are stored in the Southbound Database.
OVN Southbound Database (SBDB): Contains the physical network mapping and flow programming instructions that translate logical network configurations into actual data plane rules. Like the NBDB, it runs on control plane nodes with 3 replicas in HA mode.
ovn-controller: Runs on each node and connects to the centralized SBDB. It converts the logical flows from SBDB into OpenFlow rules and programs the local OVS instance accordingly.
Open vSwitch (OVS): The data plane that runs on every node and actually forwards packets according to the programmed flows.
Note on Interconnect Mode: For large-scale deployments or scenarios requiring maximum stability, OVN-Kubernetes also supports interconnect mode, where the OVN databases run locally on each node rather than centrally. This distributed architecture eliminates RAFT coordination overhead and isolates database failures to individual nodes, improving both scalability and stability. Each node becomes its own "zone" with local databases, though this comes with additional operational complexity.
What Makes OVN-Kubernetes Different
While plugins like Flannel focus on simplicity and Cilium focuses on eBPF-based software performance, OVN-Kubernetes differentiates itself through architectural flexibility and hardware integration.
Geneve Encapsulation with Flexible Routing Options: OVN-Kubernetes defaults to Geneve (Generic Network Virtualization Encapsulation) for pod-to-pod communication across nodes, rather than the more common VXLAN. Why Geneva? Geneve's extensible header can carry additional metadata for security labels and logical flow identification, while VXLAN's fixed header size limits this capability. What distinguishes OVN-Kubernetes is its flexibility - while Geneve overlay is the default, it can be configured for direct routing modes that eliminate encapsulation overhead when network topology permits, providing both overlay convenience and native routing performance options.
Hardware Offload Capabilities: This is one of the primary reason users choose OVN-Kubernetes over Cilium or Calico for bare-metal clusters. Because it is built on OVS, OVN-Kubernetes can leverage OVS Hardware Offload. It can push packet processing down to the SmartNIC (Network Interface Card) or DPU (Data Processing Unit), such as NVIDIA BlueField. This frees the main CPU from processing network packets (saving CPU cycles for application workloads), and network latency drops to near wire speed. In comparison, Cilium uses eBPF to speed up processing in the OS kernel; OVN-Kubernetes can bypass the CPU entirely for established flows. This makes it particularly suitable for latency-sensitive workloads like real-time analytics and telecommunications applications where microseconds matter.
Hybrid and Multi-Network Support: OVN-Kubernetes provides robust support for hybrid networking scenarios where pods need connectivity to both the cluster network and external networks. Through the integration with Multus CNI, it can attach multiple network interfaces to pods, enabling use cases like separating control plane and data plane traffic or connecting workloads directly to physical networks. This flexibility makes OVN-Kubernetes particularly suitable for network function virtualization (NFV) and telecommunications workloads that require direct hardware access or specific network topologies.
Integrated Load Balancing: Rather than relying on kube-proxy for service load balancing, OVN-Kubernetes can implement service load balancing directly in OVS using OVN's native load balancer objects. This approach bypasses iptables or IPVS entirely, reducing the complexity of the networking stack and improving performance, particularly for clusters with a large number of services.
Advanced Egress Traffic Control: OVN-Kubernetes provides sophisticated controls for traffic leaving the cluster through three key features:
EgressIP: Allows you to assign a specific, static public IP to a namespace or pod for outbound traffic (crucial for connecting to legacy firewalls that whitelist IPs).
EgressFirewall: Allows admins to block a specific pod from accessing specific external websites or IP ranges. For example, this pod cannot talk to the public internet, only the corporate intranet.
EgressQoS: Applies DSCP (Differentiated Services Code Point) markings to outbound traffic for quality-of-service handling by external network equipment Ovn-kubernetes. Useful when external routers need to prioritize certain traffic flows.
Conclusion
OVN-Kubernetes represents a sophisticated approach to Kubernetes networking that brings datacenter-grade software-defined networking to container orchestration. Its architecture, based on OVN and OVS, provides advanced features, excellent scalability, and flexibility that simpler CNI plugins cannot match. The tradeoff is operational complexity and the need for specialized knowledge. Organizations should choose OVN-Kubernetes when they need its advanced features, are operating at scale, have existing OVS expertise, or require the multi-network and hardware offloading capabilities it provides.
Top comments (0)