正在进行的升级（反之亦然）如何影响服务的计划（滚动）重启答案

【问题标题】：How will a scheduled (rolling) restart of a service be affected by an ongoing upgrade (and vice versa)正在进行的升级（反之亦然）如何影响服务的计划（滚动）重启
【发布时间】：2020-07-01 02:23:09
【问题描述】：

由于我们的一项服务中存在内存泄漏，我计划添加一个 k8s CronJob 来安排定期重启泄漏服务。目前我们没有资源来正确调查内存泄漏，因此我们需要一个临时解决方案来快速减少由泄漏引起的问题。这将是滚动重启，如下所述：

How to schedule pods restart

我已经在我们的测试集群中对此进行了测试，它似乎可以按预期工作。该服务有 2 个副本处于测试阶段，3 个处于生产阶段。

我的计划是安排 CronJob 每 2 小时运行一次。

我现在想知道：如果新的 CronJob 碰巧在服务升级已经运行时执行，它将如何表现？我们进行滚动升级以实现零停机时间，有时我们一天会推出多次升级。我不想通过说“请确保您永远不要在 08:00、10:00、12:00 等附近部署”来限制部署升级的人。从长远来看，这永远不会奏效。

反之亦然，我也想知道如果在 CronJob 已经在运行并且 Pod 正在重新启动时开始升级会发生什么。

kubernetes 有内置的东西来处理这种冲突吗？

【问题讨论】：

如果 Pod 上有 resources: 声明，我希望 kubernetes 会自动杀死泄漏的 Pod，从而让你摆脱这种反模式；遇到需要如此复杂解决方法的内存以外的泄漏？
公平的问题，但是在 k8s 重新启动它们之前，pod 似乎变慢了很多，我们希望避免这种情况。因此，即使在内存消耗超出预期之前，也需要重新启动它们。显然，正确的解决方案是修复内存泄漏，我们最终会这样做。但现在假期快到了，我们需要一个快速的临时解决方案。

标签： kubernetes google-kubernetes-engine

【解决方案1】：

This answer to the linked question 建议使用来自 CronJob pod 的 kubectl rollout restart。该命令在内部通过向部署的 pod 规范添加注释来工作；由于 pod 规格不同，它会触发部署的新滚动升级。

假设您正在运行一个普通的重新部署；这将更改 pod 规范中的 image: 设置。大约在同一时间，kubectl rollout restart 发生改变了 pod 规范中的注释设置。 Kubernetes API 强制将这两个更改序列化，因此最终的部署对象将始终包含这两个更改。

然后，此问题会简化为“如果部署发生更改并需要触发重新部署，而重新部署已经在运行，会发生什么？” Deployment documentation 涵盖了这种情况：它将开始在最新版本的 pod 规范上部署新的 pod，并将所有旧的 pod 视为“旧”，因此具有中间状态的 pod 在被替换之前可能只存在几分钟.

简而言之：这应该始终如一，您不需要采取任何特殊的预防措施。

【讨论】：

感谢您的详细解答！正是我需要知道的。