Desired state vs actual state reconciliation in Kubernetes - Performance Comparison
We want to understand how the work done by Kubernetes grows as it checks and fixes the cluster state.
How does the time to match the desired state with the actual state change when the cluster size grows?
Analyze the time complexity of the reconciliation loop in Kubernetes.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: app
image: example-image
# Controller watches all Pods and compares desired vs actual state
for each pod in cluster {
if pod.actualState != pod.desiredState {
update pod to desiredState
}
}
This code watches all pods and updates any that do not match the desired state.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through all pods in the cluster to check their state.
- How many times: Once per reconciliation cycle, the loop runs once for each pod.
As the number of pods increases, the controller must check each one, so the work grows with the number of pods.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 checks and possible updates |
| 100 | 100 checks and possible updates |
| 1000 | 1000 checks and possible updates |
Pattern observation: The work grows directly with the number of pods; doubling pods doubles the work.
Time Complexity: O(n)
This means the time to reconcile grows linearly with the number of pods in the cluster.
[X] Wrong: "The reconciliation time stays the same no matter how many pods there are."
[OK] Correct: The controller must check each pod, so more pods mean more work and more time.
Understanding how Kubernetes controllers scale their work helps you explain system behavior and design efficient solutions.
"What if the controller only checked pods that changed instead of all pods? How would the time complexity change?"