Merge master into dev-1.22 to keep in sync
This commit is contained in:
@@ -80,12 +80,14 @@ Here are some ways to mitigate involuntary disruptions:
|
||||
[multi-zone cluster](/docs/setup/multiple-zones).)
|
||||
|
||||
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
|
||||
no voluntary disruptions at all. However, your cluster administrator or hosting provider
|
||||
no automated voluntary disruptions (only user-triggered ones). However, your cluster administrator or hosting provider
|
||||
may run some additional services which cause voluntary disruptions. For example,
|
||||
rolling out node software updates can cause voluntary disruptions. Also, some implementations
|
||||
of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes.
|
||||
Your cluster administrator or hosting provider should have documented what level of voluntary
|
||||
disruptions, if any, to expect.
|
||||
disruptions, if any, to expect. Certain configuration options, such as
|
||||
[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
|
||||
in your pod spec can also cause voluntary (and involuntary) disruptions.
|
||||
|
||||
|
||||
## Pod disruption budgets
|
||||
|
||||
@@ -246,7 +246,7 @@ myapp-pod 1/1 Running 0 9m
|
||||
```
|
||||
|
||||
This simple example should provide some inspiration for you to create your own
|
||||
init containers. [What's next](#whats-next) contains a link to a more detailed example.
|
||||
init containers. [What's next](#what-s-next) contains a link to a more detailed example.
|
||||
|
||||
## Detailed behavior
|
||||
|
||||
@@ -326,7 +326,6 @@ Kubernetes, consult the documentation for the version you are using.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
|
||||
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ obsolete -->
|
||||
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.19, you must enable the `EvenPodsSpread`
|
||||
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/generated/kube-scheduler/) in order to use Pod
|
||||
|
||||
Reference in New Issue
Block a user