历史记录留多少合适
CronJob 会把已完成与失败的 Job 作为历史记录保留下来，由 successfulJobsHistoryLimit 与 failedJobsHistoryLimit 控制数量，常见默认值分别是 3 与 1。这些历史对象是查看日志与排障的主要证据；保留过多会让已完成的 Job 与 Pod 不断累积，增加对象数量与巡检噪声；保留过少又会让连续失败的现场被迅速顶掉，事后无从追溯。
基本信息
| 适用对象 | 各版本的 CronJob |
|---|---|
| 关键字段 | successfulJobsHistoryLimit 与 failedJobsHistoryLimit |
| 常见默认 | 成功历史 3，失败历史 1 |
| 影响对象 | Job 及其产生的已完成 Pod |
| 范围提醒 | 不限制正在运行的 Job，只清理已完成的对象 |
典型使用场景
- 排障取证：连续失败时保留足够现场用于定位
- 对象治理：控制已完成 Job 与 Pod 的数量，减少噪声
- 巡检核对：确认是否存在大量残留的历史对象
- 重要任务差异化：关键任务保留更多失败历史
- 配合自动清理：在任务模板里设置完成后自动回收的时长
配置示例
配置示例
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
namespace: prod
spec:
schedule: "0 2 * * *"
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3 # 保留多少成功历史
failedJobsHistoryLimit: 2 # 关键任务可适当调大
jobTemplate:
spec:
ttlSecondsAfterFinished: 86400 # 完成后一天自动清理，可数量与时间双管
template:
spec:
restartPolicy: Never
containers:
- name: backup
image: registry.example.com/backup:1.4检查堆积情况
检查堆积情况
kubectl get jobs -n prod | grep backup
kubectl get pods -n prod --field-selector status.phase=Succeeded | wc -l
kubectl get cronjob nightly-backup -n prod -o jsonpath='{.spec.successfulJobsHistoryLimit}/{.spec.failedJobsHistoryLimit}'
kubectl get jobs -n prod -l app=backup -o custom-columns='JOB:.metadata.name,STATUS:.status.conditions[0].type'字段与影响
| 字段 | 作用 | 注意 |
|---|---|---|
| successfulJobsHistoryLimit | 保留多少成功历史 | 过多会积累已完成对象 |
| failedJobsHistoryLimit | 保留多少失败历史 | 过少时连续失败现场会被迅速顶掉 |
| 正在运行的 Job | 不受数量限制影响 | 只清理已完成对象 |
| 完成后的自动清理时长 | 按时间回收 | 可与数量限制叠加使用 |
历史记录是排障的主要证据来源：重要任务可以调大失败历史的保留数，或把日志集中收集，避免对象清理后线索也一起消失。
数量限制只作用于已完成对象：正在运行的 Job 不会被清理，容量与资源问题仍要看运行中的任务本身。