Extension Interfaces (CNI, CSI, CRI)

Overview

Kubernetes defines standard interfaces so that networking, storage, and container runtime implementations can be swapped without changing core code.

Interface	Full Name	Purpose	Examples
CRI	Container Runtime Interface	Lets kubelet manage containers via any compliant runtime	containerd, CRI-O
CSI	Container Storage Interface	Lets storage providers expose volumes without in-tree plugins	EBS CSI, NFS CSI, Ceph CSI
CNI	Container Network Interface	Lets network providers configure pod networking	Calico, Flannel, Cilium

CRI — Container Runtime Interface

How it works

• The kubelet communicates with the container runtime via a gRPC interface over a Unix socket
• CRI defines two services: RuntimeService (pod/container lifecycle) and ImageService (image pull/remove)
• Any runtime implementing the CRI gRPC API can be used with Kubernetes

Supported runtimes

Runtime	Socket Path	Notes
containerd	unix:///run/containerd/containerd.sock	Default in most distributions (kubeadm, EKS, GKE, AKS)
CRI-O	unix:///var/run/crio/crio.sock	Lightweight, purpose-built for Kubernetes

Checking the configured runtime

# shows ContainerRuntime in the STATUS column
kubectl get nodes -o wide

# check kubelet's configured runtime socket
ps aux | grep kubelet | grep container-runtime-endpoint

# or inspect kubelet config
cat /var/lib/kubelet/config.yaml | grep containerRuntimeEndpoint

crictl — CRI CLI tool

crictl is the standard CLI for interacting with any CRI-compatible runtime directly on a node.

# configure crictl to use the runtime socket
sudo crictl config runtime-endpoint unix:///run/containerd/containerd.sock

Command	Description
crictl ps	List running containers
crictl pods	List pods
crictl images	List images
crictl inspect <container-id>	Inspect a container
crictl logs <container-id>	View container logs
crictl pull <image>	Pull an image
crictl stats	Display container resource usage

CSI — Container Storage Interface

How it works

• CSI replaces the old in-tree volume plugins with an out-of-tree plugin model
• A CSI driver consists of two components:
  • Controller plugin — runs as a Deployment; handles provisioning/deleting volumes, attach/detach
  • Node plugin — runs as a DaemonSet on every node; handles mount/unmount on the node
• Storage providers ship their own CSI drivers that implement the CSI spec

Common CSI drivers

Driver	Storage Backend
ebs.csi.aws.com	AWS EBS
pd.csi.storage.gke.io	GCP Persistent Disk
disk.csi.azure.com	Azure Disk
nfs.csi.k8s.io	NFS
rbd.csi.ceph.com	Ceph RBD

Checking CSI drivers

# list all CSI drivers registered in the cluster
kubectl get csidrivers

# show which CSI drivers are available on each node
kubectl get csinodes

# list storage classes (shows which provisioner/CSI driver each uses)
kubectl get storageclasses

StorageClass using a CSI driver

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com    # CSI driver name
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

For more on PersistentVolumes, PVCs, and StorageClasses, see Volumes.

CNI — Container Network Interface

• CNI plugins configure pod networking — assigning IPs, setting up routes, and connecting pods
• The kubelet invokes the CNI plugin binary when a pod is created or deleted
• Plugin binaries live in /opt/cni/bin/, config files in /etc/cni/net.d/

For detailed coverage of CNI plugins (Calico, Flannel, Cilium, etc.), see CNI.

Useful Commands

# check container runtime for each node
kubectl get nodes -o wide

# list CSI drivers
kubectl get csidrivers

# list CSI node info
kubectl get csinodes -o wide

# check CNI plugin config on a node
ls /etc/cni/net.d/

# check CNI plugin binaries on a node
ls /opt/cni/bin/

# inspect kubelet runtime endpoint
cat /var/lib/kubelet/config.yaml | grep containerRuntimeEndpoint

# list pods for CSI driver components
kubectl get pods -A | grep csi