In this lesson, you will learn how Kubernetes tracks your deployment changes and how to prune old history to keep your cluster metadata clean.
The Deployment Revision Trail
Every time you perform an update to a Deployment—such as changing a container image tag or updating environment variables—Kubernetes creates a new "Revision." This acts as a snapshot of your deployment configuration at that specific moment. These snapshots are what allow you to perform rollbacks if a new release causes issues.
You can view the history of these revisions by running:
kubectl rollout history deployment/my-app
This command returns a list of revision numbers. Because Kubernetes stores these revisions in the cluster's etcd database, having an infinite number of them can eventually clutter your environment and consume unnecessary storage.
Cleaning Up Old History
By default, Kubernetes keeps a large number of revisions (the default is usually 10). However, in automated CI/CD pipelines where you might deploy dozens of times a day, this history can grow quite large.
To manage this, you can configure the revisionHistoryLimit field in your Deployment’s spec. This field tells Kubernetes exactly how many old ReplicaSets (which represent the actual history) should be kept for rollback purposes.
spec:
revisionHistoryLimit: 5
template:
...
When you set revisionHistoryLimit: 5, Kubernetes will automatically delete the oldest Replicasets once you exceed that number, ensuring that only the most relevant snapshots remain.
Why manage this?
While it might seem trivial, maintaining a clean revision history is a "hygiene" practice. It prevents the kubectl rollout history output from becoming unmanageable and helps keep the cluster’s internal object store lean. If you are just starting out, setting this to a modest number like 3 or 5 is a great way to ensure you have enough history to roll back from a bad change without keeping obsolete data forever.
Key Takeaway: Use the revisionHistoryLimit field in your Deployment spec to automate the cleanup of old snapshots and keep your cluster configuration history tidy and efficient.