我有一个k8s集群，在我们的集群中，我们不希望将Pod逐出，因为Pod逐出会对运行在其上的应用程序产生很多副作用。
为了防止容器逐出，我们将所有容器都配置为保证的QoS。我知道即使系统中有任何资源匮乏，也可能发生荚驱逐。当容器和节点中有资源不足时，我们会有监视器来提醒我们。因此，我们在 pods 被逐出之前就已经了解了。这有助于我们在 pods 驱逐之前采取措施。
移出容器的另一个原因是，如果节点处于未就绪状态，则kube-controller-manager将检查容器移出超时，并在此超时后将容器逐出。当节点进入未就绪状态时，我们有监视器来提醒我们。现在，在收到此警报后，我们希望采取一些措施从应用程序端进行清理，以便应用程序正常运行。要进行此清理，我们需要几个小时以上的时间，但默认情况下，pod-eviction-timeout为5分钟。
将 pods 逐出超时时间增加到300m是否可以？将超时时间增加到这样的限制有什么影响？
附注:我知道在这段等待时间内，如果 pods 使用了更多资源，那么kubelet可以自行驱逐该 pods 。我想知道等待这么长时间的其他影响吗？
最佳答案
正如@coderanger所说，您的限制是不正确的，应该固定此限制，而不是降低Kubernetes的self-healing功能。
如果pod死了，不管它是什么问题，默认情况下都会根据您的配置重新安排它的时间。
如果您对此有疑问，那么我建议您重做您的架构并重写该应用程序以使用Kubernetes应该如何使用它。
pod仍在发送请求时遇到问题，则应在前面实施LB或将请求排队pod后更改IP时遇到问题，则应使用DNS和service来解决此问题，而不是直接连接到pod pod被驱逐，请检查原因，提出限制和要求，至于节点，有一个关于Improving Kubernetes reliability: quicker detection of a Node down的非常不错的博客文章，它与您正在考虑的做法相反，但同时也提到了为什么340太多了
Once the node is marked as unhealthy, the kube controller manager will remove its pods based on –pod-eviction-timeout=5m0s
This is a very important timeout, by default it’s 5m which in my opinion is too high, because although the node is already marked as unhealthy the kube controller manager won’t remove the pods so they will be accessible through their service and requests will fail.
如果您仍想将默认值更改为更高的值，可以考虑更改这些值:
到更高的。
如果您提供更多详细信息，我会尽力提供帮助。
关于kubernetes - 我们可以--pod-eviction-timeout = 300m吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60965752/