[KEP-3973]: docs for DeploymentPodReplacementPolicy #48370
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
size/M
👷 Deploy Preview for kubernetes-io-vnext-staging processing.
|
|
the kubernetes/kubernetes#123430 is still not merged yet |
k8s-ci-robot
added
the
do-not-merge/hold
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
| @@ -1317,6 +1330,49 @@ created Pod should be ready without any of its containers crashing, for it to be | |||
| This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when | |||
| a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). | |||
|
|
|||
| ### Pod Replacement Policy | |||
There was a problem hiding this comment.
| ### Pod Replacement Policy | |
| ### Pod replacement policies {#pod-replacement-policy} |
This aligns with the style guide, even though the rest of the page follows a mixture of styles. It could use an update.
There was a problem hiding this comment.
Wouldn't it be better to keep the name same as the name of the feature/field for a better lookup?
| {{< note >}} | ||
| If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the replacement will be created | ||
| immediately (even if the old Pod is still in a Terminating state). The Pod Replacement Policies control only | ||
| Deployment rollouts and scaling. | ||
| {{< /note >}} |
There was a problem hiding this comment.
Avoid using too many note shortcodes. Try this instead:
| {{< note >}} | |
| If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the replacement will be created | |
| immediately (even if the old Pod is still in a Terminating state). The Pod Replacement Policies control only | |
| Deployment rollouts and scaling. | |
| {{< /note >}} | |
| If you manually delete a Pod, the lifecycle of that Pod and its replacement is controlled by the associated ReplicaSet; a replacement will be created immediately. When you delete a Pod manually, and the deleted | |
| Pod was owned by a ReplicaSet, the ReplicaSet creates a new Pod as soon as you trigger deletion (even if the old Pod is still in a Terminating state). | |
| Setting a pod replacement policy for a Deployment only has an effect on: | |
| 1. rollouts for changes to a Deployment | |
| 2. changes to the scale of that Deployment |
There was a problem hiding this comment.
Thanks for the suggestions. As mentioned in #48370 (comment), I think it is better to just say rollouts. I have also removed the list at the end to keep it more compact and highlight the policies above.
| deployment. Some pods may take a long time to terminate and may consume additional resources during this | ||
| time. As a result, the total number of all pods can temporarily exceed `.spec.replicas` | ||
| (or `.spec.replicas + .spec.strategy.rollingUpdate.maxSurge` for RollingUpdate Deployments). | ||
| A `.spec.podReplacementPolicy` field can be used to control when a Deployment should create new pods. |
There was a problem hiding this comment.
| A `.spec.podReplacementPolicy` field can be used to control when a Deployment should create new pods. | |
| Providing this feature is enabled in your cluster, you can specify a `.spec.podReplacementPolicy` | |
| to control when a Deployment should create new pods. The field affects the behavior of the | |
| Deployment during scaling operations and when rolling out updates. |
There was a problem hiding this comment.
- Do we have to mention the enablement the 2nd time? I would think it is implied for the rest of the section.
- Same question about the last part. Should we mention it again? We also have it at the end.
| Deployment Pods can become terminating due to deletion, usually during the rollout or scaling of a new | ||
| deployment. Some pods may take a long time to terminate and may consume additional resources during this |
There was a problem hiding this comment.
| Deployment Pods can become terminating due to deletion, usually during the rollout or scaling of a new | |
| deployment. Some pods may take a long time to terminate and may consume additional resources during this | |
| Pods that (indirectly) belong to a Deployment can become terminating due to deletion, usually during | |
| the rollout of a change or an update to the scale of an existing Deployment. | |
| After a change to a Deployment, some pods may take a long time to terminate and may consume | |
| additional resources during that period of |
There was a problem hiding this comment.
- I think using
(indirectly)is a bit confusing. The relationship is quite direct via the owner references. rollout of a changeis also a bit confusing as it is possible to do a rollout without any change:kubectl rollout restart
atiratree
force-pushed
the
pod-replacement-policy-docs
branch
from
2887b57 to
187c7ed
Compare
atiratree
force-pushed
the
pod-replacement-policy-docs
branch
from
187c7ed to
2b59b4b
Compare
|
@sftim thanks for the review, I have included most of your suggestions. |
|
Unfortunately we did not manage to finish the API review, so this feature is postponed to 1.33 |
add docs for DeploymentPodReplacementPolicy feature