Understanding Cloud‑Native Networking: Practices, Open‑Source Implementations, and Challenges from Lingque Cloud’s Kube‑OVN Project

On June 11, Liu Mengxin, the lead of Lingque Cloud’s Kube‑OVN project, delivered an online presentation sharing the company’s practice and thinking on cloud‑native networking. With the widespread adoption of containers, Kubernetes, and micro‑services, the cloud‑native era has begun, demanding a powerful network to support communication between virtual nodes and micro‑services.

Cloud‑native networking differs from traditional networking in that container networks change very frequently. Pods are created, destroyed, and moved often, requiring high automation, self‑healing capabilities, and cross‑platform portability so that networks can migrate across public clouds, private clouds, and bare‑metal environments.

The basic requirements for container networking are: each pod must have a unique IP address; all pods must be reachable at layer‑3 without NAT; and the network must provide services such as Service, DNS, NetworkPolicy, and Ingress, while remaining platform‑agnostic.

Regarding open‑source implementations, the CNCF defines the CNI (Container Network Interface) standard, which enables pluggable network plugins like Flannel, Cilium, and Calico. Implementations can be classified by control‑plane and data‑plane mechanisms. Control‑plane designs include distributed KV stores (e.g., Flannel, Cilium using etcd; Kube‑OVN using OVS DB with Raft), router‑based discovery (Calico, Kube‑Router using routing protocols), hardware‑based approaches (Macvlan, IPvlan), and gossip protocols (Weave). Data‑plane designs are split into encapsulation modes (VXLAN, Geneve, IPIP) and underlay modes (host‑gateway, VLAN, BGP).

The speaker highlighted four major challenges when applying cloud‑native networking in practice: (1) functional gaps such as fixed IP, multi‑tenant isolation, encryption, and hybrid cluster connectivity; (2) monitoring and troubleshooting complexities, especially network reachability issues in dynamic topologies; (3) security concerns where traditional policies differ from Kubernetes NetworkPolicy and traffic audit mechanisms; and (4) performance considerations, particularly control‑plane scalability for large clusters versus data‑plane throughput.

The session concluded with a video recap, an announcement of the upcoming second part focusing on Kube‑OVN network practice, and instructions to follow the public account for PPT download, join the WeChat group, and explore related reading links.