Merge branches 'release-1.6' and 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.6
* 'release-1.6' of https://github.com/kubernetes/kubernetes.github.io: * 'master' of https://github.com/kubernetes/kubernetes.github.io: (23 commits) Apply changes from PR #2787 rephrase the sentence to make expression clear (#2789) update index.md (#2788) Apply changes from PR #2784 (#2950) The link URL of [kube-controller-manager] is wrong Added pod name in run command Fix grammar in docs/admin/daemon.md update index.md (#2755) Update garbage-collection.md (#2732) Fix typo (#2842) Fix typo Fix the typos Apply typo fixes from #2791 (#2949) Fix typo in kubectl_completion.md fix typeo (#2856) Use kubectl config current-context to simplify the instructions fix a typo in /docs/user-guide/configmap/index.md Fix monitor-node-health.md amend monitor-node-health.md Update manage-compute-resources-container.md ... # Conflicts: # docs/tools/index.md
This commit is contained in:
@@ -11,7 +11,7 @@ run on particular nodes. There are several ways to do this, and they all use
|
||||
[label selectors](/docs/user-guide/labels/) to make 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 where a pod lands, e.g. to ensure
|
||||
but there are some circumstances where you may want more control on a node where a pod lands, e.g. 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.
|
||||
|
||||
@@ -36,9 +36,7 @@ This example assumes that you have a basic understanding of Kubernetes pods and
|
||||
|
||||
### Step One: Attach label to the node
|
||||
|
||||
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to.
|
||||
|
||||
Then, to add a label to the node you've chosen, run `kubectl label nodes <node-name> <label-key>=<label-value>`. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
|
||||
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to, and then run `kubectl label nodes <node-name> <label-key>=<label-value>` to add a label to the node you've chosen. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
|
||||
|
||||
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user