Kubernetes Foundations: Objects, Controllers, and Reconciliation

Declarative state changes the operating model

Kubernetes accepts API objects that describe a desired result: a Deployment should maintain a certain number of replicas, a Service should expose selected pods, or a ConfigMap should contain named configuration values. A manifest describes that intent. It does not mean the API server executes each line once as an imperative deployment script.

The API server stores objects, and controllers watch relevant changes. A Deployment controller creates or updates a ReplicaSet; the ReplicaSet controller works toward the desired pod count. The scheduler assigns unscheduled pods to nodes, and kubelets on those nodes try to make containers match the pod specification. Several cooperating loops converge toward the requested state.

Reconciliation is continuous

A controller observes current state, compares it with desired state, and takes an action. If a node fails and a pod disappears, a controller can create a replacement. If the replacement cannot be scheduled, the desired replica count remains visible while the actual count falls short. Kubernetes can keep trying, but it cannot manufacture CPU, memory, or a healthy dependency.

This is why manually editing a generated pod is usually temporary. Its owner may recreate it from the Deployment template. Change the object that owns the desired configuration, then observe the reconciliation and rollout.

Labels and selectors form relationships

Labels are key-value metadata used for selection. A Service selects pods by its selector and provides a stable network identity as pods are replaced. A Deployment's pod-template labels must match the selector it manages. A selector mismatch can leave a Service with no endpoints or a controller unable to manage the intended pods.

Keep labels meaningful and stable. Avoid using a label that changes on every build as the sole selector for a long-lived Service. Inspect endpoints when networking appears broken; a Service existing does not prove it selected any ready pods.

Learn to inspect ownership

Start with object status, events, and the ownership chain. kubectl describe deployment, kubectl get replicasets, and kubectl get pods --show-labels reveal different parts of the reconciliation story. Events often report image pull failures, scheduling constraints, or probe failures before application logs explain anything.

The operating mental model

Kubernetes is a collection of APIs and reconciliation loops, not a magical process manager. Declare the intended state, understand which controller owns each object, and inspect the difference between desired and observed state. This foundation makes rollouts, probes, scheduling, and autoscaling far easier to reason about.