用 client-go 写定时清理脚本最可控，因其走原生 Kubernetes API，支持精细鉴权、重试、超时及字段筛选；应避免 List+循环 Delete，改用 fieldSelector 批量筛选并设置合理 QPS/Burst，准确识别 Evicted Pod（需 status.reason=="Evicted"），并通过 OwnerReference 判断是否跳过 Job/CronJob 关联 Pod。
用 client-go 写定时清理脚本最可控
直接调用 kubectl 做自动化清理在生产环境容易出问题：权限模型不清晰、错误难捕获、无法做精细过滤（比如跳过特定命名空间或带 Finalizer 的 Pod）。Go + client-go 是更健壮的选择，它走原生 Kubernetes API，能精确控制鉴权、重试、超时和字段筛选。
关键点在于：不要用 List + 循环 Delete 的“土法炼钢”方式。要用 fieldSelector 一次性筛选出目标 Pod，再批量提交删除请求——既减少 API 调用次数，也避免因并发导致的版本冲突（409 Conflict）。
- 必须设置
rest.Config的QPS和Burst，否则高负载集群下容易触发 API Server 限流 - 对
Evicted状态的判断，应同时检查.status.phase == "Failed"且.status.reason == "Evicted"，仅靠 phase 不够（有些 Failed Pod 并非被驱逐） - 删除前建议加
PropagationPolicy: metav1.DeletePropagationBackground，避免阻塞等待子资源清理
如何安全跳过正在调试的 Job/CronJob Pod
清理脚本如果误删了刚失败的 Job Pod，可能丢失日志和调试线索。不能只看状态，还得看来源。
真正可靠的判断依据是 OwnerReference：如果 Pod 的 ownerReferences 中包含 kind: Job 或 kind: CronJob，且该 Job 尚未设置 .spec.ttlSecondsAfterFinished，就该跳过——除非你明确配置了 --force-job-cleanup=true 这类开关。
立即学习“go语言免费学习笔记（深入）”；
- 用
metav1.GetControllerOf()辅助提取 owner，比手动遍历ownerReferences更稳妥 - 注意
CronJob创建的 Job 默认不会自动清理其 Pod，所以它的 Pod 即使是 Evicted 状态，也不代表可立即删 - 可通过
labels过滤（如job-name标签）快速识别来源，但 label 可被篡改，不能作为唯一依据
为什么不能只依赖 status.phase == "Failed"
Failed 是个宽泛状态，包含镜像拉取失败、容器启动崩溃、OOMKilled 等多种原因。而 Evicted 是 kubelet 主动终止的结果，必须通过 .status.reason 字段确认。两者语义不同，混用会导致误删。
实操中常见错误：用 fieldSelector=status.phase=Failed 批量删 Pod，结果把一个因配置错误卡在 ImagePullBackOff 的调试 Pod 给删了，再也看不到失败日志。
-
EvictedPod 的.status.reason固定为字符串"Evicted"，大小写敏感 -
FailedPod 的.status.reason可能是"OOMKilled"、"ContainerCannotRun"、"InvalidImageName"等，不是"Evicted" - etcd 里存的是原始 JSON，
.status.reason字段在某些旧版本（如 v1.21 之前）可能为空，需 fallback 到检查.status.containerStatuses[].state.terminated.reason
CronJob 配置清理任务时最容易漏掉的三件事
用 Kubernetes 自身的 CronJob 跑 Go 清理器看似省事，但实际线上踩坑最多。核心问题是：它本身也是 Pod，也会被驱逐。
- 必须给清理器 Pod 设置
resources.requests和resources.limits，否则可能因资源不足被优先驱逐，导致清理任务静默失效 - 要加
affinity把清理器固定到 master 节点或专用运维节点，避免和业务 Pod 争资源 - 务必配置
successfulJobsHistoryLimit: 1和failedJobsHistoryLimit: 3，否则 CronJob 自身会堆积大量已完成的 Job 对象，造成新一类资源泄露
复杂点在于：清理器需要读取所有命名空间的 Pod，但 ClusterRole 的 get 权限一旦放开，就等于给了它读取 secrets 的能力。最小权限原则下，应按需限制 namespace 白名单，或拆成多个按 namespace 分片运行的 Job。
