Concepts

Let’s take a quick look at some of the basic concepts related to multipleversions in Kubernetes.

Hub/Spoke/Storage Versions

All versions of a Kubernetes object share the same underlying storage. So if youhave versions v1, v2 and v3 of a kind, kubernetes will use one of the versions topersist the object of that Kind in Etcd. You can specify the version to be usedfor storage in the Custom Resource definition for that API.

One can think of storage version as the hub and other versions as spokes to visualize therelationship between storage and other versions (as shown below in the diagram).The important thing to note is that conversion between storage and other versionshould be lossless (round trippable). As shown in the diagram below, v1 is thestorage/hub version and v2 and v3 spoke version. This tutorial usesthe terms storage version and hub interchangeably.

So if each spoke version implements conversion functions to convertto/from a hub, then conversions betweek spokes can be derived. In the exampleshown in the above diagram, a v2 object can be converted to v3 object by firstconverting v2 to v1 and then converting v2 to v3. And same is true forconverting v3 object to v2.

Conversion Webhook

API clients such as kubectl, controllers can request different versions of yourAPI. So when a client requests for a version other than the storage version ofyour API, Kubernetes API server calls out to an HTTP endpoint to perform theconversion between the requested version and storage version. This HTTP endpointis called Conversion Webhook and its discovery/connection parameters areconfigured in the CRD definition. With kubebuilder, you just need to implementconversion functions between different versions and it takes care of the rest ofthe work associated with running a webhook server, generating and plumbing theconversion webhook handler.