由于我们其中一个服务的内存泄漏，我计划添加一个k8s CronJob来安排泄漏服务的定期重新启动。目前，我们没有资源来正确调查mem泄漏，因此我们需要一个临时解决方案来快速减少泄漏引起的问题。这将是滚动重启，如下所述：
如何安排 Pod 重新启动
我已经在我们的测试集群中对此进行了测试，它似乎按预期工作。该服务在测试中具有 2 个副本，在生产环境中具有 3 个副本。
我的计划是安排 CronJob 每 2 小时运行一次。
我现在想知道：如果新的 CronJob 应该在服务升级已经在运行时执行，它将如何表现？我们进行滚动升级以实现零停机时间，有时我们每天会多次推出升级。我不想通过说"请确保您永远不会在 08：00、10：00、12：00 等附近部署"来限制部署升级的人员。从长远来看，这永远不会奏效。
反之亦然，我也想知道如果在 CronJob 已经在运行并且 pod 重新启动时启动升级会发生什么。
Kubernetes 是否有内置的东西来处理这种冲突？
这个链接问题的答案建议使用 CronJob pod 中的kubectl rollout restart。 该命令通过在部署的容器规范中添加注释来在内部工作;由于 Pod 规范不同，它会触发部署的新滚动升级。
假设您正在运行普通的重新部署;这将更改 Pod 规范中的image:设置。 大约在同一时间，发生了更改 Pod 规范中的注释设置的kubectl rollout restart。 Kubernetes API 强制序列化这两个更改，因此最终部署对象将始终包含这两个更改。
然后，这个问题简化为"如果部署发生更改并需要触发重新部署，而重新部署已在运行，会发生什么情况？ 部署文档涵盖了这种情况：它将开始在最新版本的 Pod 规范上部署新 Pod，并将所有旧 Pod 视为"旧"，因此具有中间状态的 Pod 可能只存在几分钟，然后就会被替换。
简而言之：这应该始终如一地工作，您不需要采取任何特殊的预防措施。