-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
1.22 feature blog for minReadySeconds in StatefulSets #28992
Conversation
✔️ Deploy Preview for kubernetes-io-main-staging ready! 🔨 Explore the source changes: bd68cc9 🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/61252b1fcbf3ba00073047f7 😎 Browse the preview: https://deploy-preview-28992--kubernetes-io-main-staging.netlify.app |
|
||
## What problems does this solve? | ||
|
||
Today, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before the `Pod` is considered `Available` and it is ready to serve requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q. Does “today” describe the situation before the v1.22 release, or after it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is before v1.22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this article goes out after the release, let's reword to make that clear.
@@ -0,0 +1,48 @@ | |||
--- | |||
layout: blog | |||
title: 'minReadySeconds for StatefulSets' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a typical format for the titles of post-release blog articles? If so, let's follow that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure of that. Where do we have style guide?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlbutler ^?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies I thought I'd replied to this. As I mentioned last week, I also think this could use a more reader-friendly title.
I don't know of any specific guideline but they do tend to be more descriptive of functionality, rather than calling out details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit more feedback.
Please do update the article to frame it as being published after the v1.22 release. That's the most important change that needs making. The other details are less essential.
KEP: https://github.com/kubernetes/enhancements/issues/2599 | ||
API Changes: https://github.com/kubernetes/kubernetes/pull/100842 | ||
Implementation PR: https://github.com/kubernetes/kubernetes/pull/101316 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KEP: https://github.com/kubernetes/enhancements/issues/2599 | |
API Changes: https://github.com/kubernetes/kubernetes/pull/100842 | |
Implementation PR: https://github.com/kubernetes/kubernetes/pull/101316 | |
- Read the KEP: [minReadySeconds for StatefulSets](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2599-minreadyseconds-for-statefulsets#readme) | |
- Read the documentation: [Minimum ready seconds](/docs/concepts/workloads/controllers/statefulset/#minimum-ready-seconds) for StatefulSet | |
- Review the [API definition](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) for StatefulSet |
|
||
## How do I get involved? | ||
|
||
Please reach out to us on [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on slack, sig-apps mailing [email protected] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please reach out to us on [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on slack, sig-apps mailing list-[email protected] | |
Please reach out to us in the [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on Slack (visit https://slack.k8s.io/ for an invitation if you need one), or on the SIG Apps mailing list: [email protected] |
The `StatefulSet` controller watches for both `StatefulSets` and the `Pods` associated with them. When the feature gate associated with this feature is enabled, the `StatefulSet` controller identifies how long a particular `Pod` associated with a `StatefulSet` has been in the `Running` state. | ||
|
||
If this value is greater than or equal to the time specified by the end user in `.spec.minReadySeconds` field, the `StatefulSet` controller updates a field called `AvailableReplicas` in the `StatefulSet`'s status subresource to include this `Pod`. The `AvailableReplicas` in `StatefulSet`'s status is a int32 field which tracks the number of pods that are `Available`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tiny nit:
The `StatefulSet` controller watches for both `StatefulSets` and the `Pods` associated with them. When the feature gate associated with this feature is enabled, the `StatefulSet` controller identifies how long a particular `Pod` associated with a `StatefulSet` has been in the `Running` state. | |
If this value is greater than or equal to the time specified by the end user in `.spec.minReadySeconds` field, the `StatefulSet` controller updates a field called `AvailableReplicas` in the `StatefulSet`'s status subresource to include this `Pod`. The `AvailableReplicas` in `StatefulSet`'s status is a int32 field which tracks the number of pods that are `Available`. | |
The statefulset controller watches for both `StatefulSets` and the `Pods` associated with them. When the feature gate associated with this feature is enabled, the statefulset controller identifies how long a particular `Pod` associated with a `StatefulSet` has been in the `Running` state. | |
If this value is greater than or equal to the time specified by the end user in `.spec.minReadySeconds` field, the statefulset controller updates a field called `availableReplicas` in the `StatefulSet`'s status subresource to include this `Pod`. The `.status.availableReplicas` field for a `StatefulSet` is an integer field that tracks the number of pods that are `Available`. |
--- | ||
layout: blog | ||
title: 'minReadySeconds for StatefulSets' | ||
date: 2021-08-27 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's handy to update the path to the Markdown file to match. Hugo doesn't care but us humans can get confused.
@ravisantoshgudimetla can you reply to review when you have a few cycles? thanks! |
@jlbutler if you're willing to make the changes needed, feel free. That'll let us review. If you want to get signoff on those changes from @ravisantoshgudimetla before we publish, add a /hold so we don't accidentally put it live without that signoff. |
I'll get to this tomorrow. Thank you for the reviews @sftim |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made the changes locally. Will push the changes to remote branch once I have access to it. The earlier collaboration invite is expired now :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sftim - Made the changes you suggested modulo the title formatting. I am not sure which format I should use. Let me know if the current title looks good. TY
cc @soltysh |
content/en/blog/_posts/2021-08-16-minreadysecond-statefulsets.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Simon Pasquier <[email protected]>
I think the title for this article is OK and we should focus on getting this merged (we can update the title after merging if we think of a new one that we really like). |
@ravisantoshgudimetla / @soltysh - between the two of you I'm happy that you can review each other's contributions here. Feel free to add /lgtm when you're happy that this can go out. LGTM - for writing style etc /hold /approve |
@soltysh has already reviewed it. We worked with @jlbutler before opening this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just a couple of small wording suggestions.
|
||
## What problems does this solve? | ||
|
||
Prior to Kubernetes 1.22 release, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before the `Pod` is considered `Available` and it is ready to serve requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prior to Kubernetes 1.22 release, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before the `Pod` is considered `Available` and it is ready to serve requests. | |
Prior to Kubernetes 1.22 release, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, that may not be the case. For example, a workload like Prometheus, with multiple instances of Alertmanager, should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a foolproof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for some time before the `Pod` is considered `Available` and ready to serve requests. |
|
||
Prior to Kubernetes 1.22 release, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before the `Pod` is considered `Available` and it is ready to serve requests. | ||
|
||
Another case, where `minReadySeconds` helps is when using `LoadBalancer` `Services` with cloud providers. Since `minReadySeconds` adds latency after a `Pod` is `Ready`, it provides buffer time to prevent killing pods in rotation before new pods show up. Imagine a load balancer in unhappy path taking 10-15s to propagate. If you have 2 replicas then, you'd kill the second replica only after the first one is up but in reality, first replica cannot be seen because it is not yet ready to serve requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another case, where `minReadySeconds` helps is when using `LoadBalancer` `Services` with cloud providers. Since `minReadySeconds` adds latency after a `Pod` is `Ready`, it provides buffer time to prevent killing pods in rotation before new pods show up. Imagine a load balancer in unhappy path taking 10-15s to propagate. If you have 2 replicas then, you'd kill the second replica only after the first one is up but in reality, first replica cannot be seen because it is not yet ready to serve requests. | |
Another case where `minReadySeconds` helps is when using `LoadBalancer` `Services` with cloud providers. Since `minReadySeconds` adds latency after a `Pod` is `Ready`, it provides buffer time to prevent killing pods in rotation before new pods show up. Imagine a load balancer in an unhappy path, taking 10-15s to propagate. If you have 2 replicas, then you'd kill the second replica only after the first one is up. But in reality, the first replica cannot be seen because it is not yet ready to serve requests. |
|
||
After successfully starting `kube-apiserver` and `kube-controller-manager`, you will see `AvailableReplicas` in the status and `minReadySeconds` of spec (with a default value of 0). | ||
|
||
Specify a value for `minReadySeconds` for any StatefulSet and you can check if `Pods` are available or not by checking `AvailableReplicas` field using: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specify a value for `minReadySeconds` for any StatefulSet and you can check if `Pods` are available or not by checking `AvailableReplicas` field using: | |
Specify a value for `minReadySeconds` for any StatefulSet and you can check if `Pods` are available or not by checking the `AvailableReplicas` field using: |
I pushed a commit to update the publication date. @ravisantoshgudimetla / @soltysh once you're happy with the wording - and “right now, actually” is a valid answer - please use the /lgtm command to record that you are. If you're not able to LGTM (“looks good to me”), or aren't comfortable running that command, reply to say so and SIG Docs can sort something out. If we get this merged and folks want to fix minor grammar or spelling nits, those can go in after the merge (and either before or after publication). If there's no LGTM before the publication date and we miss it by more than say 18 hours, we should leave the hold in place and pick a new date. |
/label tide/merge-method-squash |
Oh, I should also add: if this gets LGTM before publication is due on the 27th, please do unhold it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @jlbutler @sftim @chrisnegus for the reviews
/lgtm
LGTM label has been added. Git tree hash: 52babcf11efe5ec31d963a0d4a849d363c378797
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ravisantoshgudimetla, sftim The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
* 1.22 feature blog for minReadySeconds in StatefulSets * Address reviewer's comments * Update content/en/blog/_posts/2021-08-16-minreadysecond-statefulsets.md Co-authored-by: Simon Pasquier <[email protected]> * Bump article publication date Co-authored-by: ravisantoshgudimetla <[email protected]> Co-authored-by: Ravi Gudimetla <[email protected]> Co-authored-by: Simon Pasquier <[email protected]> Co-authored-by: Tim Bannister <[email protected]>
1.22 feature blog post for "Add minReadySeconds to Statefulsets" (kubernetes/enhancements#2599).
Target publish date is 08/27/21. [edit: updated publish date]
cc: @ravisantoshgudimetla