为何GitLab AutoDevOps中KUBE_NAMESPACE变量不再自动设置？

安全阿岳

2026-8-20

问题分析与解决步骤

关于Runner重启是否为诱因

服务器重启生成新Runner确实可能是问题根源——Kubernetes Executor类型的Runner需要和GitLab项目的Kubernetes集群正确绑定，新生成的Runner如果只是完成了基础注册，未关联目标集群或配置缺失，会导致GitLab无法自动注入KUBE_NAMESPACE等集群相关变量，最终触发默认使用default命名空间的逻辑。

恢复`KUBE_NAMESPACE`自动赋值的排查步骤

1. 检查Runner的集群绑定与配置

进入项目「设置」→「CI/CD」→「Runners」，找到带nut标签的Runner，确认它是否关联了目标Kubernetes集群。如果是新生成的Runner，大概率未完成集群绑定，导致GitLab无法传递命名空间变量。
查看Runner的配置详情，确认kubernetes段的namespace字段是否被硬编码为default——如果Runner强制指定了命名空间，会直接覆盖GitLab自动生成的值。

2. 验证项目的集群集成状态

进入项目「基础设施」→「Kubernetes集群」，确认目标集群状态正常，且已启用AutoDevOps集成（检查是否勾选「启用AutoDevOps」，命名空间生成规则保持默认）。
进入「设置」→「CI/CD」→「变量」，检查是否存在手动设置的KUBE_NAMESPACE变量——如果有，会覆盖自动生成的值，需删除该变量。

3. 调试AutoDevOps核心变量传递

修改你的测试Job，打印生成命名空间依赖的基础变量，确认GitLab是否正常传递这些值：

env build:
  extends: .auto-deploy
  stage: build
  tags: 
    - nut
  script:
    - echo "项目ID: $CI_PROJECT_ID"
    - echo "环境标识: $CI_ENVIRONMENT_SLUG"
    - env | grep KUBE_
    - auto-deploy ensure_namespace
  environment:
    name: nut/staging
    url: https://$CI_PROJECT_PATH_SLUG.nut.$KUBE_INGRESS_BASE_DOMAIN

如果CI_PROJECT_ID、CI_ENVIRONMENT_SLUG正常输出，说明GitLab已传递基础信息，问题出在auto-deploy脚本逻辑；如果这些变量为空，说明Runner或集群集成存在配置问题。

4. 重新注册并绑定Runner

如果确认新Runner是问题核心，删除无效Runner后重新注册，确保注册时关联正确集群：

gitlab-runner register \
  --url "https://你的GitLab实例地址/" \
  --registration-token "你的项目注册令牌" \
  --executor "kubernetes" \
  --description "Nut Kubernetes Runner" \
  --tag-list "nut" \
  --kubernetes-service-account-name="gitlab-runner" \
  --kubernetes-pull-policy="if-not-present"

注意：注册时的--kubernetes-namespace是Runner默认命名空间，GitLab AutoDevOps会自动覆盖它，无需手动指定为项目专属值。

5. 检查AutoDevOps模板版本

不同版本的.auto-deploy模板，命名空间生成逻辑可能存在差异。进入项目「CI/CD」→「编辑器」，确认extends的.auto-deploy来自官方模板，且与当前GitLab版本兼容。

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