1

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

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

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

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

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

4

1 回答 1

0

正如@coderanger所说，你的限制是不正确的，这应该被修复，而不是降低Kubernetes 的自我修复能力。

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

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

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

    至于节点，有一篇关于提高 Kubernetes 可靠性的非常好的博客文章：更快地检测节点故障，这与您的想法相反，但它也提到了为什么 340s 太多了

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

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

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

  • kubelet： 节点状态更新频率=10s
  • 控制器管理器： 节点监控周期=5s
  • 控制器管理器： 节点监视器宽限期 = 40 秒
  • 控制器管理器： pod-eviction-timeout=5m

对更高的。

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

于 2020-04-01T14:33:19.533 回答