Kubernetes 1.26 requires CRI v1 and adds resource claims

Removing dockershim did not finish Kubernetes' runtime compatibility work. A node can use a CRI runtime and still depend on an older version of that protocol. Kubernetes 1.26 removes CRI v1alpha2 support, so a runtime that only speaks that version can no longer support a 1.26 kubelet.

The December 9 release announcement pairs this required compatibility change with an optional experiment in resource allocation. Dynamic Resource Allocation enters alpha with a claim-based API. The first change narrows an existing protocol contract. The second adds an extensibility model for resources that are awkward to describe as an integer count.

I find the distinction useful because Kubernetes' extension points need both stability and room for new capabilities. A node must satisfy the supported runtime protocol before it can participate. A resource driver can explore the new allocation API only where the cluster has deliberately enabled that experiment.

A CRI runtime also needs the right protocol version

Before this release, kubelet could negotiate CRI v1alpha2 when the runtime did not support v1. The announcement says that fallback is now removed. A 1.26 kubelet will not register its node when the runtime lacks CRI v1 support.

That is a more precise failure than a general statement that old runtimes are discouraged. The node cannot complete the registration path under that kubelet. Operators need to account for the runtime protocol before upgrading the node component that requires it.

For containerd, the release identifies 1.5 and older minor versions as unsupported with Kubernetes 1.26. It requires containerd 1.6.0 or later before the kubelet upgrade. The same protocol requirement applies to other runtimes, even when their product version numbering differs.

The November advance notice also points to tools that proxy the connection between kubelet and the runtime. Such an intermediary participates in the compatibility path. A compliant underlying runtime does not prove that every component between it and kubelet handles the required interface.

This is a consequence of treating runtime integration as a versioned protocol. A family name such as containerd identifies an implementation project. It does not establish which protocol its installed release exposes, or which version a proxy can pass through.

Node upgrades and control plane upgrades have distinct boundaries

The November notice explicitly describes supported skew as a way to run an older kubelet against a newer control plane. A 1.25 kubelet retains the older CRI fallback even when the control plane reaches 1.26. That supplies a sequencing option within the documented compatibility rules.

The distinction does not make the runtime requirement disappear. It locates that requirement at the node's kubelet version. An operator can separate control plane adoption from the later point at which a particular node must support CRI v1.

This is useful when infrastructure includes different node images or runtime versions. A control plane version is insufficient evidence that every node has the same runtime protocol. The operating inventory needs to associate kubelet and runtime versions with the nodes that actually run them.

The May removal of dockershim and December removal of v1alpha2 are therefore related but different transitions. The former ended kubelet's built-in Docker Engine adapter. December ends an old version of the runtime interface. Completing one migration does not establish that the other requirement is satisfied.

DRA describes a resource request as an object

The release introduces Dynamic Resource Allocation behind the DynamicResourceAllocation feature gate. Its motivation is to offer an alternative to requests such as nvidia.com/gpu: 2. An integer describes quantity, but it gives limited room for allocation parameters and coordination.

The 1.26 alpha API types show how the new model works. ResourceClaim describes what a consumer needs. Its spec references a ResourceClass and can reference a separate parameter object. Its status records whether allocation has occurred and the resulting attributes.

ResourceClass identifies the driver responsible for allocation. It can also carry a reference to driver-specific parameters and a selector limiting suitable nodes. This separates administrator-level allocation configuration from the individual consumer's claim.

The design resembles persistent volume claims in the sense identified by the release announcement. A request becomes a named API object with a lifecycle and allocation state. That does not mean device allocation has the same semantics as storage, or that existing volume drivers automatically implement DRA.

The claim's desired attributes are set at creation. Allocation state belongs in status. That separation fits the broader Kubernetes model of declaring requirements and letting a controller report the result of acting on them.

A minimal claim using the announced schema can look like this:

apiVersion: resource.k8s.io/v1alpha1
kind: ResourceClaim
metadata:
  name: accelerator
spec:
  resourceClassName: example-accelerator
  allocationMode: WaitForFirstConsumer

This specimen requires an enabled alpha API and a suitable ResourceClass with a corresponding driver. It is not a working device request in an otherwise unmodified cluster. The example illustrates the resource relationship without inventing driver-specific parameters.

Allocation can wait for a consumer

The API defines Immediate and WaitForFirstConsumer allocation modes. The latter is the default. With immediate allocation, the driver can allocate before the consuming pod's needs are known. Waiting allows placement and allocation requirements to be considered together.

That timing matters for resources whose availability depends on a node. Allocating a device without regard to the eventual consumer can constrain placement prematurely. Deferring allocation lets scheduling consider the pod's combined requirements before requesting allocation for a selected node.

The alpha API includes PodScheduling objects for coordinating that process. Their spec can identify potential nodes and a selected node. Status reports nodes unsuitable for individual claims. This makes the coordination visible through API objects instead of hiding every allocation decision inside a scheduler-local procedure.

The result still depends on a driver. Kubernetes supplies the API and coordination points, while the driver supplies resource-specific allocation behaviour. An enabled feature gate alone cannot manufacture devices or establish support for a particular accelerator.

Allocation results preserve driver-specific information

ResourceClaim status includes a driver name and an allocation result. The result can contain an opaque resource handle. Kubernetes does not interpret that handle's arbitrary contents, leaving their meaning to the resource driver.

The allocation result can also constrain the nodes on which the resource is available and declare whether it is shareable. Consumer reservations identify which entities are allowed to use the claim. A pod referencing a claim not reserved for it will not start, according to the type documentation.

Those fields show that the proposal is about allocation lifecycle as well as richer resource descriptions. The system needs to know who may consume the result and where it remains valid. The handle by itself cannot express all of those coordination requirements.

The release announcement says device injection uses the Container Device Interface. That is another boundary in the design, distinct from the claim's desired parameters and scheduling coordination. The published alpha should be understood through its 1.26 types, without assuming future revisions preserve every field.

My interest is in making resource-specific control explicit without embedding each device policy into Kubernetes itself. A claim and a driver provide places for that work to live. The alpha maturity means those interfaces remain an experiment requiring deliberate deployment choices.

Distribution and storage have their own compatibility changes

The release announcement describes 1.26 as the first release published exclusively to registry.k8s.io. Operators reading image references need to account for the registry's redirect-based distribution model and its implications for restricted networks. A reachable old registry address is not the distribution contract stated for this release.

Storage work continues to move integration responsibilities outward. Azure File and vSphere CSI migration become stable. The release also graduates delegation of fsGroup handling to capable CSI drivers, allowing the driver to apply the setting during volume handling instead of always requiring kubelet to change ownership and permissions.

These are separate changes with distinct owners. A runtime protocol upgrade does not establish registry reachability or storage driver support. Each affects a different stage in turning a declared workload into running containers with the required resources.

The release's required runtime floor is concrete. Nodes moving to the 1.26 kubelet need CRI v1 across their runtime path. DRA is an additional alpha API for installations that need driver-managed allocation beyond countable resources. Its claim lifecycle and scheduling coordination can be evaluated independently of the protocol migration every affected node must complete.