CSI gives Kubernetes storage drivers their own release cycle

Adding a storage backend used to require adding its implementation to Kubernetes itself. A vendor's bug fix then depended on the Kubernetes release process, and Kubernetes maintainers inherited code they could not always test. Saad Ali's January 15 guide to CSI's general availability explains the alternative now available in Kubernetes 1.13. A storage provider can deploy a driver separately and communicate through the Container Storage Interface. The application continues to request storage through Kubernetes objects.

The separation matters because storage implementations have different development schedules and depend on different equipment. Putting them inside the same binaries made those differences a core maintenance problem. CSI establishes a protocol between the orchestrator and storage software, allowing the vendor to maintain the latter independently. I value Kubernetes most for its reconciliation model and extensible API machinery. This change applies that preference to a subsystem where coupling has concrete consequences for upgrades.

A protocol with a deliberately limited responsibility

The CSI 1.0 specification defines a plugin as a gRPC endpoint implementing CSI services. Its objective is that a storage provider can write a plugin for multiple container orchestrators. Operations include volume creation and deletion, attachment, and making storage available on a node. Kubernetes supplies its own integration around those operations.

That distinction explains the helper containers in the Kubernetes guide. The external provisioner watches PersistentVolumeClaims and invokes the driver's creation or deletion operations. The external attacher watches VolumeAttachment objects and invokes controller publish or unpublish operations. A node driver registrar registers the driver with kubelet. Kubernetes knowledge can therefore live in these helpers while the storage driver implements the protocol. A driver does not need to embed an independent implementation of every Kubernetes watch it requires.

The specification explicitly leaves plugin lifecycle management outside its scope. It does not prescribe how an operator installs or upgrades a driver, monitors it, or restarts it after a failure. Protocol authentication and authorization are also outside the specification's responsibilities. Those exclusions are consequential. Compatibility with CSI does not supply an entire operational design for the software that holds storage credentials and performs node operations.

The claim remains the application's interface

The guide uses familiar StorageClass and PersistentVolumeClaim objects to demonstrate dynamic provisioning. A class names the provisioner, and a claim requests capacity through that class. This shortened version preserves the guide's illustrative driver name. It assumes that an appropriate driver and its helpers have already been deployed.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: csi-driver.example.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-request-for-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-storage

The provisioner name is illustrative, so this configuration alone cannot provide storage. For a deployed driver supporting dynamic provisioning, creation of the claim starts the provisioning process. The driver receives a CreateVolume request. The integration creates a PersistentVolume representing the resulting storage, and Kubernetes binds that volume to the claim. A pod can then reference the claim through its persistentVolumeClaim volume declaration.

This keeps a useful separation between the application request and the backend implementation. The claim expresses the requested capacity and access mode. The StorageClass selects the provisioner and carries driver parameters. Changing the implementation beneath that arrangement does not require inventing a separate application storage API. It also does not make existing data automatically portable between storage systems. The guide describes provisioning and binding, not a data migration service.

Secrets illustrate another boundary within this arrangement. External provisioner version 1.0.1 and later reserve parameters prefixed with csi.storage.k8s.io/. Recognized keys can refer to secrets used during provisioning. Unrecognized keys with that prefix are ignored instead of being passed to the driver. Ordinary driver parameters remain separate. The guide says the older secret parameter names remain supported in that provisioner version but are deprecated.

General availability has a defined scope

Kubernetes 1.13 supports CSI specification versions 1.0 and 0.3 despite breaking changes between them. The guide also places VolumeAttachment in the stable storage API group and promotes both the CSI PersistentVolume source and kubelet registration mechanism to general availability. These changes give the integration a stability commitment under Kubernetes' deprecation policy.

Other storage capabilities have different maturity levels. The same guide lists raw block volumes, topology awareness and volume snapshots among work still at alpha. A generally available CSI integration therefore does not imply that every operation described by the CSI specification has a generally available Kubernetes implementation. The specification and its Kubernetes integration need separate compatibility assessments.

Node privileges are another practical qualification. The guide says most CSI plugins need bidirectional mount propagation, which requires privileged pods. It identifies --allow-privileged=true on the API server and kubelet as a possible prerequisite. Moving vendor code out of the Kubernetes binary reduces one kind of coupling while leaving the deployed driver responsible for sensitive storage operations. I regard independent driver maintenance as a substantial improvement, but its deployment privileges still deserve explicit ownership.

Existing in-tree plugins have not disappeared with this announcement. The guide describes migration of persistent remote plugins to CSI as planned work. It also says inline CSI volume references are unsupported in this implementation, so ephemeral local use still requires a claim. For an application author, the immediate change is access to separately deployed storage integrations through existing claims. For the cluster operator, the new responsibility is maintaining the driver and its Kubernetes helpers as a compatible installation alongside the cluster.