GKE同命名空间下Job使用cloudsql-proxy配合Workload Identity出现scope检查超时问题

数据老陈

2026-10-2

问题根因及解决方案

你的报错本质是Pod无法通过GKE Workload Identity的元数据代理服务获取到对应服务账号的权限配置，同命名空间同KSA的Deployment正常，说明GSA-KSA绑定本身没有问题，问题出在Job的Pod配置差异上，按以下优先级排查修复：

1. 检查Job是否正确配置了服务账号

你必须在Job.spec.template.spec中显式指定serviceAccountName为绑定了GSA的KSA名称，不可省略或使用默认的default服务账号：

apiVersion: batch/v1
kind: Job
spec:
  template:
    spec:
      serviceAccountName: 【你的绑定了GSA的KSA名称】 # 必须和正常运行的Deployment使用的SA完全一致
      # 禁止配置 hostNetwork: true，该配置会绕过Workload Identity的元数据代理

特别注意：不要在Job的Pod配置中开启hostNetwork: true，开启后会直接访问节点元数据服务器，绕过Workload Identity代理逻辑，直接触发超时错误

2. 新增参数跳过云API作用域检查

Workload Identity模式下不需要依赖节点的OAuth作用域配置，你可以直接给cloudsql-proxy启动命令添加-skip_scopes_check=true参数跳过报错的检查步骤，修改后的args配置如下：

args:
  - |
    /cloud_sql_proxy -instances={{ $global.Values.cloudsql.connection_string }}=tcp:{{ $global.Values.cloudsql.port }} -term_timeout=30s -log_debug_stdout=true -skip_scopes_check=true &
    CHILD_PID=$!
    ls -al
    (while true; do if [[ -f "/signals/finished" ]]; then kill $CHILD_PID; fi; sleep 1; done) &
    wait $CHILD_PID
    if [[ -f "/signals/finished" ]]; then exit 0; fi