From e66b034afdc9af43aebd53d84d986aa0855fc08b Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Tue, 10 Apr 2018 02:27:09 +0530 Subject: [PATCH] Cross link documentation for creating dedicated nodes with special hardware and ExtendedResourceToleration admission controller. (#8015) --- docs/admin/admission-controllers.md | 3 ++- .../configuration/taint-and-toleration.md | 21 +++++++++++-------- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 9d12a220f6..a1415f98b7 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -188,7 +188,8 @@ for more details. 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 -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 add these tolerations. diff --git a/docs/concepts/configuration/taint-and-toleration.md b/docs/concepts/configuration/taint-and-toleration.md index a653a6f8ce..bce94366e4 100644 --- a/docs/concepts/configuration/taint-and-toleration.md +++ b/docs/concepts/configuration/taint-and-toleration.md @@ -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, it is probably easiest to apply the tolerations using a custom [admission controller](/docs/admin/admission-controllers/)). -For example, the admission controller could use -some characteristic(s) of the pod to determine that the pod should be allowed to use -the special nodes and hence the admission controller should add the toleration. -To ensure that the pods that need -the special hardware *only* schedule onto the nodes that have the special hardware, you will need some -additional mechanism, e.g. you could represent the special resource using -[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) -and request it as a resource in the PodSpec, or you could label the nodes that have -the special hardware and use node affinity on the pods that need the hardware. +For example, it is recommended to use [Extended +Resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +to represent the special hardware, taint your special hardware nodes with the +extended resource name and run the +[ExtendedResourceToleration](/docs/admin/admission-controllers/#extendedresourcetoleration) +admission controller. Now, because the nodes are tainted, no pods without the +toleration will schedule on them. But when you submit a pod that requests the +extended resource, the `ExtendedResourceToleration` admission controller will +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 when there are node problems, which is described in the next section.