CHAPTER 22 Controller A  Controller  actively monitors and maintains a set of Kubernetes resources in a desired state. The heart of Kubernetes itself consists of a fleet of controllers that regu‐ larly watch and reconcile the current state of applications with the declared target state. In this chapter, we see how to leverage this core concept for extending the plat‐ form for our needs. You already have seen that Kubernetes is a sophisticated and comprehensive platform that provides many features out of the box. However, it is a general-purpose orches‐ tration platform that does not cover all application use cases. Luckily, it provides nat‐ ural extension points where specific use cases can be implemented elegantly on top of proven Kubernetes building blocks. The main question that arises here is about how to extend Kubernetes without chang‐ ing and breaking it, and how to use its capabilities for custom use cases. By design, Kubernetes is based on a declarative resource-centric API. What exactly do we mean by  declarative ? As opposed to an  imperative  approach, a declarative approach does not tell Kubernetes how it should act, but instead describes how the target state should look. For example, when we scale up a Deployment, we do not actively create new Pods by telling Kubernetes to “create a new Pod.” Instead, we change the Deployment resource’s  replicas  property via the Kubernetes API to the desired number. So, how are the new Pods created? This is done internally by the  Controllers . For every change in the resource status (like changing the  replicas  property value of a Deployment), Kubernetes creates an event and broadcasts it to all interested listeners. These listeners then can react by modifying, deleting, or creating new resources, 175 Problem