Search⌘ K
AI Features

Understanding CRDs

Explore the role of CustomResourceDefinitions in extending Kubernetes APIs. Understand their schema, versioning, scope, and how they dynamically register with the kube-apiserver without downtime. Learn the differences between CRDs and ConfigMaps to manage your custom Kubernetes resources effectively.

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.

YAML
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. ...