2

我有一个部署在 Kubernetes 上的应用程序。

这个应用程序有 4 个副本，我正在对每个部署进行滚动更新。

这个应用程序有一个优雅的关闭，可能需要几十分钟（它必须等待正在运行的任务完成）。

我的问题是，在更新期间，我的容量过剩，因为所有旧版本的 pod 在创建所有新 pod 时都停留在“Terminating”状态。

在更新期间，我最终运行了 8 个容器，这是我试图避免的事情。

我尝试设置maxSurge为 0，但此设置没有考虑“终止”pod，因此部署期间我的服务器上的负载太高。

我试图获得的行为是，只有在旧版本的 pod 成功完成后才会创建新的 pod，所以在任何时候我都不会超过我设置的副本数量。

我想知道是否有办法实现这种行为。

4

2 回答 2

1

我最终做的是创建一个StatefulSetwithpodManagementPolicy: Parallel和updateStrategyto OnDelete。

我还设置terminationGracePeriodSeconds了 pod 终止所需的最长时间。

作为部署过程的一部分，我将StatefulSet新镜像与新镜像一起应用，然后删除所有正在运行的 pod。

这样，所有 pod 都进入Terminating状态，每当 pod 完成其任务并终止具有新图像的新 pod 时，都会替换它。

这样我就可以在整个部署过程中保持静态数量的副本。

于 2020-05-17T11:50:56.340 回答
0

让我建议以下策略：

  1. 部署实现了就绪 pod 的概念以帮助滚动更新。就绪探测允许部署逐步更新 pod，同时让您控制确定滚动更新何时可以继续。

  2. Ready pod 是被 Deployment 视为成功更新的 pod，将不再计入部署的激增计数。如果 Pod的就绪性探测成功并且spec.minReadySeconds自 Pod 创建以来已通过，则认为 Pod 已准备就绪。这些选项的默认值将导致容器在其容器启动后立即准备就绪。

因此，您可以做的是（如果您还没有这样做的话）为您的 pod实施准备情况探测，此外还要将 设置spec.minReadySeconds为对您的 pod 所花费的时间有意义（最坏情况）的值终止。

这将确保逐步推出并与您的要求相协调。

除此之外，不要忘记为推出配置截止日期。默认情况下，rollout在 10 分钟内无法取得任何进展后，视为失败。部署失败的时间可以通过progressDeadlineSeconds部署规范中的属性进行配置。

于 2020-05-12T10:32:43.493 回答