whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update cluster-management.md

Browse Source
This commit is contained in:
Sam Ghods
2016-05-26 14:31:15 -07:00
parent 3f32f6b1a0
commit 72e958b394
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/admin/cluster-management.md
+1 -1
View File
@@ -102,7 +102,7 @@ that you have Google Cloud Monitoring API enabled in Google Developer Console.
If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is
brief, then when the Kubelet restarts, it will attempt to restart the pods scheduled to it. If the reboot takes longer brief, then when the Kubelet restarts, it will attempt to restart the pods scheduled to it. If the reboot takes longer
(5 minutes is the default timeout, controlled by `--pod-eviction-timeout` on the controller-manager), (the default time is 5 minutes, controlled by `--pod-eviction-timeout` on the controller-manager),
then the node controller will terminate the pods that are bound to the unavailable node. If there is a corresponding then the node controller will terminate the pods that are bound to the unavailable node. If there is a corresponding
replica set (or replication controller), then a new copy of the pod will be started on a different node. So, in the case where all replica set (or replication controller), then a new copy of the pod will be started on a different node. So, in the case where all
pods are replicated, upgrades can be done without special coordination, assuming that not all nodes will go down at the same time. pods are replicated, upgrades can be done without special coordination, assuming that not all nodes will go down at the same time.