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

由于我们的一项服务内存泄漏，我计划添加一个k8s CronJob来计划定期重新启动泄漏的服务。现在我们没有足够的资源来调查mem泄漏，所以我们需要一个临时的解决方案来快速减少泄漏造成的问题。这将是一次滚动重启，如下所述：

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

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

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

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

kubernetes是否具有处理此类冲突的内置功能？

建议从CronJob pod使用

kubectl卷展栏重新启动。该命令通过向部署的pod规范添加注释在内部工作；由于pod规范不同，它会触发部署的新滚动升级

假设你正在进行一次普通的重新部署；这将更改pod规范中的
图像：
设置。大约在同一时间，
kubectl卷展栏重新启动
会更改pod规范中的注释设置。Kubernetes API强制序列化这两个更改，因此最终部署对象中始终包含这两个更改

然后，这个问题归结为“当重新部署已经运行时，如果部署发生变化并需要触发重新部署，会发生什么情况？”这个问题涵盖了这种情况：它将开始在最新版本的pod规范上部署新的pod，并将所有旧的pod视为“旧的”，所以一个中间状态的吊舱在被替换之前可能只存在几分钟

简言之：这应该是一致的，您不需要采取任何特别的预防措施。
如果Pod上有
资源：
声明，我希望kubernetes会自动杀死泄漏的Pod，从而让您摆脱这种反模式；遇到内存以外的泄漏，需要如此复杂的解决方法？这是一个公平的问题，但在k8s重新启动之前，POD似乎慢了很多，我们希望避免这种情况。因此，即使在内存消耗失控之前，也需要重新启动它们。显然，正确的解决方案是修复mem泄漏，我们最终会这样做。但现在假期即将来临，我们需要一个快速的临时解决方案。谢谢你的详细回答！这正是我需要知道的。