Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify behavior of parallel pod management policy of stateful sets #47085

Open
mittal-ishaan opened this issue Jul 4, 2024 · 2 comments
Open
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/apps Categorizes an issue or PR as relevant to SIG Apps. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling.

Comments

@mittal-ishaan
Copy link

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 k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jul 4, 2024
@k8s-ci-robot
Copy link
Contributor

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
Copy link
Contributor

Ritikaa96 commented Jul 4, 2024

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

@k8s-ci-robot k8s-ci-robot added sig/apps Categorizes an issue or PR as relevant to SIG Apps. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. kind/bug Categorizes issue or PR as related to a bug. labels Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/apps Categorizes an issue or PR as relevant to SIG Apps. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling.
Projects
Status: Needs Triage
Status: Needs Triage
Development

No branches or pull requests

3 participants