Why Custom Resource Definitions (CRDs) in Kubernetes? - Purpose & Use Cases

The Big Idea

What if you could teach Kubernetes to understand and manage anything you want, just like its built-in parts?

The Scenario

Imagine you want to manage a new type of resource in your Kubernetes cluster, like a special database or a custom app setting, but Kubernetes doesn't know about it yet.

You try to track and update these resources manually outside Kubernetes, using scripts or external tools.

The Problem

This manual way is slow and risky. You have to write lots of custom code, keep track of resource states yourself, and it's easy to make mistakes or lose sync with the cluster.

Also, you miss out on Kubernetes features like automatic updates, validation, and easy querying.

The Solution

Custom Resource Definitions (CRDs) let you tell Kubernetes about your new resource types directly.

With CRDs, you can create, update, and manage your custom resources just like built-in ones, using the same tools and commands.

This makes your cluster smarter and your work simpler and safer.

Before vs After

✗ Before

curl -X POST http://external-system/api/create -d '{"name":"mydb"}'
# then separate script to check status

✓ After

kubectl apply -f mydb-cr.yaml
kubectl get mydb mydb-instance

What It Enables

It enables you to extend Kubernetes seamlessly to manage any resource you need, all within the same powerful system.

Real Life Example

A company creates a CRD to manage custom backup jobs for their databases, so they can schedule, monitor, and automate backups using Kubernetes commands.

Key Takeaways

Manual resource management outside Kubernetes is slow and error-prone.

CRDs let you add new resource types directly into Kubernetes.

This makes managing custom resources easier, safer, and integrated.

Practice

1. What is the main purpose of a Custom Resource Definition (CRD) in Kubernetes?

easy

A. To add new resource types to Kubernetes that are not built-in

B. To update the Kubernetes version automatically

C. To manage user permissions in Kubernetes

D. To monitor cluster health and performance

Solution

1. Step 1: Understand what CRDs do

   CRDs allow users to create their own resource types beyond the default Kubernetes resources.

2. Step 2: Compare options

   Automatic version updates, user permissions (RBAC), and cluster monitoring are separate Kubernetes features unrelated to CRDs.

3. Final Answer:

   To add new resource types to Kubernetes that are not built-in -> Option A

4. Quick Check:

   CRDs = add custom resource types [OK]

Hint: CRDs = add your own resource types [OK]

Common Mistakes:

• Confusing CRDs with RBAC for permissions
• Thinking CRDs update Kubernetes versions
• Assuming CRDs monitor cluster health

2. Which of the following is the correct YAML key to define the API version for a CRD?

easy

A. version

B. api_version

C. apiVersion

D. apiVer

Solution

1. Step 1: Recall Kubernetes YAML syntax

   Kubernetes uses camelCase keys like apiVersion to specify API versions.

2. Step 2: Check other options

   version, api_version, and apiVer use incorrect formats not recognized by Kubernetes.

3. Final Answer:

   apiVersion -> Option C

4. Quick Check:

   Correct YAML key = apiVersion [OK]

Hint: Use camelCase keys like apiVersion in Kubernetes YAML [OK]

Common Mistakes:

• Using underscores instead of camelCase
• Using incomplete or shortened keys
• Confusing version with apiVersion

3. Given this CRD snippet, what is the scope of the custom resource?

spec:
  scope: Namespaced
  group: example.com
  names:
    kind: Widget
    plural: widgets

medium

A. Cluster-wide resource available in all namespaces

B. Resource limited to a specific namespace

C. Resource only available in the default namespace

D. Resource scoped to nodes

Solution

1. Step 1: Read the scope field

   The scope is set to Namespaced, meaning the resource exists within namespaces.

2. Step 2: Understand scope meanings

   Namespaced means the resource is limited to a specific namespace, not cluster-wide or node-scoped.

3. Final Answer:

   Resource limited to a specific namespace -> Option B

4. Quick Check:

   scope Namespaced = namespace-limited resource [OK]

Hint: scope: Namespaced means resource lives inside namespaces [OK]

Common Mistakes:

• Confusing Namespaced with Cluster scope
• Assuming default namespace only
• Thinking scope relates to nodes

4. You applied a CRD YAML but get an error: "unknown field 'kindd'". What is the most likely cause?

medium

A. Typo in the YAML key 'kindd' instead of 'kind'

B. Missing apiVersion field

C. CRD name is not unique

D. Cluster role permissions missing

Solution

1. Step 1: Analyze the error message

   The error says "unknown field 'kindd'", indicating a typo in the YAML key.

2. Step 2: Identify the correct key

   The correct key is kind, so kindd is a misspelling causing the error.

3. Final Answer:

   Typo in the YAML key 'kindd' instead of 'kind' -> Option A

4. Quick Check:

   YAML key typos cause unknown field errors [OK]

Hint: Check YAML keys carefully for typos [OK]

Common Mistakes:

• Ignoring spelling errors in YAML keys
• Assuming missing fields cause unknown field errors
• Blaming permissions for syntax errors

5. You want to create a CRD for a resource named Gadget that is cluster-scoped and has a plural name gadgets. Which YAML snippet correctly defines this?

hard

A. spec:
group: example.com
scope: Cluster
names:
kind: Gadget
plural: gadget

B. spec:
group: example.com
scope: Namespaced
names:
kind: Gadget
plural: gadgets

C. spec:
group: example.com
scope: Cluster
names:
kind: gadget
plural: gadget

D. spec:
group: example.com
scope: Cluster
names:
kind: Gadget
plural: gadgets

Solution

1. Step 1: Check scope value

   The resource must be cluster-scoped, so scope: Cluster is correct.

2. Step 2: Verify kind and plural names

   kind should be capitalized as Gadget and plural should be gadgets (plural lowercase).

3. Step 3: Compare options

   The snippet with scope: Cluster, kind: Gadget, plural: gadgets matches all requirements. Snippets with scope: Namespaced, lowercase kind: gadget, or singular plural: gadget are incorrect.

4. Final Answer:

   spec: group: example.com scope: Cluster names: kind: Gadget plural: gadgets -> Option D

5. Quick Check:

   Cluster scope + correct kind/plural = spec: group: example.com scope: Cluster names: kind: Gadget plural: gadgets [OK]

Hint: Cluster scope means scope: Cluster; kind capitalized, plural lowercase [OK]

Common Mistakes:

• Using Namespaced instead of Cluster scope
• Incorrect casing for kind or plural
• Using singular for plural name