Back to 20 Concepts
k8s-core • Advanced
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.