Storage Version Migrator: Never Worry About Stale API Objects Again
summary
Solves stale etcd encodings by running a controller that rewrites stored objects so they are encoded in the current storage version, deployed with the provided manifests via deploy via kubectl. It lists objects in 500-object chunks using the chunking list API, records progress in a continual token, and forces the API server to perform conversion on writes. Handles built‑in and CRDs, is resilient to crashes, has been tested at large scale (examples up to a million configmaps) and moves from alpha toward beta/GA.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 3:58Why storage migrator was created
- 4:41Kubernetes storage background
- 15:55Stale objects in clusters
- 18:05Storage migrator solution overview
- 19:55Deploying storage migrator
- 22:32How storage migrator works
- 27:10Storage migrator timeline and future
- 28:29Q&A: Handling jobs during migration
- 31:04Q&A: Migration speed and rate limits
- 32:30Q&A: Namespace filtering and backups
- 33:25Q&A: Migration impact on objects
related talks
35mStorage Version Migrator: Never Worry About Stale API Objects Again
29mExtending Kubernetes with Storage Transformers
17mUnraveling the Mystery of Versioning CRDs
35mDefusing the Kubernetes API Performance Minefield
28mHow CoreOS sees the container industry
38metcd in 2026: Enhancements, V3.7 Roadmap...
30mScaling Time-Series Data to Infinity: A Kubernetes-Powered Solution with Envoy
01h 39mTutorial: Mastering Multi-version CRDs: From YAML to a Serious Development Project