Cloud Native 9 min read

Kubernetes In‑Tree to CSI Migration Status Update (v1.17–v1.23)

This article reviews the progress of Kubernetes' in‑tree storage to CSI migration from v1.17 through v1.23, explains the purpose and benefits of CSI migration, outlines new feature gates, observability metrics, bug fixes, collaboration efforts, the release roadmap, and provides guidance for users and contributors.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Kubernetes In‑Tree to CSI Migration Status Update (v1.17–v1.23)

Overview Since the Container Storage Interface (CSI) reached alpha in Kubernetes v1.14, the migration of in‑tree storage plugins to CSI entered beta with v1.17. The SIG Storage and other SIGs have been working to stabilize the feature and prepare it for GA.

What is CSI Migration and Why Migrate? CSI allows Kubernetes to replace vendor‑specific in‑tree drivers with external CSI drivers, improving maintainability, reducing security risk, and giving operators the ability to enable only the drivers they need. Migration translates in‑tree API calls to equivalent CSI calls, keeping existing StorageClass, PersistentVolume, and PersistentVolumeClaim objects functional while delegating operations to the CSI driver.

Improvements and Updates From v1.21 onward, the old CSIMigration{provider}Complete feature flags were deprecated in favor of InTreePlugin{vendor}Unregister flags, which provide the same functionality while allowing independent enablement. New observability metrics were added to trace CSI migration usage, and numerous bugs (dangling attachments, garbage collection, topology tag errors, etc.) were fixed.

Collaboration with Other SIGs SIG Storage works closely with SIG Cloud Provider and SIG Cluster Lifecycle to ensure CSI migration is supported in managed services and distribution releases. Users of managed Kubernetes should check with their providers for any required steps.

Roadmap and Current Status A table (omitted here) shows the current and target release versions for each storage driver. Some drivers (e.g., ScaleIO) are removed, and others are deprecated and will be eliminated from the core.

Next Steps The goal is to mark the entire CSI migration feature as GA and remove all in‑tree cloud‑provider storage code before Kubernetes v1.26/v1.27.

What Should Users Do? New clusters and stateful applications should use CSI drivers directly. Existing clusters can continue using in‑tree APIs, but to access new features like volume snapshots, users must manually migrate persistent volumes to CSI.

How to Contribute Join the #csi-migration Slack channel or any SIG Storage mailing list. Contributions come from many community members, and the project welcomes new contributors.

Acknowledgments The article lists numerous contributors and thanks them for their work.

References Original blog post: https://kubernetes.io/blog/2021/12/10/storage-in-tree-to-csi-migration-status-update/

migrationCloud NativeKubernetesstorageCSIIn-Tree
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.