【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上来看，我一个调用方为啥要考虑业务信息之外的逻辑，应该直接将时间戳发送给被调用方，让被调用方通过本地服务器配置来适配时区。