Clarify behavior of parallel pod management policy of stateful sets

[mittal-ishaan]

Problem:
I was facing the issue described in kubernetes/kubernetes#67250

The way around discussed by community users to avoid this is to set the podManagementPolicy to Parallel. As suggested here

I have tried this and it works as expected, when I update the pod template to a good configuration it terminates all pods and does not wait for pods to be Running and Ready or completely terminated before launching or terminating another Pod.

All was good until I read the documentation for podManagementPolicy further, I saw one more line stated here

This option only affects the behaviour for scaling operations. Updates are not affected.

Setting it to Parallel worked for me and when I update the configuration, it works, contradicting what the above line in the docs says.

I went through the code for it and saw

https://github.com/kubernetes/kubernetes/blob/88313a445174e21ed326f40802429b854e5be9ba/pkg/controller/statefulset/stateful_set_control.go#L436-L440

when we set podManagementPolicy to parallel, monotonic is set to false and we never enter this if block. this in turn at the end leads to updating the pods.

https://github.com/kubernetes/kubernetes/blob/88313a445174e21ed326f40802429b854e5be9ba/pkg/controller/statefulset/stateful_set_control.go#L459

Proposed Solution:
This doc change was added for the Kubernetes 1.11 version and I suppose the code has changed for it since then. I have verified that updates are indeed affected by the parallel pod management policy. We should update the docs to remove the line stating updates are not affected.

Page to Update:
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset

Kubernetes Version: v1.30.0

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Ritikaa96]

/sig apps
/sig architecture
/sig scheduling
/kind bug

[mittal-ishaan]

Hey,
Wanted to know, if there is any update on this

[ayushpatil2122]

/assign

[tengqm]

/sig apps

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[EronWright]

I would appreciate some clarifying remarks about how the parallel policy relates to revision changes. I would guess that is what the term 'update' means here. As discussed in kubernetes/kubernetes#67250, the parallel policy seems to unblock a stuck rollout, meaning that it does affect updates. Meanwhile, according to kubernetes/kubernetes#96218, it should not affect updates. Then there's the MaxUnavailable flag to consider, since it is said to have an additional effect (though I haven't observed any relation to this issue).

I think the documentation should be changed to say more (not less) about the behavior of updates (revision changes).