不能用Deployment跑后台任务，因其专为长期运行的无状态HTTP服务设计，要求进程持续存活；而后台任务有明确起止，退出即正常，Deployment会将其视为故障反复重启，且不支持OnFailure/Never重启策略。
Go 后台任务（如定时 Job、一次性 CronJob 或常驻 Worker）在 Kubernetes 中不是“部署就能跑”，而是必须按其生命周期模型设计：用 CronJob 而非 Deployment，禁用 HTTP 服务逻辑，显式处理退出信号，否则会卡在 Pending、反复重启或静默失败。
为什么不能用 Deployment 跑后台任务
Deployment 是为长期运行的、可扩缩的 HTTP 服务设计的，它依赖 readiness/liveness 探针和持续存活进程。而后台任务天然有明确起止——比如每小时拉一次日志、每天清理一次缓存。Kubernetes 会把这类任务当成“异常退出”反复重启，日志里只显示 Back-off restarting failed container，根本原因是你没告诉集群“这本来就应该退出”。
-
Deployment的 Pod 一旦进程退出（哪怕 exit code 0），Kubernetes 就认为故障，立即重建 - 后台任务代码若还保留
http.ListenAndServe或监听os.Interrupt外部信号但不处理，会导致容器挂起或无法终止 - 没有
restartPolicy: OnFailure或Never的语义支持，Deployment 只支持Always
CronJob YAML 必须配对的三个字段
CronJob 是唯一原生支持周期性后台任务的资源，但它容易因字段错位直接不触发——尤其 jobTemplate.spec.template.spec.restartPolicy、concurrencyPolicy 和 startingDeadlineSeconds 这三者不匹配时，Job 会创建失败或被跳过。
-
jobTemplate.spec.template.spec.restartPolicy必须设为OnFailure或Never（不能省略，默认是Always，但 Job 不支持） -
concurrencyPolicy设为Forbid防止上一个任务还没结束，下一个就启动（常见于耗时长的 DB 清理任务） -
startingDeadlineSeconds建议设为300（5 分钟），避免因节点负载高导致错过调度时间后被直接丢弃 - 示例片段：
spec: schedule: "0 * * * *" concurrencyPolicy: Forbid startingDeadlineSeconds: 300 jobTemplate: spec: template: spec: restartPolicy: OnFailure containers: - name: worker image: your-registry/go-worker:v1.2 args: ["--mode=cleanup"]
Go 代码里要删掉什么、加上什么
后台任务二进制和 HTTP 服务完全不同：它不该监听端口、不该注册探针路由、必须主动响应 SIGTERM 并完成收尾，否则 kubectl delete job 或超时强制终止时会丢失数据。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
立即学习“go语言免费学习笔记（深入）”；
- 删掉所有
http.ListenAndServe、livenessProbe相关逻辑、os.Signal里只监听os.Interrupt的代码 - 加上对
os.Interrupt和syscall.SIGTERM的捕获，并在 handler 里做 graceful shutdown（如关闭 DB 连接、提交未完成消息） - 入口函数末尾加
os.Exit(0)显式退出，别依赖 main 函数自然返回（某些 defer 在 exit 前不执行） - 简单示例：
func main() { ctx, cancel := context.WithCancel(context.Background()) defer cancel() <p>signal.Notify(ctx.Done(), os.Interrupt, syscall.SIGTERM) go func() { <-ctx.Done() log.Println("shutting down...") db.Close() // 或其他 cleanup os.Exit(0) }()</p><p>runCleanupTask() // 实际业务逻辑 }
镜像构建和权限的隐藏陷阱
后台任务镜像比 HTTP 服务更敏感：它常需访问 Secret、挂载 ConfigMap、写入 EmptyDir，但默认权限不足或路径错误会导致静默失败——比如日志写不进 /tmp，或读不到挂载的 /etc/config。
- Dockerfile 最好用
FROM scratch或gcr.io/distroless/static-debian12，避免 Alpine 的 musl 兼容问题（尤其用了 cgo 的 crypto 库） - 确保
CronJob的securityContext.runAsNonRoot: true时，你的二进制能写入指定目录（比如/var/log需提前mkdir并chown） - 挂载 ConfigMap 到容器内路径时，注意默认权限是
0644，Go 用ioutil.ReadFile能读，但os.OpenFile写就会 Permission denied - Secret 挂载后文件属主是
root:root，非 root 用户容器需用fsGroup设置组 ID 才能读取
最常被忽略的是：CronJob 创建的 Job Pod 默认不继承 Namespace 的 default ServiceAccount 权限，如果任务需要调 K8s API（比如 list Pods），必须显式绑定 RoleBinding；还有就是本地测试时用 go run 能跑，但镜像里忘了 CGO_ENABLED=0，一运行就报 no such file or directory——这个错误在 Job 日志里只会显示一行，根本看不出缺的是哪个动态库。
