Container Runtime Interface (CRI)

The CRI is a plugin interface which enables the kubelet to use a wide variety of container runtimes, without having a need to recompile the cluster components.

You need a working container runtime on each Node in your cluster, so that the kubelet can launch Pods and their containers.

The Container Runtime Interface (CRI) is the main protocol for the communication between the kubelet and Container Runtime.

The Kubernetes Container Runtime Interface (CRI) defines the main gRPC protocol for the communication between the node components kubelet and container runtime.

The API

Feature state: Stable since Kubernetes v1.23

The kubelet acts as a client when connecting to the container runtime via gRPC. The runtime and image service endpoints have to be available in the container runtime, which can be configured separately within the kubelet by using the --container-runtime-endpoint command line flag.

For Kubernetes v1.26 and later, the kubelet requires that the container runtime supports the v1 CRI API. If a container runtime does not support the v1 API, the kubelet will not register the node.

Upgrading

When upgrading the Kubernetes version on a node, the kubelet restarts. If the container runtime does not support the v1 CRI API, the kubelet will fail to register and report an error. If a gRPC re-dial is required because the container runtime has been upgraded, the runtime must support the v1 CRI API for the connection to succeed. This might require a restart of the kubelet after the container runtime is correctly configured.

List streaming

Feature state: Alpha since Kubernetes v1.36; disabled by defaultMore information about this feature

To use this feature, you (or a cluster administrator) will need to enable the CRIListStreaming feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

The standard CRI list RPCs (ListContainers, ListPodSandbox, ListImages) return all results in a single unary response. On nodes with a large number of containers (for example, more than roughly 10,000 including both running and stopped), these responses can exceed gRPC's default 16 MiB message size limit, causing the kubelet to fail when reconciling state with the container runtime.

With the CRIListStreaming feature gate enabled, the kubelet uses server-side streaming RPCs (such as StreamContainers, StreamPodSandboxes, StreamImages) that allow the container runtime to divide results across multiple response messages, bypassing the per-message size limit. This is particularly useful for:

• High container churn environments (CI/CD systems)
• Large-scale batch processing workloads

If the container runtime does not support streaming RPCs, the kubelet automatically falls back to the standard unary RPCs for backward compatibility.