Designing High‑Availability, High‑Performance Cloud‑Native Container Networks for Banking

Driven by digital transformation, state‑owned, joint‑stock, and commercial banks are rapidly adopting containerization, but designing, building, and optimizing a cloud‑native container platform presents a major challenge for achieving agile, lightweight, fast, and efficient development, testing, delivery, and operations.

The container network is the foundation of any cloud‑native platform, and its complexity grows as banking applications increase in number and type; banks must reconcile traditional network architectures with container networks, manage fixed IPs, multi‑network planes, multi‑NICs, multi‑tenant and cross‑cloud traffic, monitoring, scheduling, and QoS.

Many banks currently treat their internal container networks as a “black box,” lacking connectivity between container and external networks and unable to interconnect multi‑cloud clusters, highlighting the urgent need for transformation.

This article addresses three key questions: how to improve availability of container networks in a two‑site three‑center architecture, how to plan container networks for high‑concurrency banking scenarios, and how to build high‑performance container networks.

From a technical perspective, both underlay and overlay approaches should be considered. If the container platform runs on traditional virtualization without SDN, a host‑network mode allows direct communication between PODs and legacy VMs/physical machines. When the host nodes use SDN and CNI, NAT or EIP may be required for communication with traditional workloads, and IP statefulness becomes a major issue.

For banks in a two‑site three‑center setup, the Kube‑OVN underlay solution—leveraging OpenStack OVS—flattens container and legacy workloads onto a single L2 plane, preserving existing network management while providing direct IP communication.

In high‑concurrency scenarios, banks should adopt a hybrid underlay/overlay strategy, reference IaaS three‑/four‑network separation concepts, use unified ingress/egress points for steady‑state and dynamic traffic, and apply NetworkPolicy for fine‑grained security.

Cluster‑level recommendations include using traditional networks with OVS for high‑performance clusters, and SDN‑based VPC isolation with CNI off‑loading for high‑capacity clusters.

Performance tests show Kube‑OVN matches Calico’s throughput, supports OVS, DPDK, and hardware acceleration, and meets strict banking stress‑test requirements, while also addressing security and regulatory controls.

Ultimately, banks should tailor these practices to their own environments to achieve high‑availability, high‑concurrency, and high‑performance cloud‑native container networking for a robust digital transformation.