Figure 22-1 shows how a controller registers itself as an event listener for detecting changes on the managed resources. It observes the current state and changes it by calling out to the API Server to get closer to the target state (if necessary). Controllers are part of Kubernetes’ control plane, and it became clear early on that they would also allow extending the platform with custom behavior. Moreover, they have turned into the standard mechanism for extending the platform and enable complex application lifecycle management. And as a result, a new generation of more sophisticated controllers was born, called  Operators . From an evolutionary and com‐ plexity point of view, we can classify the active reconciliation components into two groups: Controllers A simple reconciliation process that monitors and acts on standard Kubernetes resources. More often, these controllers enhance platform behavior and add new platform features. Operators A sophisticated reconciliation process that interacts with  CustomResourceDefini tions  (CRDs), which are at the heart of the  Operator  pattern. Typically, these Operators  encapsulate complex application domain logic and manage the full application lifecycle. We discuss  Operators  in depth in Chapter 23. As stated previously, these classifications help introduce new concepts gradually. Here, we focus on the simpler  Controllers , and in the next chapter, we introduce CRDs and build up to the  Operator  pattern. To avoid having multiple controllers acting on the same resources simultaneously, controllers use the  SingletonService  pattern explained in Chapter 10. Most controllers are deployed just as Deployments, but with one replica, as Kubernetes uses optimistic locking at the resource level to prevent concurrency issues when changing resource objects. In the end, a controller is nothing more than an application that runs perma‐ nently in the background. Solution  |  177 Figure 22-1. Observe-Analyze-Act cycle