Kubernetes Changed Block Tracking API

Reporting by Kubernetes BlogRead the original at kubernetes.io

Executive Summary

The Changed Block Tracking (CBT) support for CSI drivers shipped as Alpha in September 2025 and moved to Beta following the release of `external-snapshot-metadata` in March 2026. The feature focuses on block volumes, excluding file-volume and network file-share tracking. The main change in the Beta was the promotion of the `SnapshotMetadataService` CRD from v1alpha1 to v1beta1, changing its API path to `cbt.storage.k8s.io/v1beta1`, while removing the older version. Upgrading from Alpha requires re-applying the CRD definition shipped with v1.0.0 and updating manifests and client code to use the new API version. Compatibility requires Kubernetes version 1.33 or newer, CSI spec 1.10 or newer, and the container image `registry.k8s.io/sig-storage/csi-snapshot-metadata:v1.0.0`. Users should ensure their CSI driver supports volume snapshots and ships the sidecar before installing the CRD and creating the necessary resources to utilize the API.

Facts Only

* Changed Block Tracking (CBT) support for CSI drivers shipped as Alpha in September 2025.
* CBT moved to Beta with the March 2026 v1.0.0 release of `external-snapshot-metadata`.
* The main change in Beta was promoting the `SnapshotMetadataService` CRD from v1alpha1 to v1beta1, serving `cbt.storage.k8s.io/v1beta1`.
* Upgrading requires reapplying the CRD definition from v1.0.0 and updating manifests to use `apiVersion: cbt.storage.k8s.io/v1beta1`.
* Minimum Kubernetes version is 1.33.
* CSI spec must be 1.10 or newer.
* The required container image is `registry.k8s.io/sig-storage/csi-snapshot-metadata:v1.0.0`.
* Users must ensure the CSI driver supports volume snapshots and ships the `external-snapshot-metadata` sidecar.
* Getting started involves installing the v1beta1 CRD definition and creating a `SnapshotMetadataService` resource.

Full Take

The shift from Alpha to Beta highlights a necessary restructuring of an API artifact, specifically the evolution of the `SnapshotMetadataService` CRD. The removal of the `v1alpha1` version in favor of `v1beta1` signifies a commitment to a specific progression path for the storage ecosystem, forcing immediate migration steps for all dependent components. The necessity of manually reapplying definitions and updating client code underscores a systemic impedance mismatch rather than a simple feature update; it requires acknowledging that API evolution is not seamless regression but an explicit, multi-step integration task.
The focus on operator adoption and operational feedback during the Beta phase suggests a pattern where complex infrastructure features gain traction through hands-on development within the community, rather than purely through specification release. The explicit encouragement for CSI driver adoption and feedback implies that broad utility is gated by tangible implementation in real-world storage solutions. This creates an implicit reliance on existing, high-quality drivers to drive widespread functionality. A critical implication is the risk of fracturing compatibility if external implementations lag behind these version transitions, potentially creating silos between Kubernetes core features and vendor-specific operational tooling.
What follows is the necessary engineering bridge: If broad adoption is the goal, ensuring that client-side abstraction layers can handle these version shifts transparently—or at least provide robust migration tooling—becomes paramount. The community effort detailed underscores a pattern of distributed specification management; true sovereignty requires not just releasing new specifications but establishing clear, unambiguous, and automated transition paths between them to prevent operational friction from becoming a barrier to adoption. What resources are currently in place to automate or simplify this mandatory, one-time migration process across diverse CSI driver implementations?

From the original · Kubernetes Blog

Beta Differences Changed Block Tracking (CBT) support for CSI drivers shipped as Alpha in September 2025. With the March 2026 v1.0.0 release of the external-snapshot-metadata project, the feature moved to Beta.

Read the full story at kubernetes.io

Sentinel — provisional

Raw score, 0 to 1 (uncalibrated)0.15

No strong signs of machine writing were found in the source article. Provisional estimate, not a finding that a person wrote it.

The model's own note (unverified)

The text reads like a technical announcement or update written by someone deeply familiar with the Kubernetes storage ecosystem, likely originating from project communications rather than generalized reporting.

This looks only at the wording of the original source article, not at this page's AI-written sections. A small local AI model made this estimate. It has not been checked against known human and machine texts, so treat it as provisional. It cannot show who wrote an article.

What the model noticed in the source article

Moderate sentence length variance; clear technical focus balanced with instructional flow.

Highly coherent and focused on a specific technical progression; demonstrates an understanding of complex API migration requirements.

Directly follows a structured announcement format (What changed, How to upgrade, Compatibility, Next steps), suggesting adherence to established technical documentation patterns.

Specific version numbers, API names (CBT, CSI, gRPC), and internal project references are highly specific; no obvious confabulation detected.

Signs the model read as against machine writing

The inclusion of a detailed list of contributors by name strongly suggests an origin within a community or working group context.

The tone shifts naturally between explaining technical changes and offering calls to action for future development.