Liveness probe concept in Kubernetes - Time & Space Complexity
We want to understand how the time cost of running a liveness probe changes as the number of containers grows.
How does the system handle checking many containers to keep them healthy?
Analyze the time complexity of the following Kubernetes liveness probe configuration.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: app-container
image: myapp:latest
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
This code sets a liveness probe that checks the /healthz path on port 8080 every 10 seconds after an initial delay.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The kubelet repeatedly sends HTTP GET requests to the container's /healthz endpoint.
- How many times: This happens every 10 seconds indefinitely for each container with a liveness probe.
As the number of containers with liveness probes increases, the kubelet must perform more health checks.
| Input Size (n) | Approx. Operations per period |
|---|---|
| 10 containers | 10 HTTP requests every 10 seconds |
| 100 containers | 100 HTTP requests every 10 seconds |
| 1000 containers | 1000 HTTP requests every 10 seconds |
Pattern observation: The number of health check requests grows directly with the number of containers.
Time Complexity: O(n)
This means the time spent checking container health grows linearly as you add more containers.
[X] Wrong: "The liveness probe checks happen only once or very rarely, so adding containers doesn't affect performance much."
[OK] Correct: The kubelet runs these checks repeatedly at fixed intervals for every container, so more containers mean more checks and more work.
Understanding how liveness probes scale helps you design systems that stay healthy without overloading the cluster.
"What if we changed the liveness probe to run every 5 seconds instead of 10? How would the time complexity change?"