为何Kubernetes Job执行成功后完成状态仍显示0/1不更新？

核心问题定位 #

• 退出码捕获逻辑完全错误
  Shell 中命令的退出状态码存储在内置变量$?中，当前写法IS_SUCCESS=$(load_config "$i")仅能捕获命令的标准输出内容，完全无法获取退出码。如果load_config执行时往标准输出打印了非预期内容，会直接导致判断逻辑完全失真：
  • 若成功执行时输出1，会被误判为失败触发非0退出
  • 若输出为空，会触发数值比较语法错误，脚本直接异常退出
    正确写法为：

  load_config "$i"
  IS_SUCCESS=$?
  

• Shell 解释器与脚本语法不兼容
  脚本使用了 Bash 专属的条件判断语法[[ ]]，但 Helm 配置中明确使用sh作为解释器执行脚本。多数 Linux 发行版的默认sh是 Dash，不支持[[语法，会直接抛出语法错误导致脚本异常退出。要么将执行命令改为bash，要么将[[ ]]替换为 POSIX 标准的[ ]。
• 脚本退出逻辑位置错误
  从代码片段的缩进来看，exit 0的位置存在异常：
  • 若exit 0在for循环内部，会导致第一次成功加载实体后就提前退出，后续实体无法完成加载
  • 若缩进错误导致exit 0未在循环外，可能因为脚本缺失fi/done等语法收尾，执行完所有循环逻辑后没有正常退出，反而进入容器默认的tail -f /dev/null常驻进程，Pod 一直处于运行状态直到被 Job 控制器主动删除
• Job 控制器状态回传时序问题
  当累计失败次数接近 backoff limit 时，Job 控制器会优先判定已达到退避阈值，主动删除所有关联 Pod，不会等待第6次运行的退出状态回传。从事件日志中SuccessfulDelete和BackoffLimitExceeded同时存在的特征可以确认，第6次运行的成功状态还未上报就被控制器主动删除，自然不会更新 Completions 为 1/1。

修复方案 #

• 修正退出码捕获逻辑，通过$?获取load_config的执行状态
• 将脚本执行解释器改为 Bash，或替换为 POSIX 兼容的条件判断语法
• 调整脚本缩进，确保所有实体加载完成后再执行exit 0，补全缺失的fi/done语法结构
• 可适当提高 backoff limit 配置，避免控制器提前触发退避限制

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