Kubernetes’ Changed Block Tracking (CBT) work defines an API for retrieving allocated blocks from a snapshot and changed blocks between two snapshots of the same block volume. That data can support incremental backup workflows without requiring a backup system to process an entire volume every time.
The dated Kubernetes announcement is identified as covering beta differences, but the supplied technical evidence does not establish the announcement’s exact beta-to-beta changes, release status, Kubernetes version prerequisites, or a complete migration path. The implementation material does, however, document the API model, its Kubernetes custom resource, authentication fields, and the dependencies that storage and backup teams need to evaluate.
What the documented CBT design provides
The Changed Block Tracking KEP proposes an optional CSI SnapshotMetadata gRPC service. The service is intended to provide two kinds of information:
- Allocated-block metadata for a snapshot.
- Changed-block metadata between a base snapshot and a target snapshot of the same block volume.
The Kubernetes-facing service is implemented by the community-provided external-snapshot-metadata sidecar, which is deployed with a CSI driver. Backup applications access that service over a TLS gRPC connection rather than querying the CSI driver’s internal implementation directly.
The SnapshotMetadata protobuf schema defines GetMetadataAllocated and GetMetadataDelta. Both operations return streamed responses containing block ranges, a block metadata type, and volume capacity. Streaming allows a client to continue requesting results from an offset and to constrain the amount of data returned through an optional maximum-result value.
The Kubernetes API surface
The Kubernetes resource associated with the service is a cluster-scoped SnapshotMetadataService custom resource in the cbt.storage.k8s.io/v1beta1 API. The supplied CRD definition marks that version as served and as the storage version.
Three fields are required when defining the service:
address, identifying the service endpoint.audience, describing the expected audience for the authentication token.caCert, providing the certificate authority data used to validate the service.
The CRD also includes an optional requireBaseSnapshotForDelta field. It indicates whether backup clients should retain the base snapshot in order to calculate CBT deltas. That setting matters operationally: a backup system cannot safely discard the base snapshot until it has confirmed that the configured service and driver no longer need it for the relevant workflow.
Requests require authenticated access
Both metadata request types include a required security_token. For allocated metadata, the request also includes a namespace, snapshot name, starting offset, and optional maximum-result count. Delta requests include a namespace, base snapshot ID, target snapshot name, starting offset, and optional maximum-result count.
The token is intended for authentication and authorization, while the CRD’s audience field identifies the expected token audience. The KEP describes TLS-protected gRPC communication between backup applications and the SnapshotMetadata service. These details establish the documented access model, but they do not by themselves establish broader security guarantees or vendor-specific behavior.
Who is affected
The change is relevant to several components in a Kubernetes storage and backup stack:
- CSI driver maintainers: The driver must provide the relevant SnapshotMetadata functionality. The CSI specification identifies the SnapshotMetadata service and its operations as optional or experimental in the supplied specification content.
- Platform administrators: Administrators must account for the cluster-scoped
SnapshotMetadataServiceresource, its endpoint, certificate authority data, and token audience. - Backup-client developers: Clients must construct requests with the required security token and snapshot identifiers, then handle streamed block-range responses and continuation through
starting_offset. - Backup operators: Operators need to determine whether the configured service requires the base snapshot to remain available for delta computation.
Support is not universal by default. The feature depends on CSI driver functionality, and compatibility with backup products, client libraries, sidecars, and drivers remains implementation-specific.
What you should do
- Confirm driver support. Check whether the CSI driver you use implements the relevant SnapshotMetadata service. The documented design is optional, so the presence of CSI snapshots alone does not establish CBT support.
- Review the API contract. Ensure client code handles both streamed RPCs, required token fields, snapshot names or IDs, offsets, and optional result limits.
- Validate the service resource. Before deployment, verify that the
SnapshotMetadataServiceobject includes the required address, audience, and CA certificate values. - Plan snapshot retention. Inspect
requireBaseSnapshotForDeltaand align backup retention behavior with the service’s requirement for base snapshots. - Test version combinations independently. Confirm compatibility among the CSI driver, external-snapshot-metadata sidecar, backup client, and Kubernetes environment. The supplied documentation does not provide a complete version-skew matrix or universal migration procedure.
- Do not assume beta compatibility. The available implementation sources document the API and CRD surfaces, but they do not establish the specific beta differences described by the dated announcement.
Availability and migration caveats
The supplied specifications describe the CSI and Kubernetes SnapshotMetadata interfaces as optional or experimental. They do not establish which Kubernetes release contains the beta, whether a feature gate is required, or what minimum Kubernetes version and sidecar versions apply. They also do not establish production availability.
That limitation is important for teams planning an upgrade. The story is categorized as a breaking change, but the exact breaking differences are not independently established by the supplied KEP, protobuf, CRD, and CSI specification. Those sources describe the proposed architecture and current API surfaces; they are not a substitute for a release-specific migration guide.
Teams should therefore treat the documented fields and RPC behavior as implementation context, not as proof that every existing CBT client or CSI driver will continue to work. Before changing a production backup path, obtain release-specific compatibility information from the relevant Kubernetes, CSI, sidecar, and backup-client documentation and test the complete combination in a non-production environment.
