时区决定时间表按谁算
CronJob 的 schedule 用 cron 表达式描述时间点，但这个表达式按哪个时区展开取决于 timeZone 字段：设置之后就按指定时区解释（例如 Asia/Shanghai），未设置则按控制面组件的本地时区，常见部署下是 UTC。跨时区团队协作、或与业务时间强相关的任务（比如每天上午九点出报表）必须显式声明时区，否则就会出现「时间对不上」的偏差。
基本信息
| 适用对象 | 支持该字段的较新版本 CronJob |
|---|---|
| 关键字段 | spec.timeZone，取值为 IANA 时区名称 |
| 未设置时 | 按控制面组件所在的本地时区解释，常见为 UTC |
| 版本约束 | 较老版本遇到该字段会校验失败 |
| 验证方式 | 查看 spec 与 status 中的最近调度时间 |
典型使用场景
- 业务时刻对齐：报表、结算、推送类任务必须在本地时间某刻执行
- 跨时区团队：多地协作时统一用业务所在地时区描述调度
- 迁移集群：从自建迁到云上时保持原有触发时刻不变
- 排查时间偏差：确认任务实际执行时刻与预期是否一致
- 多地部署：不同地域集群各自按本地区时区调度
配置示例
配置示例
apiVersion: batch/v1
kind: CronJob
metadata:
name: report
namespace: prod
spec:
schedule: "0 9 * * 1-5" # 工作日 09:00
timeZone: "Asia/Shanghai" # 按上海时间解释上面的表达式
jobTemplate:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: report
image: registry.example.com/report:1.3验证
验证
kubectl get cronjob report -n prod -o jsonpath='{.spec.timeZone}{"\n"}{.spec.schedule}'
kubectl describe cronjob report -n prod | grep -i -A2 -E 'schedule|last'
kubectl get jobs -n prod | grep report # 对照 Job 的创建时间
kubectl get cronjob report -n prod -o jsonpath='{.status.lastScheduleTime}'配置方式与影响
| 配置 | 解释方式 | 注意 |
|---|---|---|
| 显式设置时区 | 按指定时区展开表达式 | 推荐做法，跨时区协作必备 |
| 未设置时区 | 按控制面本地时区 | 集群迁移或重建后可能整体偏移 |
| 夏令时地区的时区 | 一年中存在时刻跳变 | 上线前对跳变日实测验证 |
| 较老版本集群 | 字段校验失败 | 升级后再使用该字段 |
不设置时区时行为依赖控制面配置：集群迁移或更换部署形态后，原本准点运行的任务可能整体偏移若干小时，现象很隐蔽。
使用带夏令时的时区时，一年中的某些凌晨时刻会出现跳变，涉及具体时刻的任务要实测验证而不是靠推断。