Custom Resource Definitions (CRDs) in Kubernetes - Step-by-Step Execution

Process Flow - Custom Resource Definitions (CRDs)

Write CRD YAML

↓

Apply CRD to cluster

↓

Kubernetes API Server registers new resource

↓

User creates Custom Resource (CR)

↓

Kubernetes stores CR in etcd

↓

Controllers watch and act on CRs

↓

Custom behavior executed

↓

End

This flow shows how you write and apply a CRD, then create custom resources that Kubernetes stores and controllers manage.

Execution Sample

Kubernetes

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
spec:
  group: example.com
  versions:
  - name: v1
    served: true
    storage: true
  scope: Namespaced
  names:
    plural: widgets
    singular: widget
    kind: Widget

This YAML defines a CRD named 'widgets.example.com' that adds a new resource type 'Widget' to Kubernetes.

Process Table

Step	Action	Resource State Change	API Server Response
1	Apply CRD YAML with kubectl	CRD 'widgets.example.com' created in cluster	CRD accepted and registered
2	API Server registers new resource type 'Widget'	API server schema updated	Resource type available for use
3	User creates a Widget custom resource	New Widget object stored in etcd	Widget resource created successfully
4	Controller watches Widget resources	Controller detects new Widget	Controller starts managing Widget
5	Controller acts on Widget	Custom behavior executed (e.g., create pods)	Status updated on Widget resource
6	User queries Widget resource	Current state returned	Widget details shown
7	User deletes Widget resource	Widget removed from etcd	Deletion confirmed
8	User deletes CRD	CRD and all Widgets removed	CRD deleted, resource type removed

💡 CRD lifecycle ends when CRD is deleted or cluster is shut down

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7	Final
CRD 'widgets.example.com'	Not present	Created	Present	Present	Present	Deleted
Widget resources	None	None	One created	Managed by controller	Deleted	None
API Server schema	No Widget type	Widget type added	Widget type present	Widget type present	Widget type present	Widget type removed

Key Moments - 3 Insights

Why does the API server need to register the CRD before I can create custom resources?

Because the API server must know about the new resource type schema to accept and store custom resources. See execution_table step 2 where the resource type is registered before creation.

What happens if I delete the CRD but still have custom resources?

Deleting the CRD removes the resource type and all its custom resources from the cluster, as shown in execution_table step 8.

How does the controller know when to act on a custom resource?

Controllers watch the API server for changes to custom resources and react accordingly, as shown in execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the new resource type 'Widget' registered by the API server?

A Step 2

B Step 3

C Step 1

D Step 5

💡 Hint

Check the 'Resource State Change' column for when the API server schema updates.

According to the variable tracker, what is the state of Widget resources after Step 3?

A None

B One created

C Managed by controller

D Deleted

💡 Hint

Look at the 'Widget resources' row under 'After Step 3' column.

If you delete the CRD, what happens to the custom resources according to the execution table?

A They remain but become unmanaged

B They become read-only

C They are deleted along with the CRD

D They are archived automatically

💡 Hint

See execution_table step 8 for the effect of deleting the CRD.

Concept Snapshot

Custom Resource Definitions (CRDs) let you add new resource types to Kubernetes.
Write a CRD YAML and apply it to register the new type.
Create custom resources of that type like built-in resources.
Controllers watch and manage these custom resources.
Deleting the CRD removes the resource type and all its instances.

Full Transcript

Custom Resource Definitions (CRDs) allow you to extend Kubernetes by adding your own resource types. The process starts by writing a CRD YAML file that defines the new resource's group, version, scope, and names. When you apply this YAML to the cluster, the Kubernetes API server registers the new resource type. After registration, you can create custom resources of this type, which Kubernetes stores like any other resource. Controllers watch these custom resources and perform actions based on their state. If you delete the CRD, Kubernetes removes the resource type and all associated custom resources. This flow enables you to customize Kubernetes behavior with your own resource definitions.

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