Move Pod Topology Spread Constraints into scheduling
These constraints apply specifically to the mechanism for placing Pods onto nodes (that is, scheduling).pull/33792/head
parent
bde5fe9e2a
commit
6700656cb4
|
|
@ -67,7 +67,7 @@ Let's see an example of a cluster to understand this API.
|
|||
As the feature name "PodTopologySpread" implies, the basic usage of this feature
|
||||
is to run your workload with an absolute even manner (maxSkew=1), or relatively
|
||||
even manner (maxSkew>=2). See the [official
|
||||
document](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
document](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
for more details.
|
||||
|
||||
In addition to this basic usage, there are some advanced usage examples that
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ To correct the latter issue, we now employ a "hunt and peck" approach to removin
|
|||
### 1. Upgrade to kubernetes 1.18 and make use of Pod Topology Spread Constraints
|
||||
|
||||
While this seems like it could have been the perfect solution, at the time of writing Kubernetes 1.18 was unavailable on the two most common managed Kubernetes services in public cloud, EKS and GKE.
|
||||
Furthermore, [pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) were still a [beta feature in 1.18](https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
|
||||
Furthermore, [pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) were still a beta feature in 1.18 which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
|
||||
The entire endeavour was concerningly reminiscent of checking [caniuse.com](https://caniuse.com/) when Internet Explorer 8 was still around.
|
||||
|
||||
### 2. Deploy a statefulset _per zone_.
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ of terminating one or more Pods on Nodes.
|
|||
* [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
|
||||
* [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
* [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
* [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)
|
||||
* [Scheduling Framework](/docs/concepts/scheduling-eviction/scheduling-framework)
|
||||
* [Scheduler Performance Tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ of the scheduler:
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
|
||||
* Read the [kube-scheduler config (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
|
||||
* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
|
||||
|
|
|
|||
|
|
@ -320,12 +320,12 @@ in the Pod Lifecycle documentation.
|
|||
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||
* Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
|
||||
configure different Pods with different container runtime configurations.
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
|
||||
* Pod is a top-level resource in the Kubernetes REST API.
|
||||
The {{< api-reference page="workload-resources/pod-v1" >}}
|
||||
object definition describes the object in detail.
|
||||
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
|
||||
* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
|
||||
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:
|
||||
|
||||
|
|
|
|||
|
|
@ -438,7 +438,7 @@ Note that the live editor doesn't recognize Hugo shortcodes.
|
|||
### Example 1 - Pod topology spread constraints
|
||||
|
||||
Figure 6 shows the diagram appearing in the
|
||||
[Pod topology pread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels)
|
||||
[Pod topology pread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/#node-labels)
|
||||
page.
|
||||
|
||||
{{< mermaid >}}
|
||||
|
|
|
|||
|
|
@ -808,7 +808,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
availability during update per node.
|
||||
See [Perform a Rolling Update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
|
||||
- `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
|
||||
[default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
|
||||
[default spreading](/docs/concepts/scheduling-eviction/topology-spread-constraints/#internal-default-constraints).
|
||||
- `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the
|
||||
role of applying `fsGroup` from a Pod's `securityContext` to the driver by
|
||||
passing `fsGroup` through the NodeStageVolume and NodePublishVolume CSI calls.
|
||||
|
|
@ -854,7 +854,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
{{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}
|
||||
to running pods.
|
||||
- `EvenPodsSpread`: Enable pods to be scheduled evenly across topology domains. See
|
||||
[Pod Topology Spread Constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
[Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
|
||||
- `ExecProbeTimeout`: Ensure kubelet respects exec probe timeouts.
|
||||
This feature gate exists in case any of your existing workloads depend on a
|
||||
now-corrected fault where Kubernetes ignored exec probe timeouts. See
|
||||
|
|
@ -995,7 +995,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
|||
- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using
|
||||
cgroup v2 memory controller.
|
||||
- `MinDomainsInPodTopologySpread`: Enable `minDomains` in Pod
|
||||
[topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
[topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
|
||||
- `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type
|
||||
Service instance.
|
||||
- `MountContainers`: Enable using utility containers on host as the volume mounter.
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ extension points:
|
|||
and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
|
||||
Extension points: `filter`, `score`.
|
||||
- `PodTopologySpread`: Implements
|
||||
[Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
[Pod topology spread](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
|
||||
Extension points: `preFilter`, `filter`, `preScore`, `score`.
|
||||
- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
|
||||
true.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ These labels can include
|
|||
|
||||
If your cluster spans multiple zones or regions, you can use node labels
|
||||
in conjunction with
|
||||
[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
|
||||
[Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
|
||||
to control how Pods are spread across your cluster among fault domains:
|
||||
regions, zones, and even specific nodes.
|
||||
These hints enable the
|
||||
|
|
|
|||
|
|
@ -158,6 +158,7 @@
|
|||
/docs/concepts/workloads/controllers/statefulset.md /docs/concepts/workloads/controllers/statefulset/ 301!
|
||||
/docs/concepts/workloads/pods/pod/ /docs/concepts/workloads/pods/ 301
|
||||
/docs/concepts/workloads/pods/pod-overview/ /docs/concepts/workloads/pods/ 301
|
||||
/docs/concepts/workloads/pods/pod-topology-spread-constraints/ /docs/concepts/scheduling-eviction/topology-spread-constraints/ 301
|
||||
/docs/concepts/workloads/pods/init-containers/Kubernetes/ /docs/concepts/workloads/pods/init-containers/ 301
|
||||
|
||||
/docs/concepts/policy/pod-security-policy/ /docs/concepts/security/pod-security-policy/ 301
|
||||
|
|
|
|||
Loading…
Reference in New Issue