我们可以有 --pod-eviction-timeout=300m 吗？

Question

我有一个 k8s 集群，在我们的集群中，我们不希望 pod 被驱逐，因为 pod 驱逐会对运行在其上的应用程序造成很多副作用。

为了防止 pod 驱逐发生，我们已将所有 pod 配置为 Guaranteed QoS。我知道即使这样，如果系统中存在任何资源匮乏，也会发生 pod 驱逐。当 pod 和节点内出现资源不足时，我们有监视器来提醒我们。所以我们在一个 pod 被驱逐之前就知道了。这有助于我们在 pod 被驱逐之前采取措施。

发生 pod eviction 的其他原因是如果节点处于 not-ready 状态，那么 kube-controller-manager 将检查 pod-eviction-timeout 并在此超时后驱逐 pod。当节点进入未就绪状态时，我们有监视器来提醒我们。现在在此警报之后，我们想采取一些措施从应用程序端进行清理，因此应用程序将优雅地结束。要进行此清理，我们需要几个小时以上，但 pod-eviction-timeout 默认为 5 分钟。

将 pod eviction timeout 增加到 300m 可以吗？将此超时增加到这样的限制有什么影响？

P.S：我知道在这段等待时间内，如果 pod 使用了更多的资源，那么 kubelet 可以自己驱逐这个 pod。我想知道等这么久还有什么影响？

Answer 1

正如@coderanger 所说，您的限制不正确，应该修复此问题，而不是降低 Kubernetes 的self-healing 功能。

如果您的pod 死了，不管它有什么问题，默认情况下它会根据您的配置重新安排。 如果您对此有疑问，那么我建议您重做架构并重写应用程序以使用 Kubernetes 应该如何使用它。

• 如果您在 pod 无响应时仍然发送请求时遇到问题，您应该在前面实现 LB 或将请求排队，
• 如果您在pod 重新启动后遇到 IP 更改问题，应使用 DNS 和 service 解决此问题，而不是直接连接到 Pod，

• 如果您的 pod 被驱逐，请检查原因，提出限制和要求，

  关于节点，有一篇关于Improving Kubernetes reliability: quicker detection of a Node down 的非常好的博客文章，它与您的想法相反，但它也提到了为什么 340 太多了

  一旦节点被标记为不健康，kube 控制器管理器将根据 –pod-eviction-timeout=5m0s

  删除其 pod

  这是一个非常重要的超时时间，默认为 5m，我认为这太高了，因为尽管节点已经被标记为不健康，但 kube 控制器管理器不会删除 pod，因此它们可以通过他们的服务访问，并且请求将失败。

如果您仍想将默认值更改为更高的值，您可以考虑更改这些：

• kubelet： node-status-update-frequency=10s
• controller-manager： node-monitor-period=5s
• controller-manager： node-monitor-grace-period=40s
• controller-manager： pod-eviction-timeout=5m

到更高的。

如果您提供更多详细信息，我会尽力提供更多帮助。