Kubernetes Operators u0026 Custom Resource Definitions (CRDs) Quiz Quiz

Delve into the fundamentals of Kubernetes Operators and Custom Resource Definitions (CRDs) with these targeted questions. This quiz checks your knowledge on CRD creation, Operator patterns, resource reconciliation, and their practical use in extending Kubernetes with custom workflows.

1. Purpose of CRDs

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

   1. To restrict user access to specific namespaces
   2. To speed up pod deployment times by customizing the scheduler
   3. To upgrade existing system components without downtime
   4. To introduce new resource types that behave like built-in Kubernetes objects

   Explanation: CRDs enable users to define their own resource types, making them recognizable and manageable by Kubernetes just like built-in objects. This extensibility is its main function. Customizing scheduler behavior or performing system upgrades are managed differently in Kubernetes and are not the role of CRDs. While access control is important, it is handled by authorization mechanisms, not CRDs.

2. Operator Lifecycle Management

   When building a Kubernetes Operator, which component is responsible for watching resource changes and taking action to maintain the desired state?

   1. Admission Controller
   2. Scheduler
   3. Controller
   4. Pod Disruption Budget

   Explanation: A Controller continuously monitors for changes in resources and ensures that the current state matches the desired state, which is a central concept in Operators. Admission Controllers are used for validating or mutating requests but do not maintain state. The Scheduler assigns pods to nodes, and Pod Disruption Budget is a policy for pod availability, neither of which maintains resource state.

3. Custom Resource Schema

   Which field in a CRD YAML file is essential for defining the structure and validation of the custom resource's spec?

   1. strategy
   2. initContainers
   3. validation
   4. status

   Explanation: The 'validation' field specifies the schema, setting rules for the resource's structure and contents, which is critical for proper management of custom resources. The 'status' field holds observed information but does not define validation. 'initContainers' is related to pods and not to CRDs. 'strategy' defines deployment strategies for workloads, not schema validation.

4. Operator Patterns

   Which Operator pattern describes an Operator that not only creates resources but also reacts to external system changes, such as restoring data when a backup fails?

   1. Imperative
   2. Reactive
   3. Active
   4. Stateless

   Explanation: A Reactive Operator responds to events and changes both within and outside the cluster, such as handling failures or performing recoveries automatically. The Active pattern is not commonly recognized in Operator documentation. Stateless refers to ignoring persistent state, and Imperative deals more with manual interventions rather than automated reactions.

5. CRD Versioning

   If you update the schema of an existing CRD that has running custom resources, what is the recommended approach to prevent disruption?

   1. Delete all existing resources before applying the new CRD schema
   2. Directly overwrite the existing schema without versioning
   3. Introduce a new version under 'spec.versions' and support both old and new schemas
   4. Manually edit each custom resource to match the new schema before updating

   Explanation: Adding a new version under 'spec.versions' allows safe migration and backward compatibility, avoiding resource disruptions. Deleting resources leads to unwanted data loss, while overwriting the schema may cause conflicts and errors. Manually editing each resource is error-prone and inefficient compared to versioning.