在最近升级到GKE 1.26之后，我开始遇到一个与Kubernetes作业相关的问题，该作业在历史上一直运行得很顺利。
作业本身包含两个组件：

• 一个简单的initContainer，只是对API/服务进行健康检查，有时在启动时需要一些时间来响应（有时大约10分钟）
• 处理逻辑和对所述API服务的各种调用的脚本

简单地说，它看起来像以下内容（为了简洁起见，省略了一些内容）：

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job-{{ now | date "20060102150405" }}
  labels:
    app: my-job
spec:
  backoffLimit: 0
  template:
    metadata:
      labels:
        app: my-job
      annotations:
        "cluster-autoscaler.kubernetes.io/safe-to-evict": "true"
    spec:
      restartPolicy: Never
      ...
      initContainers:
      - name: wait-service
        ...
        command: ['bash', '-c', 'while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://someService/api/v1/status)" != "200" ]]; do echo waiting for service; sleep 2s; done']
      containers:
        - name: run-job
          ...
      volumes:
          ...
      tolerations: 
          ...

字符串

**我遇到的问题是，在部署后约5分钟，当initContainer正在运行并等待服务时，Kubernetes将创建作业的新示例（包括自己的initContainer等）**这是有问题的，主要是因为在主容器（run-job）中运行的脚本的两个示例很容易导致其中的操作失去同步/进入不良状态（脚本涉及通过API以特定顺序暂停和恢复各种服务）。

我可以在原始作业的日志中验证这一点：

│ wait-service waiting for service 
| failed container "run-job" in pod "my-job-20230721165715-rh6s2" is waiting to start: PodInitializing for .../my-job-20230721165715-rh6s2 (run-job)                            
| wait-service waiting for service

型
因此，在这个作业的新部署大约5分钟后，我运行了它的两个示例（与上面失败的容器消息一致）。这通常以它们中的一个或两个处于不良状态而结束。
我尝试了一些配置更改，但收效甚微，我想知道处理此问题的最佳方法是什么？本质上，我需要为initContainer提供足够的容忍度，这样它就不会触发上述故障并重新创建一个新的作业（而是继续使用原始示例）。