Kubernetes Job长时运行initContainer异常问题排查与解决

问题根因 #

升级到GKE 1.26后，你的Job因initContainer等待API启动（最长10分钟）的时间超过了Kubernetes默认的Job健康判定阈值，导致K8s误判原Pod未正常启动，触发新Job实例创建，最终引发业务冲突。

修复方案 #

1. 延长Job活跃超时时间 #

设置activeDeadlineSeconds覆盖initContainer的最长等待时间，避免K8s因超时强制终止并重建Job：

apiVersion: batch/v1
kind: Job
metadata:
  name: your-job-name
spec:
  activeDeadlineSeconds: 720 # 设为12分钟，大于initContainer的10分钟等待上限
  template:
    spec:
      initContainers:
      - name: health-check
        image: your-health-check-image
        command: ["your-wait-script.sh"]
      containers:
      - name: run-job
        image: your-business-image
      restartPolicy: OnFailure

2. 配置Pod失败策略，忽略初始化状态 #

使用podFailurePolicy精准过滤initContainer的等待状态，避免K8s误判为Pod失败：

apiVersion: batch/v1
kind: Job
metadata:
  name: your-job-name
spec:
  backoffLimit: 3 # 根据业务需求调整重试次数
  podFailurePolicy:
    rules:
    - action: Ignore
      onPodConditions:
      - type: PodInitializing
        status: "True" # 忽略处于初始化中的Pod，不触发重试
    - action: Ignore
      onExitCodes:
        values: [0] # 如果等待脚本返回0（正常等待），忽略该状态
  template:
    spec:
      initContainers:
      - name: health-check
        image: your-health-check-image
        command: ["your-wait-script.sh"]
      containers:
      - name: run-job
        image: your-business-image
      restartPolicy: OnFailure

3. 确保initContainer资源充足 #

GKE 1.26对资源限制的检查更严格，若initContainer资源不足可能被标记为失败，需配置合理的资源请求与限制：

initContainers:
- name: health-check
  image: your-health-check-image
  command: ["your-wait-script.sh"]
  resources:
    requests:
      cpu: "100m"
      memory: "128Mi"
    limits:
      cpu: "200m"
      memory: "256Mi"

注意事项 #

• activeDeadlineSeconds从Job创建时开始计时，需包含initContainer等待时间+业务容器运行时间。
• podFailurePolicy是K8s 1.21+特性，GKE 1.26完全支持，可避免不必要的Job重试。
• Job仅支持OnFailure或Never两种重启策略，OnFailure会在Pod失败时重启容器，Never则直接创建新Pod，根据业务场景选择。

内容的提问来源于stack exchange，提问作者Rion Williams