Kubeflow Job主容器执行完成后仍无限运行问题咨询

常见诱因 #

你使用的Kubeflow Pipeline 底层依赖Argo Workflow执行，主容器完成后wait容器（即Argo Executor 侧容器）持续运行无法退出，常见诱因如下：

• Argo Executor 版本已知bug：你当前使用的gcr.io/cloud-marketplace/google-cloud-ai-platform/kubeflow-pipelines/argoexecutor:1.7.1属于较老版本，存在主容器退出信号感知失败、资源收集逻辑死锁的已知问题，在GKE环境使用默认容器运行时的场景下触发概率极高。
• 日志归档流程阻塞：wait容器默认会收集主容器所有stdout/stderr日志，上传到Pipeline关联的对象存储做持久化留存，如果主容器输出日志量过大、或者集群到存储的网络连通性异常，会导致日志上传逻辑卡住，wait容器无法进入退出流程。
• Sidecar 注入规则冲突：如果集群开启了Istio、安全审计、日志采集类的自动Sidecar注入，wait容器会误判Pod内仍有业务容器未完成执行，持续等待直到超时。
• 容器资源配额不足：wait容器默认分配的CPU、内存配额极低，当节点资源占用率过高时，会出现状态检测、日志上报逻辑无法调度到CPU资源，进而hang住。

解决方法 #

• 修复版本bug：将Argo Executor镜像升级到1.8.10及以上版本，或者使用GKE官方发布的KFP补丁版Executor镜像，替换Workflow Controller配置中的默认Executor镜像地址即可。
• 验证日志链路问题：给问题Pipeline添加注解argo.upstream.io/skip-log-archiving: "true"，如果修改后wait容器可以正常退出，即可定位为日志归档链路故障，后续排查存储连通性、调整日志分片规则即可。
• 排除Sidecar干扰：给KFP生成的Pod添加注解sidecar.istio.io/inject: "false"关闭Istio注入，或者配置Argo参数sidecar.automountServiceAccountToken: false，明确标记非业务Sidecar可以被提前终止。
• 调整资源配额：在KFP的Workflow Config配置中，调高Executor默认资源配额，建议至少设置为cpu: 0.1, memory: 128Mi，避免资源不足导致的调度阻塞。
• 应急处置：线上运行的任务可以手动给wait容器发送SIGTERM信号强制终止，不会影响已经完成的主容器执行结果，也可以手动修改Pod的terminationGracePeriodSeconds参数为10，触发Pod自动清理。

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