我在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 信号被发送到正在运行的应用程序吗?SIGHUP/SIGTERM signal that gets sent to the app that's running?作为参考，这是文档中的 Replace 策略说明:
For reference, here's the Replace policy explanation in the docs:
https://kubernetes.io/docs/任务/作业/带有cron作业的自动化任务/
并发策略
CronJob的下面只有另一个Pod.
A CronJob has just another Pod underneath.
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 .
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.
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作业吊舱被“替换"终止时，停机的状态如何?并发策略?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程技术网(www.editcode.net)！
