...

/

Understanding CRDs

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/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- 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 the apiVersion that we’ll use for the CustomResourceDefinition. The CustomResourceDefinition is a Kubernetes built-in API, which has its own API versions. Normally, we use the apiextensions.k8s.io/v1 API. If you’re using a lower version of Kubernetes, it could be apiextensions.k8s.io/v1beta1 instead.

  • kind (line 2): This field indicates the resource kind. Of course, here, we want to create a CustomResourceDefinition.

  • metadata.name (line 4): This field is quite important, because it specifies the name of the resource. ...