我们有一个带有主节点 (foo-1) 和两个工作节点（foo-2 和 foo-3）的集群。我们有一个在 foo-3 上运行的 pod（由 Kubernetes 决定）。我们特意关闭 foo-3 作为实验。
我的期望是 Kubernetes 会“看到”关闭，并自动重新启动 foo-2 中的 pod。但是，这似乎并没有发生。事实上，它似乎认为 pod 仍在 foo-3 上运行。
经过五分钟的等待，Kubernetes 终于认识到集群节点已经消失，并通过重新启动 foo-2 上的 pod 来优雅地做出响应。五分钟对我们来说太长了，因为这不是一个复制的应用程序。我们怎样才能使超时时间大大缩短（例如 10 秒）？实际上，如果主机正常关闭（例如打补丁），效果应该是立竿见影的。
有一个--pod-eviction-timeout参数输入kube 控制器管理器 https://kubernetes.io/docs/admin/kube-controller-manager/默认为 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 进行部署，即使一个节点出现故障，服务也会正常运行。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
