Custom resources concept in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of a Custom Resource in Kubernetes?

In Kubernetes, what is the main reason to create a Custom Resource?

A To create a new namespace automatically for each deployment

B To replace the Kubernetes API server with a custom implementation

C To extend Kubernetes with new object types beyond built-in resources

D To manage user authentication and authorization

💡 Hint

Think about how Kubernetes can be customized to manage new kinds of objects.

Custom Resources allow users to add new types of objects to Kubernetes, enabling management of resources not originally included.

💻 Command Output

intermediate

Output of listing Custom Resource Definitions

What is the output of the command kubectl get crd in a Kubernetes cluster with two Custom Resource Definitions named widgets.example.com and gadgets.example.com?

Kubernetes

kubectl get crd

A

NAME                   STATUS
widgets.example.com     Active
gadgets.example.com     Active

B

NAME                   CREATED AT
widgets.example.com     2024-01-01T12:00:00Z
gadgets.example.com     2024-01-02T12:00:00Z

C No resources found in default namespace.

D Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io not found

💡 Hint

Think about what kubectl get crd lists and the typical columns shown.

The command lists all Custom Resource Definitions with their names and creation timestamps.

❓ Configuration

advanced

Correct YAML for defining a Custom Resource Definition

Which YAML snippet correctly defines a Custom Resource Definition (CRD) for a resource named widgets in group example.com with version v1?

A

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

B

apiVersion: v1
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
spec:
  group: example.com
  version: v1
  scope: Cluster
  names:
    plural: widgets
    kind: Widget

C

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

D

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

💡 Hint

Check the API version and the structure of the spec section for CRDs.

Option D uses the correct API version apiextensions.k8s.io/v1 and properly defines the versions list with served and storage fields.

🔀 Workflow

advanced

Order of steps to create and use a Custom Resource

Arrange the steps in the correct order to create and use a Custom Resource in Kubernetes.

A 1,3,2,4

B 3,1,2,4

C 1,2,3,4

D 2,1,3,4

💡 Hint

Think about registering the CRD before creating resources and verifying registration before usage.

First define and apply the CRD, then verify it is registered, next create resource instances, and finally manage them.

❓ Troubleshoot

expert

Reason for 'no matches for kind' error when applying a Custom Resource

You applied a Custom Resource YAML manifest but got the error: error: unable to recognize "widget.yaml": no matches for kind "Widget" in version "example.com/v1". What is the most likely cause?

A The Custom Resource Definition (CRD) for kind Widget is not installed or not yet registered in the cluster.

B The user does not have permission to create Custom Resources.

C The Kubernetes API server is down and cannot process the request.

D The YAML manifest has a syntax error in the spec section of the Custom Resource.

💡 Hint

Consider whether the cluster knows about the new resource kind before you create instances.

This error usually means the CRD is missing or not yet active, so Kubernetes does not recognize the resource kind.

Practice

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