我最近在GitLab免费账户上折腾Kubernetes集成时踩了个坑——CI流水线里本该自动注入的Kubernetes相关环境变量完全没生效，导致部署步骤直接报错。先跟大家同步下我的环境背景，方便对照排查：

• 使用GitLab免费账户，已完成Kubernetes集群配置，Helm Tiller、Prometheus、GitLab-CI-Runner均安装完成
• Runner能正常执行常规CI任务，基础CI/CD链路是通的
• 受免费账户限制，仅能添加一个带*范围的集群

核心问题很明确：在CI作业中，像KUBECONFIG、KUBE_NAMESPACE这类GitLab本该自动注入的K8s相关变量，完全找不到踪迹。我翻了不少社区讨论，发现绝大多数方案都是针对旧版GitLab-Kubernetes集成方式的——比如手动配置集群变量、修改Runner配置模板，但这些逻辑和现在新版的集成流程完全不匹配，新版是通过GitLab界面直接关联集群、自动同步配置，不需要手动折腾太多。

结合我的排查经验，给大家几个针对新版集成的排查方向：

方向1：确认集群命名空间与项目的关联状态 #

因为免费账户只能关联一个通配符范围的集群，要先去GitLab的「项目 → 设置 → Kubernetes」里检查：项目对应的命名空间是否已被正确创建/关联，且状态显示正常。如果命名空间没同步成功，GitLab就没法给CI作业注入对应变量。

方向2：验证Runner标签与CI作业的匹配性 #

虽然Runner能正常跑任务，但要确认这个Runner是和你关联的K8s集群绑定的（而非公共共享Runner）。可以在.gitlab-ci.yml里明确指定标签，确保作业分配到正确的Runner上：

deploy-to-k8s:
  stage: deploy
  tags:
    - kubernetes-cluster
  script:
    - echo "检查K8s变量：$KUBECONFIG"

只有匹配到关联K8s集群的Runner，GitLab才会自动注入相关环境变量。

方向3：查看集群集成同步日志 #

去GitLab的「集群管理 → 你的集群 → 日志」页面，检查有没有同步失败的记录——比如GitLab和K8s集群之间的网络不通、权限不足，都会导致变量注入失败，日志里一般会有明确的报错提示。

方向4：检查项目CI/CD权限配置 #

最后确认下项目的CI/CD权限：在「项目 → 设置 → CI/CD」里，确保「Kubernetes integration」的权限是开启状态，且允许该项目使用已关联的集群。

目前我还在针对自己的场景进一步排查，但这几个方向应该能帮到遇到同样问题的朋友，尤其要注意区分新旧版集成逻辑，别盲目套用旧方案。

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