github
/
k3s
mirror of https://github.com/k3s-io/k3s
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fix some wording in cluster management doc.

pull/6/head
David Oppenheimer 2015-04-16 22:31:19 -07:00
parent 6d8a25ff56
commit bae12d6369
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/cluster_management.md
View File

@ -46,11 +46,11 @@ If you want more control over the upgrading process, you may use the following w
This keeps new pods from landing on the node while you are trying to get them off.
1. Get the pods off the machine, via any of the following strategies:
1. wait for finite-duration pods to complete
1. for pods with a replication controller, delete the pod with `kubectl delete pods $PODNAME`
1. for pods which are not replicated, bring up a new copy of the pod, and redirect clients to it.
1. delete pods with `kubectl delete pods $PODNAME`
l. for pods with a replication controller, the pod will eventually be rescheduled to a new node. additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
l. for pods with no replication controller, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
1. Work on the node
1. Make the node schedulable again:
`kubectl update nodes $NODENAME --patch='{"apiVersion": "v1beta1", "unschedulable": false}'`.
Or, if you deleted the VM instance and created a new one, and are using `--sync_nodes=true` on the apiserver
(the default), then a new schedulable node resource will be created automatically when you create a new
VM instance. See [Node](node.md).
If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
be created automatically when you create a new VM instance. See [Node](node.md).