Bird
Raised Fist0
Kubernetesdevops~10 mins

Custom resources concept in Kubernetes - Interactive Code Practice

Choose your learning style10 modes available

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
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a Custom Resource Definition (CRD) with the correct API version.

Kubernetes
apiVersion: [1]
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
Drag options to blanks, or click blank then click option'
Acore/v1
Bv1
Capps/v1
Dapiextensions.k8s.io/v1
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'v1' or 'core/v1' which are for core Kubernetes resources.
Using 'apps/v1' which is for deployments and similar resources.
2fill in blank
medium

Complete the code to specify the kind of the custom resource in the CRD spec.

Kubernetes
spec:
  group: example.com
  versions:
  - name: v1
    served: true
    storage: true
  scope: Namespaced
  names:
    plural: widgets
    singular: widget
    kind: [1]
Drag options to blanks, or click blank then click option'
AWidget
Bwidgets
CWidgetList
Dwidget
Attempts:
3 left
💡 Hint
Common Mistakes
Using plural or lowercase names for the kind.
Confusing kind with plural or singular names.
3fill in blank
hard

Fix the error in the command to create a custom resource from a YAML file named 'widget.yaml'.

Kubernetes
kubectl [1] -f widget.yaml
Drag options to blanks, or click blank then click option'
Aapply
Brun
Ccreate
Ddelete
Attempts:
3 left
💡 Hint
Common Mistakes
Using 'run' which is for running pods or containers.
Using 'delete' which removes resources.
Using 'apply' which can update existing resources but may not be ideal for initial creation.
4fill in blank
hard

Fill both blanks to define a Custom Resource Definition with the correct scope and plural name.

Kubernetes
spec:
  scope: [1]
  names:
    plural: [2]
Drag options to blanks, or click blank then click option'
ANamespaced
BCluster
Cwidgets
Dwidget
Attempts:
3 left
💡 Hint
Common Mistakes
Using singular for plural name.
Confusing 'Cluster' and 'Namespaced' scope.
5fill in blank
hard

Fill all three blanks to create a dictionary comprehension that filters custom resources with replicas greater than 3.

Kubernetes
filtered = {cr['metadata']['name']: cr['spec']['replicas'] for cr in resources if cr['spec']['replicas'] [1] [2]
Drag options to blanks, or click blank then click option'
A>
B3
C==
D<
Attempts:
3 left
💡 Hint
Common Mistakes
Using equality or less than operators.
Using the wrong number for comparison.

Practice

(1/5)
1. What is the main purpose of a Custom Resource in Kubernetes?
easy
A. To delete all existing Kubernetes resources
B. To replace built-in Kubernetes objects like Pods
C. To automatically update Kubernetes itself
D. To add new object types to Kubernetes for custom app needs

Solution

  1. Step 1: Understand Kubernetes object types

    Kubernetes has built-in objects like Pods and Services, but sometimes you need new types for your apps.
  2. Step 2: Role of Custom Resources

    Custom Resources let you define new object types to extend Kubernetes capabilities without changing its core.
  3. Final Answer:

    To add new object types to Kubernetes for custom app needs -> Option D
  4. Quick Check:

    Custom Resources extend Kubernetes = A [OK]
Hint: Custom Resources add new types, not replace or delete [OK]
Common Mistakes:
  • Thinking Custom Resources replace built-in objects
  • Believing Custom Resources update Kubernetes itself
  • Confusing Custom Resources with deleting resources
2. Which YAML kind is used to define a Custom Resource type in Kubernetes?
easy
A. CustomResourceDefinition
B. Pod
C. Deployment
D. Service

Solution

  1. Step 1: Identify the YAML kind for custom types

    Custom Resource types are defined by a special Kubernetes object called CustomResourceDefinition.
  2. Step 2: Differentiate from common kinds

    Pod, Deployment, and Service are built-in kinds, not for defining new types.
  3. Final Answer:

    CustomResourceDefinition -> Option A
  4. Quick Check:

    CustomResourceDefinition defines new types [OK]
Hint: CustomResourceDefinition is the special kind for custom types [OK]
Common Mistakes:
  • Choosing Pod or Deployment as custom type definition
  • Confusing Service with CustomResourceDefinition
  • Using incorrect kind names in YAML
3. Given this CustomResourceDefinition snippet, what is the spec.names.kind used for?
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
    shortNames:
    - wdg
medium
A. It controls the storage backend for the resource
B. It defines the kind name used when creating custom resource objects
C. It sets the namespace where the resource lives
D. It specifies the API version of the custom resource

Solution

  1. Step 1: Understand spec.names.kind role

    This field sets the kind name you use in YAML when creating instances of this custom resource.
  2. Step 2: Differentiate from other fields

    API version is under versions.name, scope is separate, storage backend is not set here.
  3. Final Answer:

    It defines the kind name used when creating custom resource objects -> Option B
  4. Quick Check:

    spec.names.kind = kind name for objects [OK]
Hint: spec.names.kind is the object kind name in YAML [OK]
Common Mistakes:
  • Confusing kind with API version
  • Thinking it sets namespace or storage
  • Mixing plural and kind meanings
4. You applied a CustomResourceDefinition YAML but get an error: error: unable to recognize "crd.yaml": no matches for kind "CustomResourceDefinition" in version "v1beta1". What is the likely cause?
medium
A. Missing metadata.name field in the YAML
B. Trying to create a Pod instead of a CustomResourceDefinition
C. Using deprecated API version v1beta1 instead of apiextensions.k8s.io/v1
D. Incorrect indentation in the YAML file

Solution

  1. Step 1: Analyze the error message

    The error says no matches for kind "CustomResourceDefinition" in version "v1beta1" which means the API version is not supported.
  2. Step 2: Check Kubernetes API version support

    Since Kubernetes 1.22+, the v1beta1 version for CustomResourceDefinition is removed; use apiextensions.k8s.io/v1 instead.
  3. Final Answer:

    Using deprecated API version v1beta1 instead of apiextensions.k8s.io/v1 -> Option C
  4. Quick Check:

    Deprecated API version causes no match error [OK]
Hint: Use apiextensions.k8s.io/v1 for CRD, not v1beta1 [OK]
Common Mistakes:
  • Ignoring API version deprecation
  • Assuming missing metadata causes this error
  • Blaming YAML indentation without checking version
5. You want to create a custom resource named Gadget with group devices.example.com and version v1. Which is the correct minimal spec section of the CustomResourceDefinition YAML?
hard
A. group: devices.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: gadgets singular: gadget kind: Gadget
B. group: devices.example.com version: v1 scope: Cluster names: plural: gadgets kind: Gadget
C. apiVersion: v1 group: devices.example.com versions: - name: v1 served: false storage: true scope: Namespaced names: plural: gadgets kind: Gadget
D. group: devices.example.com versions: - name: v2 served: true storage: true scope: Namespaced names: plural: gadgets singular: gadget kind: Gadget

Solution

  1. Step 1: Check group and version correctness

    The group must be devices.example.com and version v1 served and storage true.
  2. Step 2: Validate scope and names

    Scope should be Namespaced (common default), and names must include plural, singular, and kind Gadget.
  3. Step 3: Eliminate wrong options

    group: devices.example.com version: v1 scope: Cluster names: plural: gadgets kind: Gadget uses singular version field and Cluster scope, apiVersion: v1 group: devices.example.com versions: - name: v1 served: false storage: true scope: Namespaced names: plural: gadgets kind: Gadget has served false, group: devices.example.com versions: - name: v2 served: true storage: true scope: Namespaced names: plural: gadgets singular: gadget kind: Gadget uses version v2 instead of v1.
  4. Final Answer:

    group: devices.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: gadgets singular: gadget kind: Gadget -> Option A
  5. Quick Check:

    Correct group, version, scope, and names = A [OK]
Hint: Use served: true and storage: true for active versions [OK]
Common Mistakes:
  • Using version instead of versions list
  • Setting served: false disables API
  • Mismatching version name or group
  • Omitting singular name