GitLab流水线执行gcloud获取GKE凭证后未生成~/.kube/config报错如何解决

问题产生原因 #

常见的诱因有以下几种：

• CI Job隔离问题：GitLab CI默认每个独立Job运行在单独的Runner容器/环境中，生成kubeconfig的命令和后续需要读取配置的命令如果分属不同Job，生成的文件不会自动跨Job共享，导致后续Job找不到文件。
• 环境变量配置异常：
  1. HOME环境变量被篡改：执行gcloud命令时的HOME路径和后续命令的HOME路径不一致，比如执行gcloud时HOME指向GitLab工作目录/builds/xxx，后续命令HOME被重置为/root，配置文件生成到了前者路径下，后者读取不到。
  2. KUBECONFIG环境变量被自定义：如果环境中设置了KUBECONFIG指向其他路径，gcloud会把配置写入指定路径而非默认的~/.kube/config，后续命令读默认路径就会报错。
• 执行用户不一致：生成配置的命令和后续读取配置的命令使用了不同用户执行，比如前者用普通gitlab-runner用户，后者用root用户，两个用户的HOME目录不同，配置文件生成在普通用户家目录下，root用户读取自己家目录自然找不到。
• 目录权限/不存在问题：运行gcloud的用户没有~/.kube目录的写入权限，或者目录不存在，部分旧版本gcloud存在提示生成成功但实际写入失败的兼容问题。

排查步骤 #

在生成kubeconfig的命令之后、后续报错命令之前，插入以下调试命令定位问题：

# 打印当前执行用户
whoami
# 打印HOME路径
echo $HOME
# 打印KUBECONFIG变量，确认是否自定义路径
echo $KUBECONFIG
# 检查默认路径下是否存在配置文件
ls -la ~/.kube/ || echo ".kube目录不存在"
# 如果KUBECONFIG不为空，检查对应路径
if [ -n "$KUBECONFIG" ]; then ls -la $(dirname $KUBECONFIG); fi

同时确认两个操作是否在同一个CI Job中。

解决方案 #

根据排查到的原因对应处理即可：

1. 跨Job文件不共享场景：将生成的kubeconfig设置为Job产物，供后续Job使用，示例配置：

# 生成配置的Job
generate-kubeconfig:
  script:
    - 原有生成配置的命令
    - cp ~/.kube/config ./kubeconfig
  artifacts:
    paths:
      - ./kubeconfig

# 后续需要读取配置的Job
use-kubeconfig:
  dependencies:
    - generate-kubeconfig
  script:
    - mkdir -p ~/.kube
    - cp ./kubeconfig ~/.kube/config
    - 后续业务命令

2. 环境变量/路径不一致场景：显式指定kubeconfig路径，避免默认路径的不确定性，示例：

# 生成时显式指定路径
gcloud container clusters get-credentials $NAME --zone $REGION --project $PROJECT --kubeconfig ~/.kube/config
# 或者统一设置KUBECONFIG环境变量
export KUBECONFIG=./kubeconfig
gcloud container clusters get-credentials $NAME --zone $REGION --project $PROJECT
# 后续命令自动读取该变量即可

3. 目录权限问题：执行gcloud命令前先创建目录并授权：

mkdir -p ~/.kube
chmod 700 ~/.kube

4. 补充遗漏参数：原脚本中已经提取了PROJECT变量但未使用，建议在gcloud命令中补充--project $PROJECT参数，避免gcloud默认项目不对导致的配置生成异常。

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