GitLab CI集成Kubernetes命名空间管理的核心是精准定位与权限管控，而非创建命名空间：由管理员预划命名空间并绑定最小权限ServiceAccount；CI通过环境变量（如K8S_NAMESPACE）配合-n参数或上下文切换，在指定命名空间中安全执行部署操作；支持GitOps工具实现声明式同步。
GitLab CI 集成 Kubernetes 命名空间管理，核心不是让 GitLab “管理”命名空间本身，而是让 CI 流水线在指定命名空间中安全、可控地执行部署、清理等操作。命名空间的创建和权限划分通常由集群管理员提前完成，CI 侧的关键在于：精准定位目标命名空间、使用对应凭据、按需隔离资源。以下是实际落地的关键环节：
明确命名空间归属与权限边界
命名空间是 Kubernetes 的逻辑隔离单元，CI 流水线不能随意创建或删除它（除非有 cluster-admin 权限，这不推荐）。更合理的做法是：
- 由运维或平台团队统一规划命名空间，例如按环境（
dev、staging、prod）或项目（my-app-dev、my-app-prod）划分； - 为每个命名空间创建专用 ServiceAccount，并绑定最小必要权限的 Role/RoleBinding（如仅允许在该命名空间内操作 Deployment、Service、Secret）；
- 避免复用 default ServiceAccount，防止权限扩散。
在 .gitlab-ci.yml 中指定命名空间上下文
流水线执行 kubectl 命令时，必须明确作用域。常见方式有两种：
-
通过 kubectl config use-context：如果使用 GitLab Agent 或 kubeconfig 文件，需在
before_script中切换上下文，其中 context 名通常包含命名空间信息（如my-group/my-project:staging）； -
显式指定 -n 参数：所有 kubectl 操作加
-n <namespace>，例如：kubectl apply -f deployment.yaml -n staging； - 建议将命名空间名设为 CI/CD 变量（如
K8S_NAMESPACE: staging），并在脚本中引用-n $K8S_NAMESPACE，便于多环境复用同一份流水线配置。
利用变量与环境隔离不同命名空间
GitLab 支持按环境（Environment）保护变量和触发阶段，这是实现命名空间级隔离的实用手段：
- 为每个环境（如
staging、production）创建对应 Environment，并设置保护规则（如仅允许特定分支或人员部署）； - 将命名空间名、ServiceAccount Token、镜像仓库地址等敏感信息，作为“受保护”且“仅限该环境”的 CI/CD 变量；
- 在 job 中通过
environment: name: staging关联，确保部署命令只影响 staging 命名空间，且不会被 dev 分支误触发。
配合 Flux 或 Argo CD 实现声明式命名空间同步
若采用 GitOps 模式（如 Flux），命名空间本身也可作为 Git 中的一等资源管理：
- 在 Git 仓库中定义
Namespace资源 YAML（如namespaces/staging.yaml），并纳入 Flux 的监控路径； - Flux 会自动在集群中创建/更新该命名空间，并同步其下所有资源（Deployment、Ingress 等）；
- GitLab CI 不再直接执行 kubectl create ns，而是提交变更到 Git，由 Flux 异步同步——这样更符合声明式原则，也便于审计和回滚。
命名空间管理本质是权限与范围的控制问题。GitLab CI 的角色是“精准执行者”，而非“创建者”。把命名空间生命周期交给集群治理流程，把部署动作限定在预授权范围内，才能既安全又高效。
