You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 5, 2017. It is now read-only.
why is the default kubelet executor's suicide timeout so large (20 minutes) ? kubelet executor seem to commit suicide after some period of "inactivity":
no running tasks
no task launch requests in the last X minutes
what we are seeing is, after an executor is asked to kill pod tasks, it kills them and enters into suicide timeout timer wait. meanwhile, the kube node controller sees the pods running on that slave node as healthy, as the kubelet seems to still report node status during this timer wait interval. Eventually, when the executor exits, node controller's pod evictor eventually kicks in (again after a default podEvictionTimeout of 5 mins!) and deletes the pod assignments to that slave node, after which Replication controller kicks in, recreates the pod and k8sm scheduler schedules the pod task.
Can you please validate the above analysis. Are there any downsides to running with lower executor timeout ?
we are planning to run with a executor-suicide-timeout of 2 mins and implicit reconcile-interval down to 60secs.
The text was updated successfully, but these errors were encountered:
ravilr
changed the title
the reason behind 20 minute kubelet executor suicide timeout default ?
the reason behind 20 minutes kubelet executor suicide timeout default ?
Aug 30, 2015
@jdef
Observed in kubernetes v1.0.3 release.
why is the default kubelet executor's suicide timeout so large (20 minutes) ? kubelet executor seem to commit suicide after some period of "inactivity":
what we are seeing is, after an executor is asked to kill pod tasks, it kills them and enters into suicide timeout timer wait. meanwhile, the kube node controller sees the pods running on that slave node as healthy, as the kubelet seems to still report node status during this timer wait interval. Eventually, when the executor exits, node controller's pod evictor eventually kicks in (again after a default podEvictionTimeout of 5 mins!) and deletes the pod assignments to that slave node, after which Replication controller kicks in, recreates the pod and k8sm scheduler schedules the pod task.
Can you please validate the above analysis. Are there any downsides to running with lower executor timeout ?
we are planning to run with a executor-suicide-timeout of 2 mins and implicit reconcile-interval down to 60secs.
The text was updated successfully, but these errors were encountered: