Update content/en/docs/concepts/workloads/controllers/deployment.md
Co-authored-by: Tim Bannister <tim@scalefactory.com>pull/49854/head
parent
6a7df0df22
commit
faaae90b41
|
@ -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.
|
thus that Deployment will not be able to roll back.
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
|
||||||
{{< note >}}
|
The cleanup only starts **after** a Deployment reaches a
|
||||||
The cleanup will ONLY start after a deployment reaches a
|
[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment).
|
||||||
[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment)
|
If you set `.spec.revisionHistoryLimit` to 0, any rollout nonetheless triggers creation of a new
|
||||||
For example, if pods are crash looping, and there are multiple rolling updates
|
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
|
events triggered over time, you might end up with more ReplicaSets than the
|
||||||
`.spec.revisionHistoryLimit` because the deployment never reaches a complete state.
|
`.spec.revisionHistoryLimit` because the Deployment never reaches a complete state.
|
||||||
{{< /note >}}
|
|
||||||
|
|
||||||
## Canary Deployment
|
## Canary Deployment
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue