TL;DR: CRI, CNI, and CSI are standardized interfaces that allow Kubernetes to work with different container runtimes, network implementations, and storage systems without tightly coupling Kubernetes to a specific implementation.
As we discussed, Kubernetes is a collection of software rather than a single application. To make this ecosystem work together, Kubernetes uses standardized interfaces instead of depending directly on specific implementations.
Three important interfaces are CRI, CNI, and CSI.
CRI, CNI, CSI
CRI, CNI, and CSI separate Kubernetes from the implementations responsible for containers, networking, and storage.
This allows different runtimes, network plugins, and storage drivers to integrate with Kubernetes without requiring their implementation to become part of the Kubernetes core codebase.
1. CRI (Container Runtime Interface)
The CRI is the interface between the kubelet and the container runtime on a Kubernetes node.
The kubelet uses CRI to request operations such as creating pod sandboxes, starting and stopping containers, and managing their lifecycle.
Early versions of Kubernetes had tighter integration with Docker. CRI introduced a standardized interface so different container runtimes could integrate with Kubernetes.
Examples: containerd, CRI-O.
2. CNI (Container Network Interface)
The CNI is a specification for configuring network interfaces for containers.
When a pod sandbox is created, the container runtime invokes the configured CNI plugin to configure the pod’s network. Depending on the implementation, this can include creating network interfaces such as veth pairs, assigning IP addresses, configuring routes, and connecting pods to the node or other networks.
CNI allows Kubernetes to maintain its pod networking model while delegating the actual network configuration to network plugins.
Some CNI-based solutions provide additional capabilities such as network policy enforcement, but NetworkPolicy enforcement is not part of the CNI specification.
Examples: Cilium, Calico, Flannel, AWS VPC CNI.
3. CSI (Container Storage Interface)
The CSI is a standard interface between Kubernetes and storage systems.
CSI drivers provide operations such as provisioning volumes, attaching and detaching them, mounting and unmounting them, expanding them, and deleting them.
CSI drivers generally have controller-side and node-side components. The controller handles operations such as provisioning and attaching storage, while the node component handles mounting the volume on the Kubernetes node.
Historically, many Kubernetes storage drivers were implemented in-tree, meaning their code was part of the Kubernetes codebase.
CSI moved storage integrations out-of-tree, allowing storage vendors and projects to develop and release their drivers independently of Kubernetes itself.
Examples: AWS EBS CSI Driver, Ceph CSI, Longhorn CSI, Azure Disk CSI.
Back to Certified Cloud Native Platform Engineering Associate Preparation