Back to 20 Concepts
k8s-coreAdvanced

Kubernetes Control Plane: Declarative Reconciliation Loop

The Kubernetes Control Plane maintains desired cluster state through continuous reconciliation: kube-apiserver (REST hub) <-> etcd (Raft state store) <-> kube-scheduler (Node placement) <-> kube-controller-manager (Reconciliation loops).

Intuitive Mental Model

The Thermostat & HVAC System: You set the desired temperature to 72°F (Declarative YAML manifest). The thermostat constantly measures actual temperature against desired state (Reconciliation Loop) and turns on the furnace until Actual == Desired.

Dockerfile / YAML Manifest / CLIProduction Standard
# Declarative Manifest (Specify DESIRED state, not imperative steps):
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3 # Desired State: Exactly 3 Pods
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: server
        image: api:v2.0
        resources:
          limits:
            memory: "256Mi"
            cpu: "500m"

Key Architectural Takeaways

  • Declarative Model: You declare the target end state; Kubernetes controllers continuously execute reconciliation loops to converge actual state to desired state.
  • etcd: Distributed, consistent Raft-replicated key-value store containing the single source of truth for the entire cluster.
  • kube-apiserver is the ONLY component that directly communicates with etcd; all other controllers watch the API server via HTTP long-polling.
Common Production Mistake

Using imperative kubectl create/replace commands in production CI/CD instead of declarative kubectl apply -f.

Recommended Solution

Always use kubectl apply -f with GitOps controllers (ArgoCD, Flux) for automated reconciliation.