0Pricing
Docker & Kubernetes for Developers · Lesson

Custom Resource Definitions (CRDs)

Extend Kubernetes functionality by defining your own custom resources to manage domain-specific objects.

Custom Resource Definitions (CRDs) is a free Docker & Kubernetes for Developers lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Docker & Kubernetes for Developers learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Extend Kubernetes API

Welcome! In this lesson, we'll explore Custom Resource Definitions (CRDs). CRDs allow you to extend Kubernetes by defining your own custom resource types.

Think of it as teaching Kubernetes new words and concepts, so it can manage application-specific objects just like it manages built-in ones like Pods or Deployments.

Why Custom Resources?

Kubernetes provides powerful primitives like Pods, Deployments, and Services. But what if your application needs to manage a unique kind of object, like a database cluster, a serverless function, or a custom build pipeline?

  • Domain-Specific Objects: Define resources tailored to your application's unique needs.
  • Abstraction: Simplify complex application deployments into a single, manageable resource.
  • Kubernetes Native: Leverage Kubernetes's declarative API, tooling (kubectl), and watch mechanisms for your custom objects.

Core vs. Custom Resources

Kubernetes comes with many built-in or 'core' resources you already know:

  • Core Resources: Pod, Deployment, Service, ConfigMap. These are part of the standard Kubernetes API.
  • Custom Resources: These are resources you define using CRDs. They behave just like core resources but represent your own application-specific concepts.

Once a CRD is created, you can create and manage instances of your custom resource using kubectl, just like any other Kubernetes object.

Anatomy of a CRD: Basics

A CRD is itself a Kubernetes resource defined in YAML. Here's what some key fields mean:

  • apiVersion: apiextensions.k8s.io/v1: Specifies the API version for the CRD itself.
  • kind: CustomResourceDefinition: Identifies this YAML as a CRD definition.
  • metadata.name: The unique name for your CRD, typically in the format <plural>.<group>.

Let's look at defining the core specification next.

CRD Anatomy: Group & Versions

The spec section of a CRD defines the custom resource's properties:

  • spec.group: The API group for your custom resource (e.g., example.com). This helps organize your custom resources.
  • spec.versions: A list of supported versions for your custom resource (e.g., v1alpha1, v1). Each version can have its own schema.
  • spec.scope: Defines if your custom resource is Namespaced (like Pods) or Cluster (like Nodes).

CRD Anatomy: Names & Schema

More important fields in the spec:

  • spec.names: Defines how your custom resource will be referred to:
    • plural: The plural name used in kubectl get (e.g., webservers).
    • singular: The singular name (e.g., webserver).
    • kind: The CamelCase name for the resource object (e.g., WebServer).
    • shortNames: Optional, short aliases (e.g., ws).
  • spec.versions[].schema.openAPIV3Schema: This is crucial! It defines the structure and validation rules for your custom resource's data.

Defining a Simple WebServer CRD

Here's a basic CRD for a WebServer resource. Notice how it defines the group, versions, names, and a simple schema for its properties (like image and replicas).

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: webservers.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                image:
                  type: string
                replicas:
                  type: integer
              required:
                - image
  scope: Namespaced
  names:
    plural: webservers
    singular: webserver
    kind: WebServer
    shortNames:
      - ws

Applying Your CRD

Once you have your CRD YAML file (e.g., webserver-crd.yaml), you can apply it to your Kubernetes cluster using kubectl. This registers your new resource type with Kubernetes.

It might take a few seconds for the API server to fully acknowledge the new type.

kubectl apply -f webserver-crd.yaml

Creating a Custom Resource

After the CRD is applied, you can create instances of your WebServer custom resource. This YAML defines a specific WebServer object with its own image and replicas values, conforming to the schema you defined.

You can manage this object just like any other Kubernetes resource.

apiVersion: example.com/v1
kind: WebServer
metadata:
  name: my-first-webserver
spec:
  image: nginx:latest
  replicas: 3

Interacting with Custom Resources

Now that you've defined a CRD and created an instance, you can use standard kubectl commands to interact with your custom resources:

  • kubectl get webservers: List all WebServer objects.
  • kubectl get ws: Use the short name.
  • kubectl describe webserver my-first-webserver: Get detailed information about a specific WebServer instance.

This seamless integration is a key benefit of CRDs!

Check Your CRD Knowledge

Which of the following are benefits of using Custom Resource Definitions (CRDs) in Kubernetes?

Recap: Extending Kubernetes

Great job! You've learned about Custom Resource Definitions!

  • CRDs allow you to extend the Kubernetes API with your own custom resource types.
  • They enable Kubernetes to manage domain-specific objects using its native API and tooling.
  • A CRD defines the schema and properties of your custom resource.
  • Once defined, you can create and interact with instances of your custom resource using kubectl.

Next, we'll see how Operators leverage CRDs to automate complex application management!

Frequently asked questions

Is the “Custom Resource Definitions (CRDs)” lesson free?

Yes — the full text of “Custom Resource Definitions (CRDs)” is free to read here on the web, and the Docker & Kubernetes for Developers course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Docker & Kubernetes for Developers course, upgrade to CoddyKit PRO.

What will I learn in “Custom Resource Definitions (CRDs)”?

Extend Kubernetes functionality by defining your own custom resources to manage domain-specific objects. You practise Docker & Kubernetes for Developers with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Docker & Kubernetes for Developers?

No prior experience is required. Docker & Kubernetes for Developers on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Custom Resource Definitions (CRDs)” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Docker & Kubernetes for Developers lesson?

Yes. Every Docker & Kubernetes for Developers lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Custom Resource Definitions (CRDs)
  2. The Operator Pattern in Kubernetes
  3. Serverless with Kubernetes (Knative)
  4. Extending the API Server with Admission Webhooks
← Back to Docker & Kubernetes for Developers