Desired state vs actual state reconciliation in Kubernetes - Visual Side-by-Side Comparison

Process Flow - Desired state vs actual state reconciliation

User defines desired state

↓

Kubernetes stores desired state

↓

Controller checks actual state

↓

Compare actual state with desired state

↓

Do nothing

↓

Update actual state

↓

Loop back to check actual state

This flow shows how Kubernetes controllers continuously compare the desired state with the actual state and make changes to keep the system as the user wants.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest

This YAML defines the desired state of a Pod named 'my-pod' running an nginx container.

Process Table

Step	Action	Desired State	Actual State	Comparison Result	Controller Action
1	User applies Pod YAML	Pod 'my-pod' with nginx container	No Pod exists	No match	Create Pod 'my-pod'
2	Controller checks cluster	Pod 'my-pod' with nginx container	Pod 'my-pod' starting	Partial match	Wait for Pod to be ready
3	Pod starts running	Pod 'my-pod' with nginx container	Pod 'my-pod' running	Match	No action needed
4	Pod crashes unexpectedly	Pod 'my-pod' with nginx container	Pod 'my-pod' crashed	No match	Restart Pod
5	Pod restarts and runs	Pod 'my-pod' with nginx container	Pod 'my-pod' running	Match	No action needed
6	User deletes Pod YAML	No Pod desired	Pod 'my-pod' running	No match	Delete Pod 'my-pod'
7	Pod deleted	No Pod desired	No Pod exists	Match	No action needed

💡 Desired state matches actual state; reconciliation complete.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	After Step 6	Final
Desired State	No Pod	Pod 'my-pod' with nginx	Pod 'my-pod' with nginx	Pod 'my-pod' with nginx	No Pod	No Pod
Actual State	No Pod	Pod 'my-pod' starting	Pod 'my-pod' running	Pod 'my-pod' crashed	Pod 'my-pod' running	No Pod

Key Moments - 3 Insights

Why does the controller restart the Pod after it crashes instead of creating a new one?

The controller sees the Pod exists but is not in the desired running state (Step 4). It tries to fix the actual state by restarting the existing Pod to match the desired state, not by creating a new Pod.

What happens if the desired state is deleted but the Pod still runs?

The controller detects the mismatch (Step 6) and deletes the running Pod to match the desired state of no Pod.

Why does the controller sometimes wait instead of acting immediately?

When the Pod is starting (Step 2), the actual state partially matches the desired state, so the controller waits for the Pod to become ready before taking further action.

Visual Quiz - 3 Questions

Look at the execution table, what is the actual state at Step 3?

A No Pod exists

B Pod 'my-pod' crashed

C Pod 'my-pod' running

D Pod 'my-pod' starting

💡 Hint

Check the 'Actual State' column for Step 3 in the execution table.

At which step does the controller delete the Pod to match the desired state?

A Step 4

B Step 6

C Step 2

D Step 1

💡 Hint

Look for the step where desired state is 'No Pod' but actual state is 'Pod running'.

If the Pod never crashes, which steps would be skipped?

A Steps 4 and 5

B Steps 2 and 3

C Steps 6 and 7

D Steps 1 and 2

💡 Hint

Check the steps related to Pod crashing and restarting in the execution table.

Concept Snapshot

Desired state is what you want the system to be.
Actual state is what is currently running.
Kubernetes controllers compare both.
If they differ, controllers act to fix actual state.
This loop keeps your system stable and as you defined.

Full Transcript

In Kubernetes, you tell the system what you want by defining the desired state, like a Pod running nginx. The system checks what is actually running, called the actual state. If the actual state does not match the desired state, Kubernetes controllers take action to fix it. For example, if the Pod crashes, the controller restarts it. If you delete the Pod definition, the controller deletes the running Pod. This continuous check and fix process is called reconciliation, and it keeps your cluster running as you want.

Practice

1. What does Kubernetes do when the actual state of a pod differs from the desired state?

easy

A. It changes the actual state to match the desired state automatically.

B. It deletes the pod without recreating it.

C. It ignores the difference and does nothing.

D. It sends an alert but does not change anything.

Solution

1. Step 1: Understand desired vs actual state

   The desired state is what you want Kubernetes to have running, and the actual state is what is currently running.

2. Step 2: Kubernetes reconciliation process

   Kubernetes continuously compares actual state to desired state and makes changes to fix any differences automatically.

3. Final Answer:

   It changes the actual state to match the desired state automatically. -> Option A

4. Quick Check:

   Reconciliation means fixing actual state to desired state [OK]

Hint: Kubernetes fixes differences automatically [OK]

Common Mistakes:

• Thinking Kubernetes ignores differences
• Believing Kubernetes only alerts without fixing
• Assuming Kubernetes deletes pods without recreating

2. Which Kubernetes component is responsible for ensuring the actual state matches the desired state?

easy

A. kube-apiserver

B. kube-scheduler

C. etcd

D. kube-controller-manager

Solution

1. Step 1: Identify the role of kube-controller-manager

   The kube-controller-manager runs controllers that watch the desired state and make changes to match the actual state.

2. Step 2: Differentiate other components

   kube-apiserver handles API requests, kube-scheduler assigns pods to nodes, and etcd stores cluster data but does not reconcile states.

3. Final Answer:

   kube-controller-manager -> Option D

4. Quick Check:

   Controllers fix state differences [OK]

Hint: Controllers fix state differences [OK]

Common Mistakes:

• Confusing scheduler with controller
• Thinking apiserver reconciles state
• Assuming etcd manages reconciliation

3. Given this YAML snippet for a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: web
        image: nginx:1.19

If one pod crashes and stops running, what will Kubernetes do?

medium

A. Create a new pod to maintain 3 replicas.

B. Do nothing and keep 2 pods running.

C. Delete all pods and restart the deployment.

D. Scale down the deployment to 2 replicas.

Solution

1. Step 1: Understand the desired replicas

   The Deployment specifies 3 replicas, so Kubernetes wants 3 pods running.

2. Step 2: Reconciliation after pod crash

   If one pod crashes, Kubernetes detects the actual state has only 2 pods and creates a new pod to restore 3 replicas.

3. Final Answer:

   Create a new pod to maintain 3 replicas. -> Option A

4. Quick Check:

   Pods count fixed to desired replicas [OK]

Hint: Pods auto-recreated to match replicas [OK]

Common Mistakes:

• Thinking Kubernetes ignores crashed pods
• Assuming deployment restarts all pods
• Believing deployment scales down automatically

4. You notice a Deployment is stuck with fewer pods than desired. Which of these is a likely cause preventing reconciliation?

medium

A. The kube-apiserver is running normally.

B. The image name in the container spec is correct.

C. The Deployment's selector labels do not match pod labels.

D. The desired replicas count is set to 3.

Solution

1. Step 1: Check label selectors for matching pods

   If the Deployment's selector labels do not match pod labels, Kubernetes cannot track pods correctly, so reconciliation fails.

2. Step 2: Understand other options

   Correct image name, running apiserver, and desired replicas do not prevent reconciliation by themselves.

3. Final Answer:

   The Deployment's selector labels do not match pod labels. -> Option C

4. Quick Check:

   Label mismatch blocks reconciliation [OK]

Hint: Selector and pod labels must match [OK]

Common Mistakes:

• Ignoring label selector importance
• Blaming image name for pod count issues
• Assuming apiserver status causes pod count

5. You want to update a Deployment's container image from nginx:1.19 to nginx:1.21. After applying the change, you see some pods still run the old image. What explains this behavior in terms of desired vs actual state reconciliation?

hard

A. Kubernetes ignores image changes unless manually restarted.

B. Kubernetes gradually updates pods to match desired state using rolling updates.

C. Kubernetes cannot update pods without deleting the Deployment.

D. Kubernetes immediately deletes all old pods and creates new ones.

Solution

1. Step 1: Understand rolling update strategy

   Kubernetes uses rolling updates to gradually replace old pods with new ones to avoid downtime.

2. Step 2: Explain why old pods remain temporarily

   During rolling update, some pods run old image until replaced, so actual state temporarily differs from desired state.

3. Final Answer:

   Kubernetes gradually updates pods to match desired state using rolling updates. -> Option B

4. Quick Check:

   Rolling update means gradual pod replacement [OK]

Hint: Rolling updates replace pods gradually [OK]

Common Mistakes:

• Expecting instant pod replacement
• Thinking Deployment must be deleted to update
• Believing Kubernetes ignores image changes