Cross link documentation for creating dedicated nodes with special hardware and ExtendedResourceToleration admission controller. (#8015)
This commit is contained in:
parent
8397658688
commit
e66b034afd
|
@ -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.
|
||||||
|
|
||||||
|
|
|
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue