Bird
Raised Fist0
Kubernetesdevops~7 mins

Custom Resource Definitions (CRDs) in Kubernetes - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
Sometimes you need Kubernetes to understand new types of objects beyond the built-in ones. Custom Resource Definitions (CRDs) let you teach Kubernetes about your own resource types so you can manage them like native objects.
When you want to store and manage application-specific settings inside Kubernetes.
When you need to extend Kubernetes with new resource types for your custom controllers or operators.
When you want to create reusable APIs for your team that behave like built-in Kubernetes resources.
When you want to track the state of external systems inside Kubernetes using custom objects.
When you want to automate workflows by defining new resource types that trigger actions.
Config File - my-crd.yaml
my-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: string
                color:
                  type: string
  scope: Namespaced
  names:
    plural: widgets
    singular: widget
    kind: Widget
    shortNames:
      - wdgt

This file defines a new resource type called Widget under the group example.com.

apiVersion and kind specify this is a CRD.

metadata.name is the full name of the CRD.

spec.group is the API group for the new resource.

spec.versions lists versions; here only v1 is served and stored.

spec.versions.schema defines the shape of the resource, here with spec.size and spec.color as strings.

spec.scope means the resource is namespaced.

spec.names defines how the resource is called in plural, singular, kind, and short names.

Commands
This command creates the Custom Resource Definition in the Kubernetes cluster, so Kubernetes learns about the new resource type Widget.
Terminal
kubectl apply -f my-crd.yaml
Expected OutputExpected
customresourcedefinition.apiextensions.k8s.io/widgets.example.com created
This command checks that the CRD was created and shows its details.
Terminal
kubectl get crd widgets.example.com
Expected OutputExpected
NAME CREATED AT widgets.example.com 2024-06-01T12:00:00Z
This command lists all Custom Resource Definitions installed in the cluster, including the new Widget CRD.
Terminal
kubectl get crds
Expected OutputExpected
NAME CREATED AT widgets.example.com 2024-06-01T12:00:00Z othercrd.example.com 2024-05-20T09:30:00Z
This command shows the schema and documentation of the new Widget resource, helping you understand its fields.
Terminal
kubectl explain widget
Expected OutputExpected
KIND: Widget VERSION: example.com/v1 DESCRIPTION: Widget is a custom resource for managing widgets. FIELDS: apiVersion <string> kind <string> metadata <Object> spec <Object> size <string> color <string>
Key Concept

If you remember nothing else from this pattern, remember: CRDs let you add your own resource types to Kubernetes so you can manage custom objects like built-in ones.

Common Mistakes
Not applying the CRD file before creating custom resources of that type.
Kubernetes won't recognize the custom resource type and will reject the resource creation.
Always apply the CRD first with kubectl apply -f before creating any custom resources.
Using incorrect apiVersion or kind in the CRD file.
The CRD will fail to create or behave unexpectedly because Kubernetes expects specific apiVersion and kind values.
Use apiVersion apiextensions.k8s.io/v1 and kind CustomResourceDefinition exactly as shown.
Not defining the schema under spec.versions.schema.openAPIV3Schema.
Without a schema, Kubernetes cannot validate your custom resource objects, leading to potential errors or acceptance of invalid data.
Always define a proper OpenAPI v3 schema for your CRD version.
Summary
Create a CRD YAML file that defines your new resource type with group, versions, schema, and names.
Apply the CRD to the cluster using kubectl apply -f to register the new resource type.
Verify the CRD is installed with kubectl get crd and explore its schema with kubectl explain.

Practice

(1/5)
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