k8s 监听节点宕机的时间设置
环境： 1个master , 2个node,
操作：master 通过 "kubectl sacle --replicas=10 deployment/mynginx-dep" 命令创建了10pod。我将其中一个node节点关机， master 过了很久很久才在另外一个node中创建新的pod（感觉差不多有67分钟）。 我想问下， 如何设置master发现node节点宕机，然后重新再另外一个node上拉起 pod 的时间？（不是配置原因， 三台都是4核8G的）。
不知道我有没有描述清楚，我觉得67分钟太久了， 想设置短一些，因为再学习测试， 等待的时间太久了。有没有清楚的， 麻烦告知一下， 谢谢。
我觉得可能不是配置的问题，可能是node节点数目或者node服务器本身资源的问题。
一般按照官方的说法，
最基本的k8s集群需要三台服务器，1个master 2个node
如果你一个node宕机了，另外只剩下一个master或者node可能达不到k8s的默认配置要求，所以导致会有点慢。
你可以这样操作试下：
1、再加一个node节点，这样就有1master+3node
2、宕机其中一个node节点，查看其中的被关闭的node节点上的pod数目,在其他的node节点上创建出来大概有多长时间，理论上基本都是几分钟就可以了。
我在之前的一个集群环境中(大概6个node节点)测试过这种情况，一个node宕机，其他的pod资源自动在其他的node上创建。
另外，你需要先确保正常环境下一个pod重新创建拉取需要多长时间,
（比如网络问题：镜像的拉取和其他配置），确保正常大概是多长时间，这样做个对比比较。
如果你的deployment比较耗资源，可以用简单的nginx或者busybox来测试,
至于Node宕机时间的设置
默认一般是300s，如果想更短，
可以自行设置，
这个现象与 Kubelet 的状态更新机制密切相关，下面我们来分析下 Kubelet 状态更新的基本流程。
- 1、kubelet
kubelet 自身会定期更新状态到 apiserver，通过参数 --node-status-update-frequency 配置上报频率，默认 10s 上报一次。
- 2、kube-controller-manager
kube-controller-manager 会定时去检查 kubelet 的状态，可通过 --node-monitor-period 自定义这个时间 ，默认是 5s。
当 node 失联一段时间后，kubernetes 判定 node 为 notready 状态，这段时长可通过 --node-monitor-grace-period 参数配置，默认 40s。
当 node 状态为 notready 一段时间后，kubernetes 判定 node 为 unhealthy 状态，这段时长可通过 --node-startup-grace-period 参数配置，默认 1m0s。
当 node 状态为 unhealthy 一段时间后，kubernetes 开始删除原 node 上的 Pod，这段时长可通过 --pod-eviction-timeout 参数配置，默认 5m0s。
通过配置如下几个属性，默认情况是6分钟。不清楚的可以再问我额，如有帮助，请采纳！
node-monitor-period
节点控制器(node controller) 检查每个节点的间隔，默认5秒。
node-monitor-grace-period
节点控制器判断节点故障的时间窗口, 默认40秒。即40 秒没有收到节点消息则判断节点为故障。
pod-eviction-timeout
当节点故障时，kubelet允许pod在此故障节点的保留时间，默认300秒。即当节点故障5分钟后，kubelet开始在其他可用节点重建pod。