-
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
Pod Topology Spread blog post (KEP-3022 KEP-3094 KEP-3243) #39777
Conversation
/sig scheduling |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
Great! Thanks for opening this. |
/area blog |
Hello, Comms Shadow for the 1.27 release here. This feature blog is tracked for release, the deadline for submitting the draft is 4th of April- the sooner the better since there's still editing to be done afterward. Any doubt, the Comms team is here to help. Thanks! |
FYI: I'll start to write the blog next week. |
412d3c5
to
bd64321
Compare
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.
@@ -0,0 +1,43 @@ | |||
--- | |||
layout: blog | |||
title: "TBD" // TODO: have a cool title. |
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.
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.
How about "Introducing the advanced pod topology spread policy for Kubernetes"?
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.
or More fine-gained pod topology spread policies in Kubernetes scheduling
.
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 like the word "fine-grained".
Also, I'd like to mention that these features are coming to beta in v1.27 like many other blog posts did.
So... like Kubernetes 1.27: More fine-grained pod topology spread policies reached beta
?
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.
Kubernetes 1.27: More fine-grained pod topology spread policies reached beta
sgtm.
Hello @sanposhiho, we're doing a global reminder about submitting a draft for review for all opted-in feature blogs. If it's at all possible, it is very helpful for the release team to have drafts submitted for review before the hard deadline date, to better plan the release dates and avoid missing out. Thank you! |
My commit is 7656b49, I can't append directly, maybe I should be a co-author. |
Signed-off-by: Kante Yin <kerthcet@gmail.com>
@sanposhiho plz help to cherry-pick this commit. Thanks |
Signed-off-by: Alex Wang <wangqingcan1990@gmail.com>
ping @sanposhiho a new commit to address the comments about nodeInclusionPolicy. c01127b |
Signed-off-by: Kante Yin <kerthcet@gmail.com>
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.
LGTM from SIG Scheduling (technical PoV)
**Authors:** [Alex Wang](https://github.com/denkensk)(Shopee), [Kante Yin](https://github.com/kerthcet)(DaoCloud), [Kensei Nakada](https://github.com/sanposhiho)(Mercari) | ||
|
||
In Kubernetes v1.19, [Pod Topology Spread Constraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) went to GA. | ||
It is the feature to control how Pods are spread to each failure-domain (regions, zones, nodes etc). |
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 the feature to control how Pods are spread to each failure-domain (regions, zones, nodes etc). | |
It is the feature to control how Pods are spread in the cluster topology or failure domains (regions, zones, nodes etc). |
## KEP-3094: Take taints/tolerations into consideration when calculating PodTopologySpread skew | ||
|
||
Before this enhancement, when you deploy a pod with `podTopologySpread` configured, kube-scheduler would | ||
take all inclined nodes(satisfied with pod nodeAffinity and nodeSelector) into consideration |
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.
take all inclined nodes(satisfied with pod nodeAffinity and nodeSelector) into consideration | |
take the Nodes that satisfy the Pod's nodeAffinity and nodeSelector into consideration |
take all inclined nodes(satisfied with pod nodeAffinity and nodeSelector) into consideration | ||
in filtering and scoring, but would not care about whether the node taints are tolerated by the incoming pod or not. | ||
This may lead to a node with untolerated taint best fit the pod in podTopologySpread plugin, and as a result, | ||
the pod will stuck in pending for it violates the nodeTaint plugin. |
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.
the pod will stuck in pending for it violates the nodeTaint plugin. | |
the pod will stuck in Pending if it doesn't tolerate the taint. |
Before this enhancement, when you deploy a pod with `podTopologySpread` configured, kube-scheduler would | ||
take all inclined nodes(satisfied with pod nodeAffinity and nodeSelector) into consideration | ||
in filtering and scoring, but would not care about whether the node taints are tolerated by the incoming pod or not. | ||
This may lead to a node with untolerated taint best fit the pod in podTopologySpread plugin, and as a result, |
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.
This may lead to a node with untolerated taint best fit the pod in podTopologySpread plugin, and as a result, | |
This may lead to a node with untolerated taint as the only candidate for spreading, and as a result, |
revision label to Deployment and update it manually at each rolling upgrade (both the label on the | ||
podTemplate and the `labelSelector` in the `topologySpreadConstraints`). | ||
|
||
To solve this problem once and for all, and to make more accurate decisions in scheduling, we added a new named |
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.
To solve this problem once and for all, and to make more accurate decisions in scheduling, we added a new named | |
To solve this problem with a simpler API, we added a new field named |
existing pods over which spreading will be calculated for the incoming pod. | ||
|
||
With `matchLabelKeys`, you don't need to update the `pod.spec` between different revisions. | ||
The controller/operator just needs to set different values to the same label key for different revisions. |
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.
The controller/operator just needs to set different values to the same label key for different revisions. | |
The controller or operator managing rollouts just needs to set different values to the same label key for different revisions. |
@alculquicondor I fixed based on your suggestions. @kerthcet @denkensk I applied what @alculquicondor suggested as it is for now. Please create a commit if you have another idea for your section. |
Thanks @sanposhiho , LGTMed. |
OK Thanks LGTM @sanposhiho |
Hello, Comms Lead for v1.27 here. The publication order and date for the Feature Blog series has been finalized and the tracking board is updated. The publication date for this article is 17-04-2023 (April 17). Thank you! |
/assign @onlydole For approval from sig/docs side. |
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.
Hi. Here's some feedback based on how we usually write and style articles. I hope it helps.
I also suggested an update to use the official publication date.
--- | ||
layout: blog | ||
title: "Kubernetes 1.27: More fine-grained pod topology spread policies reached beta" | ||
date: 2023-04-11 |
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.
date: 2023-04-11 | |
date: 2023-04-17 |
Please update the filename to match.
title: "Kubernetes 1.27: More fine-grained pod topology spread policies reached beta" | ||
date: 2023-04-11 | ||
slug: fine-grained-pod-topology-spread-features-beta | ||
evergreen: true |
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.
Are you sure? This represents a commitment by the SIG to keep the content current. However, this doesn't feel like a post that would stay up to date as it is tied to a specific release.
evergreen: true |
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.
This represents a commitment by the SIG to keep the content current.
Ah, OK. I'll delete then.
But, there wasn't a way to control the number of domains over which we should spread. | ||
Some users want to force spreading Pods over a minimum number of domains, and if there aren't enough already present, make the cluster-autoscaler provision them. | ||
|
||
Then, we introduced the `minDomains` parameter in the Pod Topology Spread. |
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.
Then, we introduced the `minDomains` parameter in the Pod Topology Spread. | |
Kubernetes v1.24 introduced the `minDomains` parameter for pod topology spread constraints, | |
as an alpha feature. |
Via `minDomains` parameter, you can define the minimum number of domains. | ||
|
||
For example, assume there are 3 Nodes with the enough capacity, | ||
and a newly created replicaset has the following `topologySpreadConstraints` in template. |
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.
and a newly created replicaset has the following `topologySpreadConstraints` in template. | |
and a newly created ReplicaSet has the following `topologySpreadConstraints` in its Pod template. |
and a newly created replicaset has the following `topologySpreadConstraints` in template. | ||
|
||
```yaml | ||
topologySpreadConstraints: |
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.
topologySpreadConstraints: | |
... | |
topologySpreadConstraints: |
|
||
## Getting involved | ||
|
||
These features are managed by the [SIG/Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling). |
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.
These features are managed by the [SIG/Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling). | |
These features are managed by Kubernetes [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling). |
|
||
## How can I learn more? | ||
|
||
- [Pod Topology Spread Constraints | Kubernetes](/docs/concepts/scheduling-eviction/topology-spread-constraints/) |
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.
- [Pod Topology Spread Constraints | Kubernetes](/docs/concepts/scheduling-eviction/topology-spread-constraints/) | |
- [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) in the Kubernetes documentation |
|
||
**Authors:** [Alex Wang](https://github.com/denkensk)(Shopee), [Kante Yin](https://github.com/kerthcet)(DaoCloud), [Kensei Nakada](https://github.com/sanposhiho)(Mercari) | ||
|
||
In Kubernetes v1.19, [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) went to GA. |
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.
(nit)
In Kubernetes v1.19, [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) went to GA. | |
In Kubernetes v1.19, [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) | |
went to general availability (GA). |
In Kubernetes v1.19, [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) went to GA. | ||
It is the feature to control how Pods are spread in the cluster topology or failure domains (regions, zones, nodes etc). | ||
|
||
As time passed, we received feedback from users, |
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 time passed, we received feedback from users, | |
As time passed, we - SIG Scheduling - received feedback from users, |
```yaml | ||
topologySpreadConstraints: | ||
- maxSkew: 1 | ||
minDomains: 5 # requires 5 Nodes at least. |
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.
minDomains: 5 # requires 5 Nodes at least. | |
minDomains: 5 # requires 5 Nodes at least (because each Node has a unique hostname) |
@sanposhiho can you help to solve these comments? Or another two cherry-picks? |
I applied the changes to fix the points from @sftim |
/hold cancel |
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.
Thanks
/lgtm
/approve
LGTM label has been added. Git tree hash: 6b6be3cc3058d90117a5245fe819e4249a340e59
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
We added some features in recent releases and those are now graduated to beta by 1.27.
We'd like to have a blog post for all of these features.
/cc @kerthcet @denkensk