Merge pull request #27143 from allcentury/patch-1
update assign-pod doc
This commit is contained in:
commit
279bf48616
|
@ -11,18 +11,17 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
|
||||
{{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes.
|
||||
There are several ways to do this, and the recommended approaches all use
|
||||
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
|
||||
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
|
||||
{{< glossary_tooltip text="Node(s)" term_id="node" >}}.
|
||||
There are several ways to do this and the recommended approaches all use
|
||||
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
|
||||
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
|
||||
(e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
|
||||
but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
|
||||
(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
|
||||
but there are some circumstances where you may want to control which node the pod deploys to - for example to ensure
|
||||
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
|
||||
services that communicate a lot into the same availability zone.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## nodeSelector
|
||||
|
|
Loading…
Reference in New Issue