需用 client-go ≥v0.22.0，导入 batchv1 并设 apiversion="batch/v1"；go 程序须正确退出（os.exit(0/1)）、recover panic、用 context 控制 goroutine；cronjob 要求 utc 时间、rbac 授权 jobs/cronjobs、避免 timezone 字段误配。
怎么用 client-go 创建 CronJob 对象
直接调用 Kubernetes API 创建 CronJob，核心是构造 CronJob 结构体并提交给集群。别写 YAML 再 kubectl apply —— Go 程序里要的是 client-go 的原生交互方式。
常见错误现象：Invalid value: "v1": no kind "CronJob" is registered for version "batch/v1"，说明用了旧版 API 组（batch/v1beta1）但集群已禁用，或 client-go 版本太低不支持 batch/v1。
- 确保 client-go 版本 ≥ v0.22.0（对应 K8s 1.22+），用
batchv1.CronJob而非batchv1beta1.CronJob -
apiVersion必须写成"batch/v1"，不是"batch/v1beta1"，否则创建失败或被拒绝 -
spec.jobTemplate.spec.template.spec.containers[0].command要写完整可执行路径，比如["/app/myjob"]，不能只写["myjob"]（镜像里没配 PATH 或没进 PATH） - 如果程序需要读取 ConfigMap/Secret，记得在
spec.jobTemplate.spec.template.spec.volumes和volumeMounts里显式挂载，CronJob 不自动继承 namespace 下的默认卷
如何让 Go 程序作为 CronJob 容器正确退出
CronJob 依赖 Job 控制器判断任务是否完成，而 Job 又靠容器主进程 exit code 判定成功或失败。Go 程序若 panic 后没捕获、或 os.Exit(0) 前有 goroutine 漏跑，会导致 Job 卡在 Running 状态，甚至触发重试爆炸。
使用场景：定时拉日志、清理临时文件、调用外部 API 同步数据——这些都要求“做完就退”，不能常驻。
- 用
defer os.Exit(0)是错的：exit 会跳过 defer，且无法区分成功/失败 - 主函数结尾统一用
os.Exit(exitCode)，成功为 0，失败为非 0（如 1） - 全局 panic 恢复必须放在
main()开头：defer func() { if r := recover(); r != nil { log.Fatal(r) } }()，否则 panic 直接导致 exit code = 2 - 如果有 long-running goroutine（比如 ticker + select），必须通过
context.Context控制生命周期，并在 main return 前cancel()，避免主 goroutine 退出后子 goroutine 还在跑
为什么 CronJob 创建后没触发，或者触发了但 Job 不生成
不是代码问题，往往是配置或权限卡点。K8s 对 CronJob 的调度有隐含前提，漏掉任意一条都会静默失效。
常见错误现象：kubectl get cronjob 显示 ACTIVE 0，kubectl describe cronjob xxx 里看不到 Last Schedule，Events 为空；或者看到 FailedCreate 但没具体报错。
-
spec.schedule格式必须符合 POSIX cron（5 字段），比如"0 * * * *"，不能写成"0 */1 * * *"（部分老版本不认） - 时间字段用的是
UTC，不是集群节点本地时区，也不是你本地机器时区——这是最容易被忽略的时差坑 - RBAC 权限缺一不可：ServiceAccount 至少要有
create权限对jobs和cronjobs资源，否则 Job 模板根本无法实例化 - K8s 1.21+ 默认关闭
AllowDangerousScheduling，如果 CronJob 的spec.timeZone字段写了但集群不支持（比如未启用 FeatureGate），整个对象会被拒绝，kubectl create 报 400 错误
如何调试 CronJob 启动失败的 Go 容器
Job 失败后 Pod 很快变成 Completed 或 Error，默认查不到日志。得先捞出 Pod 名，再指定参数看输出，否则只能靠猜。
性能影响：频繁失败的 CronJob 会产生大量终止态 Pod，填满 etcd，拖慢整个 namespace 的 list 操作。
- 用
kubectl get jobs -n xxx --sort-by=.status.startTime找最新 Job，再kubectl get pods -n xxx --selector=job-name=xxx-xxxxx找对应 Pod - Pod 已终止？加
--previous参数：kubectl logs -n xxx <code>pod-name--previous - Go 程序启动即 panic？在容器启动命令前加
sh -c 'echo \"start at $(date)\"; exec /app/myjob'，确认是否进到容器 - 怀疑镜像里二进制权限不对？进容器调试：
kubectl debug -it -n xxx <code>pod-name--image=busybox --share-processes，然后ls -l /app/myjob
真正麻烦的不是写 CronJob，而是它的失败不报错、不告警、不重试——它只是安静地不干活。时间字段写错、时区设错、RBAC 少一条、Go exit code 没设对，任何一个点都会让你等三天才发现任务根本没跑过。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
