Understanding CRDs
Understand Kubernetes CRDs and what's behind the scenes.
We'll cover the following...
More about CRDs
With CRDs, we can define our own API schema and plumb them to the kube-apiserver at any time. No broken changes in the kube-apiserver are made. We don’t need to restart or recompile the kube-apiserver. They work pretty much like add-on plugins, in the sense that we can apply or remove them whenever we want. Super handy!
What does a CRD look like?
To better understand CRDs, let’s see what one looks like.
apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata:name: crontabs.stable.example.comspec:group: stable.example.comversions:- name: v1served: truestorage: trueschema:openAPIV3Schema:type: objectproperties:spec:type: objectproperties:cronSpec:type: stringimage:type: stringreplicas:type: integerscope: Namespacednames:plural: crontabssingular: crontabkind: CronTabshortNames:- ct
Now, let’s try to break down the definitions above so that we can better understand every field in a CRD. These fields are quite different in other built-in Kubernetes objects, and some of them are quite important and worth discussing.
-
apiVersion(line 1): This field specifies theapiVersionthat we’ll use for theCustomResourceDefinition. TheCustomResourceDefinitionis a Kubernetes built-in API, which has its own API versions. Normally, we use theapiextensions.k8s.io/v1API. If you’re using a lower version of Kubernetes, it could beapiextensions.k8s.io/v1beta1instead. -
kind(line 2): This field indicates the resourcekind. Of course, here, we want to create aCustomResourceDefinition. -
metadata.name(line 4): This field is quite important, because it specifies the name of the resource. ...