Kubernetes 部署滚动更新答案

【问题标题】：Kubernetes Deployment Rolling UpdatesKubernetes 部署滚动更新
【发布时间】：2020-08-27 10:51:50
【问题描述】：

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

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

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

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

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

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

我想要得到的行为是，只有在旧版本的 pod 成功完成后才会创建新的 pod，所以我始终没有超过我设置的副本数。

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

【问题讨论】：

使用maxSurge，您是在向 kubernetes 说，您允许多少个 pod 居住在所需数量的范围内。您是否尝试将 maxUnavailable 设置为 1 ？这是在更新过程中可能不可用的 pod 数量。
这不会削减它，因为每次部署都需要几个小时，因为它会一个一个地替换 Pod。

【解决方案1】：

我最终做的是创建一个StatefulSet 与podManagementPolicy: Parallel 和updateStrategy 到OnDelete。

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

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

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

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

【讨论】：

【解决方案2】：

让我建议以下策略：

部署实现就绪 pod 的概念以帮助滚动更新。 就绪探测允许部署逐步更新 pod，同时让您控制确定何时可以继续滚动更新。
Ready pod 是被部署视为成功更新的 pod，将不再计入部署的激增计数。 如果 Pod 的就绪性探测成功并且 spec.minReadySeconds 在 Pod 创建后已经过去，则认为 Pod 已准备就绪。这些选项的默认值将导致 Pod 在其容器启动后立即准备就绪。

所以，你可以做的是为你的 pod 实现（如果你还没有这样做的话）readiness probe除了将spec.minReadySeconds 设置为一个值感知（最坏情况）您的 pod 终止所需的时间。

这将确保逐步推出并根据您的要求进行。

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

【讨论】：

将 minReadySeconds 设置为一个小时会导致我的部署太慢，因为所有 pod 可能需要几个小时才能准备好。
我不确定您所说的“会导致我的部署太慢”是什么意思。推出过程会很慢，而且您不会有任何停机时间。 请注意，这是您在问题中要求的内容：“只有在旧版本的 pod 成功完成后才会创建 pod”。请澄清。
我还有一个要求就是始终不超过副本数。