Deep Dive into kube-ovn-cni: How Pod Network Interfaces Are Created and Managed

Introduction

Kube-OVN is a Kubernetes networking solution built on OVS/OVN that brings mature OpenStack networking capabilities to Kubernetes, enhancing security, operability, manageability, and performance. This series introduces the kube-ovn-cni component, which acts as a CNI plugin deployed as a DaemonSet.

CNI Process

When kubelet creates a pod, it selects the configuration file with the smallest index (01-kube-ovn.conflist) in /etc/cni/net.d/ and invokes the kube-ovn binary via the CNI cmdAdd interface.

cmdAdd Interface

The cmdAdd implementation in the kube-ovn binary simply builds an HTTP API request to the kube-ovn-daemon component and returns the response to kubelet.

Daemon (cni‑server) Response

The kube-ovn-daemon runs as a local Unix‑socket server, listening for API calls from /opt/cni/bin/kube-ovn . It processes the add request and coordinates with the OVN/OVS backend.

handleAdd Callback

During pod creation, the handleAdd callback creates a veth pair, places one end inside the pod’s network namespace, configures IP and routing, and attaches the other end to the br-int OVS bridge, linking it to the corresponding OVN port via external_ids:iface-id .

configureNic Function

The core of pod network‑card management resides in the configureNic function, which creates the veth pair, moves one end into the pod’s netns, sets IP and routes, and configures QoS limits on the host side. It also invokes configureContainerNic to apply the settings inside the pod namespace.

Conclusion

kube-ovn-cni functions as a CNI server that works with /opt/cni/bin/kube-ovn to handle pod network interface creation, IP allocation, OVS port creation, and routing configuration, providing a complete solution for Kubernetes pod networking.