which in turn creates other events, like Pod-created events. These events are then potentially picked up again by other controllers, which perform their specific actions. 

The whole process is also known as state reconciliation , where a target state (the num‐ ber of desired replicas) differs from the current state (the actual running instances), and it is the task of a controller to reconcile and reach the desired target state again. When looked at from this angle, Kubernetes essentially represents a distributed state manager. You give it the desired state for a component instance, and it attempts to maintain that state should anything change. 

How can we now hook into this reconciliation process without modifying Kubernetes code and create a controller customized for our specific needs? 

## Solution 

Kubernetes comes with a collection of built-in controllers that manage standard Kubernetes resources like ReplicaSets, DaemonSets, StatefulSets, Deployments, or Services. These controllers run as part of the Controller Manager, which is deployed (as a standalone process or a Pod) on the master node. These controllers are not aware of one another. They run in an endless reconciliation loop, to monitor their resources for the actual and desired state, and to act accordingly to get the actual state closer to the desired state. 

However, in addition to these out-of-the-box controllers, the Kubernetes event- driven architecture allows us to plug in natively other custom controllers. Custom controllers can add extra functionality to the behavior state change events, the same way as the internal controllers do. A common characteristic of controllers is that they are reactive and react to events in the system to perform their specific actions. At a high level, this reconciliation process consists of the following main steps: 

Observe 

Discover the actual state by watching for events issued by Kubernetes when an observed resource changes. 

Analyze 

Determine the differences from the desired state. 

Act 

Perform operations to drive the actual to the desired state. 

For example, the ReplicaSet controller watches for ReplicaSet resource changes, ana‐ lyzes how many Pods need to be running, and acts by submitting Pod definitions to the API Server. Kubernetes’ backend is then responsible for starting up the requested Pod on a node. 

