How Kube-OVN Enables Financial‑Grade Cloud‑Native Networking for Large Banks

Background

Large banks require a container‑cloud infrastructure that meets financial‑grade availability, stability and compliance. While traditional IaaS already provides mature mechanisms such as image replication, VM migration and global DNS failover, a cloud‑native stack must add higher resource utilization, elasticity and fine‑grained network control across multiple clusters and business systems.

Key Challenges

Existing Kubernetes CNI solutions are difficult to integrate with legacy data‑center networking, making network management opaque.

Achieving fine‑grained policy enforcement across multi‑cluster, multi‑tenant environments is complex.

Active‑active micro‑service deployments increase the difficulty of cross‑cluster service governance.

Dual‑Stack Overlay/Underlay Architecture

The design separates traffic into two logical planes:

Overlay network – built on Open vSwitch (OVS) tunnels for non‑core workloads. It provides isolation, easy scaling and independent namespace policies.

Underlay network – connects pods directly to the physical fabric (VLAN or VxLAN) for latency‑sensitive, critical services, enabling seamless integration with existing data‑center controls.

This dual‑stack bridges the container cloud and the traditional IaaS layer, allowing consistent network policies and global load balancing for active‑active banking applications.

Kube‑OVN Overview

Kube‑OVN is an open‑source CNI plugin that uses OVS as the data‑plane. It is community‑driven, natively integrates with Kubernetes, and supports both overlay and underlay modes. Each Kubernetes namespace can have independent network policies, and the solution offers distributed or centralized gateways, NAT, and per‑pod IP/MAC control via annotations.

Technical Details

Overlay implementation : OVS creates Geneve/VXLAN tunnels; pod CIDRs are allocated per‑namespace, and traffic is encapsulated over the physical network.

Underlay implementation : Pods are attached to physical VLANs; OVS ports are configured with external_ids to bind a pod to a specific VLAN, enabling zero‑copy forwarding and DPDK acceleration when required.

Network policy control : Annotations such as kube-ovn.io/ip_address and kube-ovn.io/mac_address allow static IP/MAC assignment; kube-ovn.io/gateway_type selects distributed or centralized gateway mode.

QoS and bandwidth shaping : OVS queues are programmed via OpenFlow to enforce bidirectional bandwidth limits per pod or per service, supporting dynamic QoS adjustments.

Traffic mirroring : OVS flow rules can duplicate all pod traffic to a monitoring port, facilitating security audit and deep packet inspection without impacting the data path.

Service flow tables : Instead of iptables, Kube‑OVN installs OpenFlow entries that implement Kubernetes Service load‑balancing, eliminating the performance penalty of kernel‑level NAT.

Hardware acceleration : When DPDK is enabled, OVS bypasses the kernel, providing line‑rate throughput and sub‑microsecond latency for underlay traffic.

Performance Validation

Stress tests on core banking workloads demonstrated that underlay mode delivers throughput comparable to Calico while retaining the advanced features of OVS (mirroring, QoS, DPDK). Service‑level flow tables removed iptables overhead, and the dual‑stack design allowed non‑critical workloads to run on the overlay, conserving bandwidth.

Conclusion

Adopting a Kube‑OVN‑based dual‑stack network enables banks to allocate overlay networks for non‑critical containers and underlay networks for latency‑sensitive, regulated services. The architecture provides consistent policy enforcement, high‑performance cross‑cluster connectivity, and the ability to integrate with existing data‑center controls, supporting high‑concurrency, high‑availability cloud‑native transformations in the financial sector.

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