Kubernetes v1.37: Embrace Storage Version Migration by Default
Kubernetes v1.37 addresses a common pain point in managing custom resources: the hassle of upgrading API versions. Storage Version Migration (SVM) is now built-in and enabled by default, allowing you to seamlessly transition your CustomResourceDefinitions (CRDs) to newer versions without the usual headaches. This feature ensures that your resources are always using the most up-to-date storage version, reducing compatibility issues and technical debt.
Initiating a storage version migration is straightforward. You create a declarative StorageVersionMigration object, specifying the resource you want to migrate. The built-in StorageVersionMigrator controller in the Kubernetes control plane automatically watches for these objects and handles the migration to the default storage version for that API. For example, to migrate a CRD named crontabs, you would define it in a YAML file and apply it with kubectl. The process is efficient and minimizes downtime, making it ideal for production environments.
In practice, ensure your CRDs are set up correctly to support storage versioning. The migration process will reflect in the status of the migration object, indicating whether it is running or has succeeded. This feature is a game changer for teams managing multiple versions of custom resources, but be aware of your specific use cases and resource configurations to avoid potential pitfalls. As always, testing in a staging environment before production rollout is crucial.
Key takeaways
- →Create a StorageVersionMigration object to initiate migrations.
- →Use `kubectl apply -f` to apply your migration configuration.
- →Monitor migration status with `kubectl get storageversionmigration`.
Why it matters
This feature significantly reduces the complexity of managing API version upgrades for custom resources, enhancing stability and reducing the risk of errors in production environments.
Code examples
1apiVersion: storagemigration.k8s.io/v1
2kind: StorageVersionMigration
3metadata:
4 name: crontabs-migration
5spec:
6 resource:
7 group: example.com
8 resource: crontabskubectl apply -f crontabs-migration.yamlkubectl get storageversionmigration.storagemigration.k8s.io/crontabs-migration -o yamlWhen NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Streamline Your EKS Migration with Amazon Bedrock AgentCore
Migrating to Amazon EKS can be daunting, but Amazon Bedrock AgentCore simplifies the process. It evaluates your application’s readiness by analyzing source code and container artifacts, providing a clear migration plan.
Zero-Downtime Migration of Kubernetes Deployments: The ExternalName Approach
Migrating critical Kubernetes deployments can be a daunting task, especially when aiming for zero downtime. By leveraging an ExternalName service, you can seamlessly redirect traffic to a new namespace without disrupting your application.
Mastering kubeadm Upgrades: Strategies for Smooth Transitions
Upgrading your kubeadm cluster is crucial for maintaining security and performance. Understanding the upgrade workflow and the role of etcd can prevent downtime and ensure a seamless transition. Dive in to learn the best practices for managing your upgrades effectively.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.