Migrating In-Tree Kubernetes Storage Plugins to CSI: Overview, Procedure, and Current Status

Kubernetes storage plugins are transitioning from the built‑in in‑tree implementation to the Container Storage Interface (CSI), with the migration reaching beta in v1.17 after being introduced as an alpha feature in v1.14.

Why migrate in‑tree plugins to CSI? In‑tree plugins are compiled into the core Kubernetes binary, making it difficult for vendors to add or fix support for new storage systems without aligning with the Kubernetes release cycle. Maintaining third‑party storage code in the core also raises reliability and security concerns. CSI decouples storage drivers from the core, improving stability, security, and ease of maintenance.

What is CSI migration? CSI migration replaces an existing in‑tree plugin (e.g., kubernetes.io/gce-pd or kubernetes.io/aws-ebs) with a corresponding CSI driver. When the migration works correctly, end users notice no functional change; the control plane simply hands storage operations over to the CSI driver.

How to try CSI migration for existing plugins? Use Kubernetes v1.17 or newer and enable the feature gates CSIMigration and CSIMigration{Provider} (where {Provider} matches the in‑tree cloud provider, such as gce or aws). Install the appropriate CSI driver for the target storage system.

Verify that the feature gates are active and that the driver is installed by inspecting the CSINode object: kubectl get csinodes -o yaml Example CSINode output (truncated):

apiVersion: storage.k8s.io/v1
kind: CSINode
metadata:
  annotations:
    storage.alpha.kubernetes.io/migrated-plugins: kubernetes.io/gce-pd
  name: test-node
spec:
  drivers:
    - name: pd.csi.storage.gke.io
      ...

Create a PersistentVolumeClaim and a pod that uses it, then confirm the pod runs:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-disk
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - mountPath: /var/lib/www/html
          name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: test-disk

kubectl get pods web-server

NAME         READY   STATUS    RESTARTS   AGE
web-server   1/1     Running   0          39s

Check the CSI driver logs to ensure it processes the request:

kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}

/csi.v1.Controller/ControllerPublishVolume called with request: ...
Attaching disk ... to ...
ControllerPublishVolume succeeded for disk ... to instance ...

Current limitations – Although CSI migration is in beta, it requires administrators to install the CSI driver before enabling migration. Only GCE PD and AWS EBS have beta‑ready drivers; Azure File/Disk, OpenStack, and VMware are still early, and many non‑cloud drivers (e.g., NFS, Portworx) are only planned.

Roadmap – The goal is to remove all in‑tree cloud provider code by Kubernetes v1.21, making CSI migration enabled by default and bundling required drivers with cloud distributions.

What users should do – For new clusters or stateful workloads that need newer storage features (e.g., volume snapshots), use CSI drivers directly. If upgrading an existing cluster, enable CSI migration to continue receiving support via the external drivers.

Reference: Kubernetes blog . Author: David Zhu, Google Software Engineer.