Origin of the specs

On resources, controllers and loops.

We have most of the development-related basics covered by now, but in order to establish an understanding of how a cluster works, I'd like to deliver on a promise made earlier and connect some more of the dots we've specked our mental canvas with.

We understand that throughout our usage of Kubernetes we are dealing with objects representing resources defined on an API. The lifecycle of an object begins with a resource definition on the API followed by its actual creation, and ultimately ends with its deletion and consequent removal with lots of updates and state changes in between in order to adhere to a desired state at all times to satisfy our requirements.

Components responsible for resource lifecycle management are called controllers. Put simply, a controller is a program, which is looking for certain kinds of resources it is assigned to process and performs tasks that have to do with them. This is a continuous activity which runs in circles, ensuring resources are maintained - checking for new objects to be created as well as tracking and updating the state of existing ones, and also deleting those slated for removal. These circles are called reconciliation loops or control loops. There are various controllers at play which cater for different kinds of resources, and most of them are technically implemented by an aptly named cluster component named "kube-controller-manager" in a configurable manner.

(The principles discussed before still apply - like pretty much any software that runs in such a cluster, these also run in containers - and therefore in pods in namespaces - and communicate with the Kubernetes API.)

A Kubernetes cluster is highly extensible and is able to accommodate resources out of its initial scope to support a vast range of use-cases. These are generally referred to as custom resources and in order to have them represented on the API, corresponding custom resource definitions (aka CRDs) are needed as well as a controller that will run the above mentioned circles for them. Once these are all in place, the custom resources (new kinds, if you will) can be used in the exact same manner as their built-in counterparts.

With the groundwork now laid, we'll proceed further - please stand by.