05-14, 11:40–12:10 (Europe/Madrid), Gallery
All Kubernetes projects need to define the APIs for CRDs and the lifecycle of each API generally starts with the alpha version. The API definition evolves over time and eventually moves to a stable version. But this evolution leads to multiple releases and each release should provide support for handling multiple API versions.
API changes between versions can include addition, deletion and renaming of fields in CRDs, but while introducing these changes we need to ensure stability and backward compatibility. To support multiple versions simultaneously, we write conversion functions that are used to convert API objects from one version to another. We have auto generating tools that help to write conversions but still we need manual intervention in many cases. There is a lack of resources on this topic so a lot of developers face difficulties when dealing with conversions, especially those who are newer to this ecosystem. Due to this, API changes become a complicated and time consuming experience which makes it a prominent issue for the majority of contributors because APIs and conversions are part of almost all k8s projects.
This talk aims to explain the concepts behind conversion functions and demonstrate how to write conversions for k8s CRDs.
This talk will explain the relevance of conversions in Kubernetes projects, why we need conversion functions, when these are invoked and how to implement them.
A simple approach to implement conversions might be to define functions for converting k8s objects between each pair of API versions. Then we could use the appropriate function to convert an object from one version to another. This approach works fine when we just have two versions, but what if we had 4 or 8 types of versions? This would need a conversion function to convert between each pair of versions. But this approach is not scalable as it would need a lot of functions.
So to implement the conversions among multiple API versions, we need to understand hubs, spokes and other wheel metaphors that are heavily used in writing these conversion functions.
We will understand the working of auto generating tools for conversion functions, how to use them and when we need manual implementation for conversion between API types.
Madhur Agarwal is a Member of Technical Staff 3 @VMware, who was introduced to the Kubernetes world in 2019. He recently received his kubernetes-sigs membership. Over the past few months, his work has been around Cluster API and its AWS provider.
Shivani Singhal is a Member of Technical Staff 3 @VMware, who has started her Kubernetes contribution since 2019. She graduated as a mentee from LFX Mentorship Program (previously known as community bridge). Currently she is actively contributing to the SIG cluster API lifecycle and working as a reviewer in Cluster API provider for AWS [CAPA]. When not glued to her laptop, she is mostly engaged in cooking stuff and with her doodle book.