whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

mv "Assign Pods" and "Taints and Tolerations" concepts to "Scheduling and Eviction"

Browse Source 
* Moved "Assigning Pods to Nodes" article to Concepts -> Scheduling and Eviction
* Moved "Taints and Tolerations" article to Concepts -> Scheduling and Eviction
* Updated weight of the "Kubernetes Scheduler" article so it appears first
* Updated redirects
* Replaced links to "Assigning Pods to Nodes" and "Taints and Tolerations" articles
to avoid redirects.

Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
This commit is contained in:
Adam Kaplan
2020-04-21 17:13:47 -04:00
parent 4d5ddc5586
commit 55e17b86f2
23 changed files with 35 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md
+1 -1
View File
@@ -144,7 +144,7 @@ The local persistent volume beta feature is not complete by far. Some notable en
[Pod disruption budget](/docs/concepts/workloads/pods/disruptions/) is also very important for those workloads that must maintain quorum. Setting a disruption budget for your workload ensures that it does not drop below quorum due to voluntary disruption events, such as node drains during upgrade.
[Pod affinity and anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node.
[Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node.
## Getting involved