Introduction to Cloud‑Native Networking, DPDK, and the Contiv/VPP Kubernetes Plugin

Introduction

Cloud‑native brings many advantages: rapid deployment, horizontal scalability, elasticity, faster DevOps, and optimized resource utilization. Micro‑service architecture is a new way to deploy applications and services in the cloud, packaging each micro‑service into a container that runs in a POD on a host.

Applications are the king of cloud‑native, yet networking knowledge is often missing. Why? Because application developers usually do not care about networking, networking is a specialized field, and the speed of classic network deployment does not match cloud‑native demands.

Kubernetes (k8s) defines the Container Network Interface (CNI) – an API for network plugins that enable POD‑to‑POD communication.

CNI is a standard, universal interface that allows container platforms such as Docker, Kubernetes, and Mesos to provide networking functionality as long as they implement the protocol.

The cloud‑native community now recognizes the importance of networking. Innovations such as DPDK (Data Plane Development Kit) and BPF have made throughput and performance critical concerns.

DPDK Overview

DPDK is an Intel‑developed toolkit that provides libraries and drivers for high‑efficiency packet processing in user space on IA‑architecture processors, focusing on data‑plane performance for network applications.

It moves packet processing, memory management, and CPU scheduling to user space, leaving the kernel to handle only control instructions, thereby eliminating interrupts, context switches, and system‑call overhead.

To run drivers in user space, Linux offers the UIO (User‑space I/O) mechanism, which allows drivers to receive interrupts via read and communicate with NICs via mmap.

DPDK Poll‑Mode Drivers (PMDs)

PMDs change the traditional I/O model. Instead of sleeping after submitting I/O requests and being woken by interrupts, applications continue working and periodically poll to check I/O completion, avoiding interrupt‑related overhead and improving packet‑processing speed.

Traditional Linux Network Stack

Hardware interrupt → Packet fetched → Kernel thread → Software interrupt → Kernel thread processes packet in protocol stack → Completion notifies user space
User‑space receives packet → Network layer → Logic layer → Business layer

DPDK Network Stack

Hardware interrupt → Interrupt flow abandoned

User‑space obtains packet via device mapping → Enters user‑space protocol stack → Logic layer → Business layer

Linux Virtual Network Devices (tun/tap)

Linux kernel includes a network device management layer that sits between drivers and the protocol stack, acting like a pipe. Physical NICs (e.g., eth0) connect the kernel stack to the external network, while tun/tap devices forward selected packets to user space, giving applications a chance to process them.

Contiv/VPP Kubernetes Network Plugin

VPP is a full‑stack, DPDK‑based packet‑processing solution from the Linux Foundation, often called a “plug‑and‑play” package. Contiv/VPP uses VPP to provide networking between PODs in a Kubernetes cluster and runs as a set of system PODs in the kube‑system namespace.

contiv‑KSR, contiv‑CRD, contiv‑ETCD run on the master node.

contiv‑CNI, contiv‑vswitch, contiv‑st run on every cluster node.

Contiv/VPP integrates fully with Kubernetes, automatically re‑programming the network via the Kubernetes API whenever the cluster changes.

The main component, VPP, runs inside the contiv‑vswitch POD on each node, providing:

POD‑to‑POD connectivity within the cluster.

Host‑to‑POD and external‑POD connections.

It leverages VPP’s fast data‑plane processing, runs entirely in user space, and uses DPDK for rapid network I/O access.

Kubernetes Services and Networking

Comparison of solutions: