【Kubernetes】CronJob 执行时间存在大量延迟

在这里插入图片描述
最近在迁移集群CronJob的时候,发现了一个问题:CronJob执行大概差了八个小时。当前的(指写文章)时间是5.18 19:36分,往前推45个小时,大概是5.16 22:36分,和我预设CronJob表达式子里写明的
0 14 16 * * 16号14:00相差了八个小时。

今天来研究一下这个小时究竟问题出在哪。

从八个小时上来判断,正好是UTC +0 和 UTC +8的时差,也正好是我们的美国服务器和上海时间的时差。所以猜测上是集群设置时区的问题。

查了一下文档,发现CronJob的执行时间是根据kube-controller-manager的时间来控制
在这里插入图片描述
所以看了一下这个pod上的时区设置是UTC +0
在这里插入图片描述
然后看了一下 在CronJob表达式的业务逻辑,指定了上海这个时区。

        Date date = new Date(time);
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        simpleDateFormat.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));

这个问题的链路就是 微服务A制定了上海市UTC+8作为Cron表达式,然后将这个Cron表达式发送给kube-api由kube-crontroller-manager来执行控制。而kube-crontroller-manager的时区认定在了UTC+0。

举个例子,处于UTC+8的微服务A说你在 16号 8点钟来执行这个任务,但是A并没有考虑美国服务区的时区。Kube-Controller-manager认为这个8点钟是对于自己UTC+0来说的时区,所以让微服务A多等待了八个小时。

最后解决办法倒是很简单,直接把上面的业务代码换成对应Kube-Controller-manager对应的时区。

        Date date = new Date(time);
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        simpleDateFormat.setTimeZone(TimeZone.getTimeZone(ZoneOffset.UTC));

但这只是一时之计,撤掉解决的思路大概现在有两种

  1. 站在SpringBoot 约定大于配置的角度上想,如果几方决定使用UTC+0的时区的话,应该和所有达成一致。否则不应该随便更换Kube-Controller-manager的时区。
  2. 站在Client-Server上来看,我一个调用方为啥要考虑业务信息之外的逻辑,应该直接将时间戳发送给被调用方,让被调用方通过本地服务器配置来适配时区。
展开阅读全文
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值