🏷️ Understand extension interfaces (CNI, CSI, CRI, etc…)

🏷️ Understand extension interfaces (CNI, CSI, CRI, etc…)#

Container Runtime Interface#

Container Runtime Interface

The Container Runtime Interface (CRI) is a standardized API layer in Kubernetes that uses gRPC to enable communication between the kubelet, the node agent, and various container runtimes like containerd and CRI-O. It abstracts container lifecycle operations—such as pulling images, starting, and stopping containers—allowing Kubernetes to work with multiple container runtimes without requiring modifications to the core codebase.

See also

🌐 https://kubernetes.io/docs/concepts/architecture/cri/

Container Runtimes:

Container Network Interface#

Container Network Interface

A Container Network Interface (CNI) plugin is responsible for inserting a network interface into the container network namespace (e.g., one end of a virtual ethernet (veth) pair) and making any necessary changes on the host (e.g., attaching the other end of the veth into a bridge). It then assigns an IP address to the interface and sets up the routes consistent with the IP Address Management section by invoking the appropriate IP Address Management (IPAM) plugin.

See also

🌐 https://kubernetes.io/docs/concepts/services-networking/#the-kubernetes-network-model

Network plugins:

Container Storage Interface#

Container Storage Interface

The Container Storage Interface (CSI) is a standard API specification that enables third-party storage providers to develop and deploy plugins that expose arbitrary block and file storage systems to containerized workloads running on Kubernetes. It decouples storage management from the core Kubernetes codebase, allowing storage vendors to create and maintain their own drivers independently of Kubernetes release cycles.

Provisioner:

Contents