Cross link documentation for creating dedicated nodes with special hardware and ExtendedResourceToleration admission controller. (#8015)

This commit is contained in:
Rohit Agarwal 2018-04-10 02:27:09 +05:30 committed by k8s-ci-robot
parent 8397658688
commit e66b034afd
2 changed files with 14 additions and 10 deletions

View File

@ -188,7 +188,8 @@ for more details.
This plug-in facilitates creation of dedicated nodes with extended resources. This plug-in facilitates creation of dedicated nodes with extended resources.
If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to
taint the node with the extended resource name as the key. This admission controller, if enabled, automatically [taint the node](/docs/concepts/configuration/taint-and-toleration/#example-use-cases) with the extended resource
name as the key. This admission controller, if enabled, automatically
adds tolerations for such taints to pods requesting extended resources, so users don't have to manually adds tolerations for such taints to pods requesting extended resources, so users don't have to manually
add these tolerations. add these tolerations.

View File

@ -171,15 +171,18 @@ hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or
toleration to pods that use the special hardware. As in the dedicated nodes use case, toleration to pods that use the special hardware. As in the dedicated nodes use case,
it is probably easiest to apply the tolerations using a custom it is probably easiest to apply the tolerations using a custom
[admission controller](/docs/admin/admission-controllers/)). [admission controller](/docs/admin/admission-controllers/)).
For example, the admission controller could use For example, it is recommended to use [Extended
some characteristic(s) of the pod to determine that the pod should be allowed to use Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)
the special nodes and hence the admission controller should add the toleration. to represent the special hardware, taint your special hardware nodes with the
To ensure that the pods that need extended resource name and run the
the special hardware *only* schedule onto the nodes that have the special hardware, you will need some [ExtendedResourceToleration](/docs/admin/admission-controllers/#extendedresourcetoleration)
additional mechanism, e.g. you could represent the special resource using admission controller. Now, because the nodes are tainted, no pods without the
[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) toleration will schedule on them. But when you submit a pod that requests the
and request it as a resource in the PodSpec, or you could label the nodes that have extended resource, the `ExtendedResourceToleration` admission controller will
the special hardware and use node affinity on the pods that need the hardware. automatically add the correct toleration to the pod and that pod will schedule
on the special hardware nodes. This will make sure that these special hardware
nodes are dedicated for pods requesting such hardware and you don't have to
manually add tolerations to your pods.
* **Taint based Evictions (alpha feature)**: A per-pod-configurable eviction behavior * **Taint based Evictions (alpha feature)**: A per-pod-configurable eviction behavior
when there are node problems, which is described in the next section. when there are node problems, which is described in the next section.