Custom Resource Definitions and Operators

Kubernetes is a powerful system for managing containerised applications. Think of it as a factory floor manager. It comes with a set of standard tools to handle standard machines: you can tell it to run a machine (a Pod), expose it to the network (a Service), or keep a certain number of machines running (a ReplicaSet). But what if you need to manage a very specific machine, like a custom-built database that requires a special startup sequence and regular backups? The standard tools don't understand this machine's unique needs. This is where Custom Resource Definitions (CRDs) and Operators come in.

A Custom Resource Definition (CRD) is the act of creating a new, custom type of object within the Kubernetes API. The API is the set of rules and commands you use to talk to your factory floor manager. Normally, you can only tell it about Pods, Services, and Deployments. A CRD lets you add a new object type, let's call it "MyCustomDatabase." You define its rules in a YAML file. For example, you specify that every MyCustomDatabase object must have fields like version, storageSize, and backupSchedule. Once you apply this CRD to your cluster, you can now create instances of MyCustomDatabase just like you create Pods. In fact, you can use the familiar command kubectl get mycustomdatabases to list them. This is a fundamental extension of Kubernetes.

Now you have the ability to declare you want a MyCustomDatabase, but Kubernetes still doesn't know how to bring one to life or keep it healthy. This is where the Operator comes in. An Operator is a custom controller (a self-running program) that watches for the custom objects you defined with the CRD. It is essentially a piece of software that contains all the operational knowledge a human expert would have about your specific database.

Let's break down the Operator's workflow. First, you install the Operator (often as a Deployment) into your cluster. The Operator is programmed to watch the Kubernetes API for events related to your custom resource (MyCustomDatabase). When you use kubectl apply -f mydb.yaml to create a new MyCustomDatabase object, the Operator sees this event. It then takes action. Its actions can include: creating the necessary Pod with the correct database image, creating a PersistentVolumeClaim for storage, setting up a network Service for access, and starting the initial database backup schedule. The Operator doesn't stop after creation. It continuously monitors the state of the database. If the database Pod crashes, the Operator can automatically recreate it with the correct configuration. If you update the MyCustomDatabase object to request a larger storage size, the Operator might automatically trigger a storage expansion. This is the key difference: an Operator manages the entire lifecycle of an application, not just deployment.

Without this pattern, you would have to write complex scripts and CronJobs to handle these tasks manually. You would have to write a script to create the Pod, another to set up the backups, and another to handle failures. You are essentially building an application that runs inside Kubernetes to manage another application. Why does this exist? It exists to automate the work of a skilled human operator. In large-scale systems, you cannot have a person manually configuring and restarting databases every time something fails. The Operator codifies that expertise into a program that never sleeps.

The CKAD exam focuses on the practicalities of working with CRDs and a basic Operator, not on writing your own Operator from scratch. You need to understand how to create a CRD from a YAML manifest. The exam expects you to know the structure of a CRD, specifically the spec.names and spec.scope fields. The scope field determines if your custom resource is namespaced (exists within a single namespace) or cluster-scoped (global). You also need to understand how to create an instance of the custom resource by using your CRD's definitions. The exam might ask you to deploy a pre-built Operator from a Helm chart or a set of YAML files. The critical skill is understanding the relationship: the CRD defines the blueprints, and the Operator is the builder that brings those blueprints to life and maintains them.

An IT professional at a mid-sized company is tasked with managing a MongoDB cluster for a critical financial application. The traditional approach would be to manually install MongoDB on a virtual machine, configure replica sets, set up monitoring, and create backup scripts. This is error-prone and does not scale. Instead, the engineer decides to use a Kubernetes Operator for MongoDB.

The engineer begins by installing the MongoDB Operator. This is usually done by applying a set of YAML files or using a Helm chart. Once the Operator's Pod is running, it is actively watching the Kubernetes API for a specific custom resource, typically named something like MongoDB or MongoDBCluster. The engineer then creates a YAML file that defines their desired MongoDB cluster state. This file is an instance of the custom resource. It might look like this:

When the engineer runs kubectl apply -f financial-mongodb.yaml, the Operator sees this new object. Because the Operator is programmed with MongoDB expertise, it does the following:

Six months later, the finance team needs to increase the database storage. The engineer simply edits the MongoDB custom resource YAML file, changing a storageSize field, and re-applies it: kubectl apply -f financial-mongodb.yaml. The Operator detects the change and automatically triggers a storage expansion operation on the underlying PersistentVolumeClaim, a task that would normally require manual database intervention.

A few weeks later, a node fails and one of the MongoDB Pods is destroyed. The Operator's reconciliation loop detects the mismatch between the desired state (3 healthy members) and the actual state (2 healthy members). The Operator automatically creates a new Pod on a healthy node and configures it to re-join the Replica Set, ensuring zero data loss and minimal downtime. The human operator is alerted but does not need to act. This is the value proposition: the Operator handles complex, recurring operational tasks, freeing the IT professional to work on higher-level features instead of fixing production databases at 3 AM.