Kubernetes 定时任务应使用原生 CronJob 资源，而非用 Deployment 运行含 time.Ticker 的 Go 程序；需将业务逻辑封装为一次性命令行工具，由 CronJob 按 cron 表达式调度执行，并正确配置 schedule、restartPolicy 和 concurrencyPolicy。
用 CronJob 资源定义定时任务，不是写个 Go 程序跑在集群里就叫“Kubernetes 定时任务”
很多人误以为：写个 time.Ticker 的 Go 程序，打包进镜像、用 Deployment 部署，就算实现了 Kubernetes 定时任务。这不对——它缺乏调度可靠性、失败重试、历史记录、并发策略控制等关键能力。Kubernetes 原生的 CronJob 才是正确入口。
真正该做的，是把你的 Go 逻辑封装成一个「一次执行即退出」的命令行工具（比如 my-backup-tool --db=prod），然后交给 CronJob 调度。它会按 cron 表达式拉起 Pod，Pod 运行完自动终止，状态可查、日志可追溯。
-
CronJob是 Kubernetes API 对象，需用 YAML 定义，不是 Go SDK 调用某个函数就能替代的 - Go 程序本身只需关注业务逻辑，不负责“什么时候运行”——这个职责必须交给集群调度层
- 避免在 Go 代码里硬编码
time.Sleep或time.AfterFunc，否则 Pod 挂了任务就丢了
编写 CronJob YAML 时，这三个字段最容易配错
哪怕 Go 程序完全正确，CronJob YAML 写错也会导致任务不触发、反复重启或堆积大量僵尸 Job。
-
schedule字段必须是标准 Unix cron 格式（如"0 * * * *"），不能写成 Go 的time.Duration字符串（如"1h"）；注意分钟在前、小时在后，和 Linux crontab 一致 -
jobTemplate.spec.template.spec.restartPolicy必须设为"OnFailure"或"Never"（推荐"OnFailure"），设成"Always"会导致容器退出后无限重启，Job 永远不结束 -
concurrencyPolicy默认是"Allow"，若上一个任务还没结束，下一个又到点，就会并发运行；生产环境建议显式设为"Forbid"防止资源争抢或数据冲突
示例片段：
立即学习“go语言免费学习笔记（深入）”；
apiVersion: batch/v1
kind: CronJob
metadata:
name: daily-report
spec:
schedule: "0 2 * * *" # 每天凌晨 2 点
concurrencyPolicy: "Forbid"
jobTemplate:
spec:
template:
spec:
restartPolicy: "OnFailure"
containers:
- name: runner
image: my-registry/my-go-tool:v1.2
args: ["--action=send-daily-report"]Go 程序怎么适配 CronJob：退出码、日志、超时三件事必须处理
你的 Go 二进制被 CronJob 启动后，Kubernetes 只认一件事：进程退出码。0 表示成功，非 0 表示失败（会触发重试或标记为 Failed）。其余全是细节问题。
- 主逻辑执行完必须调用
os.Exit(0)，别依赖函数自然返回——尤其有 goroutine 未结束时，main 返回不代表进程退出 - 所有关键步骤打结构化日志（比如用
log/slog输出 JSON），Kubernetes 日志采集器才能正确解析时间戳和 level；避免只用fmt.Println打乱时间顺序 - 务必设置全局超时：
context.WithTimeout(context.Background(), 30*time.Minute)，防止数据库卡住或网络 hang 死导致 Pod 永不退出；CronJob 的activeDeadlineSeconds可作为兜底，但 Go 层主动控制更可靠
调试 CronJob 失败：先看 Job 和 Pod，别急着改 Go 代码
任务没运行？运行失败？90% 的情况和 Go 逻辑无关，而是资源对象没生效或权限不足。
- 先运行
kubectl get cronjob确认资源已创建；再看kubectl get job -w是否生成了新 Job；最后查对应 Pod：kubectl describe pod -l job-name=xxx，重点看Events区域里的 Warning（比如ImagePullBackOff、FailedScheduling、Forbidden） - 如果 Job 已创建但 Pod 始终 Pending，大概率是节点资源不足，或 ServiceAccount 缺少 RBAC 权限（比如你的 Go 程序要读 Secret，但
ClusterRoleBinding没给对应权限） - Pod 启动后立即 CrashLoopBackOff？用
kubectl logs <pod-name>查输出；若日志为空，说明进程启动失败（比如二进制路径错、缺少动态库、args 解析 panic），这时要检查容器entrypoint和args是否匹配
真正需要进 Go 代码调试的情况，通常出现在日志里明确出现 panic 或业务错误码之后——在此之前，别碰 main.go。
