Understanding how Kubernetes manages your applications is crucial for effective deployment and scaling. At the heart of its power lies a fundamental concept: the distinction between the declared state and the observed state. Grasping this difference unlocks a deeper understanding of Kubernetes’ automated healing and scaling capabilities.
The declared state, often referred to as the desired state, is what you, the user, tell Kubernetes you want. You express this through configuration files like YAML manifests. This manifest describes the ideal state of your system – for example, you declare that you want three replicas of a specific application running, using a particular container image, exposed on a certain port, and utilizing specific storage. This is your intention, your blueprint for reality.
The observed state, or actual state, is the current condition of your cluster and the resources within it. This is the ground truth, what is currently happening in the cluster right now. It reflects how many pods are actually running, their current status (pending, running, failed), their IP addresses, the state of volumes, and so on. This information is gathered by various components within the Kubernetes control plane.
Kubernetes operates on a continuous reconciliation loop. The control plane constantly watches the observed state and compares it against the declared state. Its core job is to bridge any gap between what you want (declared) and what currently exists (observed).
This is where controllers come into play. These are specific processes within the control plane responsible for particular resource types (like Deployments, StatefulSets, Services, etc.). Each controller monitors resources relevant to it. If a controller detects a discrepancy – for instance, if you declared three replicas but only two are running in the observed state – it takes action.
Using the control loop, the controller initiates the necessary steps to move the system from the observed state closer to the declared state. In the replica example, the Deployment controller would instruct the API server to create a new pod. This loop is constant and automated. If a pod crashes, the controller observes that the replica count no longer matches the declared state and automatically creates a replacement. If you update the declared state (e.g., scale up to five replicas), the controller observes the change and creates two new pods to match the new desired number.
This declarative model is incredibly powerful. Instead of issuing imperative commands (“start a pod,” “delete a pod”), you simply state your desired outcome. Kubernetes then takes on the responsibility of maintaining that state, handling failures, scaling, and updates automatically. By clearly defining your declared state and relying on Kubernetes to reconcile it with the observed state, you build resilient and self-healing systems. It is this fundamental paradigm that makes Kubernetes so effective at managing complex, dynamic applications at scale.
Source: https://kifarunix.com/understanding-kubernetes-states-declared-vs-observed-states-explained/
