Extending Kubernetes With Custom Resources and Operators

We've learned that the Kubernetes API is not just a single API but also an aggregation of APIs backed by cooperative services called operators and controllers. Operators are extensions to Kubernetes that make use of custom resources to manage systems and applications via controllers. Controllers are components of operators that execute control loops for a kind of resource. A control loop for a custom resource is an iterative process that observes a desired state of the resource and works, possibly over several loops, to drive the state of a system to that desired state.

Those previous sentences are rather abstract. We like to sum it up differently. Kubernetes
is a platform for automation. Automation is a series of steps and decision trees that drives to reach an end goal. Let's think of operators in a similar way. We could think of writing operators as taking a runbook, the human steps for completing an operational activity and making the computer execute the automation. Operators and controllers are like crystallizing operational knowledge into code to be run in Kubernetes.

Custom resources can represent anything. They can be things related to Kubernetes resources, or they can be something completely external to Kubernetes. For an example of a custom resource related to cluster workloads, we discussed the OTel collector and deployed it via its container image in docker-compose, but we could have used the Kubernetes operator for OTel to do the same thing in a Kubernetes cluster. The OTel operator exposes a custom resource, like the following: