feat: GA feature gate DefaultPodTopologySpread

Signed-off-by: kerthcet <kerthcet@gmail.com>
This commit is contained in:
kerthcet
2022-03-03 23:53:29 +08:00
parent 0aa00b6902
commit c5428ebad7
@@ -4,21 +4,11 @@ content_type: concept
weight: 40
---
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
<!-- leave this shortcode in place until the note about EvenPodsSpread is
obsolete -->
<!-- overview -->
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
{{< note >}}
In versions of Kubernetes before v1.18, you must enable the `EvenPodsSpread`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on
the [API server](/docs/concepts/overview/components/#kube-apiserver) and the
[scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) in order to use Pod
topology spread constraints.
{{< /note >}}
<!-- body -->
@@ -319,21 +309,17 @@ profiles:
```
{{< note >}}
The score produced by default scheduling constraints might conflict with the
score produced by the
[`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins).
It is recommended that you disable this plugin in the scheduling profile when
using default constraints for `PodTopologySpread`.
[`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
is disabled by default. It's recommended to use `PodTopologySpread` to achieve similar
behavior.
{{< /note >}}
#### Internal default constraints
#### Built-in default constraints {#internal-default-constraints}
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
With the `DefaultPodTopologySpread` feature gate, enabled by default, the
legacy `SelectorSpread` plugin is disabled.
kube-scheduler uses the following default topology constraints for the
`PodTopologySpread` plugin configuration:
If you don't configure any cluster-level default constraints for pod topology spreading,
then kube-scheduler acts as if you specified the following default topology constraints:
```yaml
defaultConstraints:
@@ -346,7 +332,7 @@ defaultConstraints:
```
Also, the legacy `SelectorSpread` plugin, which provides an equivalent behavior,
is disabled.
is disabled by default.
{{< note >}}
If your nodes are not expected to have **both** `kubernetes.io/hostname` and