K8s长期运行索引Job中失败Pod的快速垃圾回收配置咨询

针对你提到的K8s 1.26.3环境下，索引Job（RestartPolicy=Never）中大量Errored状态Pod长期留存的问题，以下是几个可行的配置方案：

1. 配置Pod级别的ttlSecondsAfterFinished #

Job的ttlSecondsAfterFinished仅作用于Job对象本身，且只有当Job进入完成状态（Succeeded/Failed）后才会触发回收，而你的Job长期运行（持续创建新Pod），因此该配置对未完成Job下的失败Pod无效。

你需要在Job的Pod模板中添加Pod级别的ttlSecondsAfterFinished字段，该字段会在Pod进入Finished状态（包含Failed/Errored）后自动触发垃圾回收。示例配置：

apiVersion: batch/v1
kind: Job
metadata:
  name: index-job
spec:
  completions: 5000
  parallelism: 100
  template:
    spec:
      restartPolicy: Never
      ttlSecondsAfterFinished: 600 # 10分钟后回收已完成（含失败）的Pod
      containers:
      - name: index-container
        image: your-image:tag
        command: ["your-index-command"]

K8s 1.25及以上版本中，Pod级TTL特性已稳定，你的1.26.3环境完全支持。

2. 结合Pod Failure Policy优化失败处理 #

既然你已启用podFailurePolicy，可在策略中配置精准的失败判定，并配合Pod TTL实现快速回收。比如针对特定错误类型的Pod，确保其进入Failed状态后触发TTL回收：

spec:
  podFailurePolicy:
    rules:
    - action: Continue # 保持Job继续创建新Pod，符合你的业务需求
      onExitCodes:
        values: [1, 255] # 匹配索引任务的失败退出码
      onPodConditions:
      - type: Error
        status: "True"

3. 全局节点级垃圾回收（兜底方案） #

如果需要全局层面限制失败Pod的留存时间，可调整kubelet的垃圾回收参数：

• 修改kubelet配置文件（通常为/var/lib/kubelet/config.yaml），设置软驱逐规则，针对节点上的失败Pod数量或占比设置阈值：

evictionSoft:
  podFailedTotal: "100" # 节点上失败Pod超过100个时触发软驱逐
evictionSoftGracePeriod:
  podFailedTotal: "5m" # 达到阈值后5分钟开始回收

该方案为节点级全局控制，适合统一限制所有失败Pod的场景，但精准度不如Pod级TTL。

4. 自定义清理脚本（临时 workaround） #

若上述原生方案暂时无法落地，可通过CronJob定期清理指定Namespace下的Errored/Failed Pod：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: clean-failed-pods
spec:
  schedule: "*/10 * * * *" # 每10分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: kubectl
            image: bitnami/kubectl:latest
            command:
            - /bin/sh
            - -c
            - kubectl delete pods --field-selector=status.phase=Failed -n your-namespace

此方案属于临时补救，不推荐长期依赖，优先使用原生TTL机制。

内容的提问来源于stack exchange，提问作者Anirudh Jayakumar