Cronjob 并发规则(concurrencyPolicy)

TL;DR 🔗

在k8s 集群中添加计划任务(Cronjob)时，需要考虑关于调度时间间隔和计划任务执行时长的问题。如果调度频率相对过于频繁会出现一种情况：由于计划任务脚本执行时间过长，在前一次的计 划任务还没执行完的情况下，又开始了下一次调度。

Resolution: 只需根据需要相应调整 .spec.concurrencyPolicy ：

...
spec:
  concurrencyPolicy: Replace
...

• Allow: 默认值。允许并发执行任务: 旧任务继续执行，也继续调度执行新任务
• Replace: 旧任务终止执行，并重新调度执行新任务
• Forbid: 旧任务继续执行，忽略执行新任务

Question Description 🔗

最近几天，业务告警系统中突然出现很多node load相关的 warning 和 critical 告警信息。

在之前某次处理过这个问题，之后再也没发生过，就没继续关注了；之前因为告警的 node 都是同一个节点，大致查看下是因为多个 cronjob 总是默认调度到同一个告警节点执行 job,所以就在某些 cronjob上添加了 nodeName：WorkNodeName 把一些 job 绑定到其他节点。

本次直接在 grafana 监控面板查看：告警节点上的 问题pod (cronjob 调度生成的)相对于同一节点其他pod来说，cpu 使用量会高出很多。虽然相对很多，但cpu使用量也没有超过 700m（1c=1000m）， 界面来看也没什么特别异常。于是就直接命令行操作了：

# cronjob 部署在 default namespace
# 获取告警节点上的 pod
kubectl get pod -o wide | grep NodeName (告警节点名称)

#  查找所有 namespace 中 cpu 使用量较高的前十个 pod
 kubectl top pod -A | grep -v CPU | sort -rn -k3 | head

# 观察到较高cpu使用量的pod确实运行在告警节点。
# 正常情况下的需求是每次只运行一个job，但是上述操作发现同一个 cronjob 调度生产了多个 job

# 获取 default namespace 中所有 pod
kubectl get pod -o wide
# 发现很多 Evicted状态的pod,大概是因为告警节点资源不足导致 pod 被驱逐

# 查看相应 cronjob 具体配置
 kubectl get cronjob CronJobName -o yaml |less
 ...
 spec:
  concurrencyPolicy: Allow  #默认策略
  schedule: '*/11 * * * *'
  ...
# 最开始的获取 pod时，有的pod已经运行 20-40min 不等，但是计划任务调度时间是每 11min执行一次
# 所以会出现 job 并发执行的问题

最终和开发确认了计划任务执行策略，调整 .spec.concurrencyPolicy为Replace