我们有一个包含一个主节点（foo-1）和两个工作节点（foo-2 和 foo-3）的集群。我们有一个在 foo-3 上运行的 pod（由 Kubernetes 决定）。我们故意关闭 foo-3 作为实验。
我的期望是 Kubernetes 会“看到”关闭，并自动重启 foo-2 中的 pod。但是，这似乎并没有发生。实际上，它似乎认为 pod 仍在 foo-3 上运行。
经过五分钟的等待，Kubernetes 终于意识到集群节点已经消失，并优雅地响应，重启了 foo-2 上的 pod。五分钟对我们来说太长了，因为这不是一个复制的应用程序。我们怎样才能使超时时间大大缩短（比如 10 秒）？实际上，如果主机有正常关闭（如修补），效果应该是立竿见影的。
【问题讨论】：
标签： kubernetes
kube-controller-manager中有一个--pod-eviction-timeout参数，默认为5m：
--pod-eviction-timeout duration The grace period for deleting pods on failed nodes. (default 5m0s)
如果你想加快驱逐过程，你需要修改它。
但是如果你想尽量减少你的 pod 的宕机时间，当节点宕机时，你还需要修改以下参数：
kubelet: node-status-update-frequency=4s (default 10s)
kube-controller-manager: node-monitor-period=2s (default 5s)
kube-controller-manager: node-monitor-grace-period=16s (default 40s)
kube-controller-manager: pod-eviction-timeout=30s (default 5m)
当然，您始终可以使用副本 2 进行部署，即使一个节点出现故障，服务也会启动。
【讨论】：
kubelet 和 kube-controller-manager 配置文件应该被修改。它们的位置取决于您使用的操作系统和部署工具。