问题描述
我在kubernetes官方文档中找不到关于此的任何内容.替换长期运行的cron作业的实际低层流程是什么?我想了解这一点，以便我的应用程序可以正确处理它.
I couldn't find anything in the official kubernetes docs about this. What's the actual low-level process for replacing a long-running cron job? I'd like to understand this so my application can handle it properly.
- 是干净的
SIGHUP/SIGTERM信号被发送到正在运行的应用程序吗? - 在发送该信号后是否有一个等待期，因此应用有时间清理/关闭，然后有可能被杀死?如果是这样，那超时时间是几秒钟?还是永远等待?
- Is it a clean
SIGHUP/SIGTERMsignal that gets sent to the app that's running? - Is there a waiting period after that signal gets sent, so the app has time to cleanup/shutdown before it potentially gets killed? If so, what's that timeout in seconds? Or does it wait forever?
作为参考，这是文档中的 Replace 策略说明:
For reference, here's the Replace policy explanation in the docs:
https://kubernetes.io/docs/任务/作业/带有cron作业的自动化任务/
- 替换:如果是时候开始新的任务运行并且之前的任务尚未完成，则cron任务会用新的任务运行替换当前正在运行的任务运行
推荐答案
CronJob的下面只有另一个Pod.
A CronJob has just another Pod underneath.
当并发策略为替换"的Cronjob仍处于活动状态时，工作将被删除，这也将删除Pod.
When a Cronjob with a concurrency policy of "Replace" is still active, the Job will be deleted, which also deletes the Pod.
当Pod被删除时，在宽限期(默认为30秒)后，将向Linux容器发送 SIGTERM ，然后发送 SIGKILL . PodSpec 设置为覆盖该默认值.
When a Pod is deleted the Linux container/s will be sent a SIGTERM and then a SIGKILL after a grace period, defaulted to 30 seconds. The terminationGracePeriodSeconds property in a PodSpec can be set to override that default.
由于标记添加到 DeleteJob 调用，听起来像此删除操作只是从kube键/值存储中删除值.这意味着可以在当前Job/Pod仍终止的同时创建新的Job/Pod.您可以使用不遵守 SIGTERM 且将 terminationGracePeriodSeconds 设置为集群调度速度几倍的Job进行确认.
Due to the flag added to the DeleteJob call, it sounds like this delete is only deleting values from the kube key/value store. Which would mean the new Job/Pod could be created while the current Job/Pod is still terminating. You could confirm with a Job that doesn't respect a SIGTERM and has a terminationGracePeriodSeconds set to a few times your clusters scheduling speed.
这篇关于当kubernetes cron作业吊舱被“替换"终止时，停机的状态如何?并发策略?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！