kubernetes - 正在进行的升级如何影响计划的(滚动)服务重启(反之亦然)

Question

由于我们一项服务的内存泄漏，我计划添加一个k8s CronJob来安排该泄漏服务的定期重新启动。目前，我们没有足够的资源来正确调查内存泄漏，因此我们需要一个临时解决方案来快速减少泄漏引起的问题。它将是滚动重启，如下所示:
How to schedule pods restart
我已经在我们的测试集群中对此进行了测试，它似乎可以正常工作。该服务在测试中有2个副本，在生产中有3个副本。
我的计划是安排CronJob每2小时运行一次。
我现在想知道:如果新的CronJob在运行服务升级时应该恰好执行，将如何表现？我们进行滚动升级以实现零停机时间，有时我们每天进行几次升级。我不想通过说“请确保您永远不要在08:00、10:00、12:00等附近进行部署”来限制部署升级的人员。从长远来看，这永远都行不通。
反之亦然，我还想知道如果在CronJob已经运行并且Pod重新启动时开始升级，将会发生什么。
kubernetes是否有内置的东西可以处理这种冲突？

Answer 1

This answer to the linked question建议使用CronJob Pane 中的kubectl rollout restart。该命令在内部通过向部署的pod规范添加注释来起作用。由于Pod规格不同，因此会触发部署的新滚动升级。
假设您要进行普通的重新部署；这将更改pod规范中的image:设置。大约在同一时间，kubectl rollout restart发生更改了pod规范中的注释设置。 Kubernetes API强制将这两个更改序列化，因此最终部署对象将始终具有两个更改。
然后，该问题简化为“如果部署已更改并且需要在部署已经运行的同时触发重新部署，将会发生什么情况？” Deployment documentation涵盖了这种情况:它将开始在最新版本的Pod规范上部署新的Pod，并将所有较旧的Pod视为“旧”，因此处于中间状态的Pod可能只存在几分钟，然后才能被替换。
简而言之:这应该始终如一，并且您无需采取任何特殊的预防措施。