Deployment status and history in Kubernetes - Time & Space Complexity
When checking deployment status and history in Kubernetes, we want to know how the time to get this information changes as the number of deployments grows.
We ask: How does the time to retrieve status and history grow when there are more deployments or revisions?
Analyze the time complexity of the following commands.
kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app
kubectl rollout history deployment/my-app --revision=3
These commands check the current status and list the revision history of a deployment named "my-app".
Look for repeated steps in fetching and displaying deployment data.
- Primary operation: Iterating over deployment revisions to list history.
- How many times: Once per revision in the deployment's history.
The time to get the current status stays about the same no matter how many revisions exist.
But listing history takes longer as the number of revisions grows, because it shows each revision.
| Input Size (n = revisions) | Approx. Operations |
|---|---|
| 10 | 10 operations (one per revision) |
| 100 | 100 operations |
| 1000 | 1000 operations |
Pattern observation: The time grows linearly with the number of revisions when listing history.
Time Complexity: O(n)
This means the time to list deployment history grows directly with the number of revisions.
[X] Wrong: "Checking deployment status takes longer as history grows."
[OK] Correct: Checking current status only looks at the latest state, so it stays fast regardless of history size.
Understanding how commands scale with data size helps you explain system behavior clearly and shows you know what affects performance in real tools.
"What if we added a filter to show only the last 5 revisions? How would the time complexity change?"