The talk explains the lifecycle of Custom Resource Definitions (CRDs) and the challenges of versioning them. It provides insights on how to upgrade CRDs seamlessly, with zero downtime and backwards compatibility.
- CRDs are used to extend Kubernetes and as projects grow, the definitions of the resource start to evolve and may completely change, requiring versioning of CRDs
- Versioning of CRDs can be tough as end users need to be provided with seamless upgrades, zero downtime and backwards compatibility
- There are two views of CRD versioning: server version and stored version
- There are two conversion strategies: last mile change and full conversion
- The conversion package simplifies conversion functions between API versions
- The storage version migrator component bumps up existing objects to the new desired storage version
- Lossless conversion is followed where users can roll back to the older version
- Annotations of the field of the CR are used to store functions which lose data between versions
The speaker demonstrated a demo of two versions of CRDs and how the conversion webhook works. He showed how the conversion package reads the fields, makes it into one field, and assigns the object metadata. He also explained how the storage version migrator component probes the API discovery document every 10 minutes and bumps up the existing objects to the new desired storage version.