Storage Version Migrator: Never Worry About Stale API Objects Again
summary
Automated controller watches API discovery and, when a resource’s storage version changes, posts migration requests and rewrites objects via the API server so etcd objects are re-encoded to the new storage version. Deployable with kubectl manifests, it processes objects in chunks of 500 using a continue token checkpoint, survives crashes and resumes, supports CRDs, and relies on the API server to do version conversions. Alpha in kubecon repo with planned beta then GA in Q3 2019.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:35Agenda
- 5:09API Group & Version
- 5:27API Group/API Version
- 6:40Multi-version RESTful API
- 7:39Creating an Object
- 10:21Reading an Object
- 12:07If only one version was supported...
- 14:32If storage version is used...
- 15:18Implication to API Server Upgrades
- 16:06Stale Objects
- 18:15Storage Migrator in One Line
- 18:44Highlights
- 19:49Deploying Storage Migrator
- 20:16Migration API
- 21:50Checking Migration Status
- 22:45Controllers
- 27:07Timeline
related talks
35mStorage Version Migrator: Never Worry About Stale API Objects Again
35mExtending Kubernetes: Our Journey & Roadmap
01h 39mTutorial: Mastering Multi-version CRDs: From YAML to a Serious Development Project
35mBeyond Storage Management
29mExtending Kubernetes with Storage Transformers
17mUnraveling the Mystery of Versioning CRDs
29mSIG API Machinery in the Era of AI: Updates
35mDefusing the Kubernetes API Performance Minefield