kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update content/en/docs/concepts/workloads/controllers/deployment.md 

Co-authored-by: Tim Bannister <tim@scalefactory.com>
pull/49854/head
adriananeci 2025-02-21 16:34:40 +02:00 committed by GitHub
parent 6a7df0df22
commit faaae90b41
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
content/en/docs/concepts/workloads/controllers/deployment.md
View File

@ -1079,13 +1079,15 @@ Explicitly setting this field to 0, will result in cleaning up all the history o
thus that Deployment will not be able to roll back.
{{< /note >}}
{{< note >}}
The cleanup will ONLY start after a deployment reaches a
[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment)
For example, if pods are crash looping, and there are multiple rolling updates
The cleanup only starts **after** a Deployment reaches a
[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment).
If you set `.spec.revisionHistoryLimit` to 0, any rollout nonetheless triggers creation of a new
ReplicaSet before Kubernetes removes the old one.
Even with a non-zero revision history limit, you can have more ReplicaSets than the limit
you configure. For example, if pods are crash looping, and there are multiple rolling updates
events triggered over time, you might end up with more ReplicaSets than the
`.spec.revisionHistoryLimit` because the deployment never reaches a complete state.
{{< /note >}}
`.spec.revisionHistoryLimit` because the Deployment never reaches a complete state.
## Canary Deployment