GitLab集成AWS Kubernetes集群后，如何部署镜像到指定命名空间？

没问题，要实现把镜像分别部署到Kubernetes的development和production命名空间，咱们主要需要在GitLab CI/CD配置和Kubernetes权限这两个层面做调整，下面一步步来：

一、先搞定Kubernetes层面的权限配置 #

首先得确保GitLab用来执行部署的ServiceAccount有这两个新命名空间的操作权限——毕竟之前你只配置了default命名空间的权限对吧？

• 如果你已经有了GitLab对应的ServiceAccount（比如叫gitlab-deployer），只需要给它添加新命名空间的角色绑定：
  先创建gitlab-deployer-dev-rolebinding.yaml文件：

  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: gitlab-deployer
    namespace: development
  subjects:
  - kind: ServiceAccount
    name: gitlab-deployer  # 替换成你实际的GitLab服务账号名
    namespace: default  # 如果ServiceAccount在default命名空间的话
  roleRef:
    kind: ClusterRole
    name: edit  # 这个角色足够处理部署相关操作，要是需要更严格权限可以自定义Role
    apiGroup: rbac.authorization.k8s.io
  

  复制一份改名为gitlab-deployer-prod-rolebinding.yaml，把namespace字段改成production，然后应用这两个文件：

  kubectl apply -f gitlab-deployer-dev-rolebinding.yaml
  kubectl apply -f gitlab-deployer-prod-rolebinding.yaml
  

• 要是还没创建GitLab的ServiceAccount，先在default命名空间创建它，再给每个目标命名空间绑定对应的Role/ClusterRole，确保它有创建Deployment、Service等资源的权限。

二、修改GitLab CI/CD配置（.gitlab-ci.yml） #

接下来要在CI流程里加入环境分支或变量控制，让不同的触发条件对应不同的命名空间，这里给你两种常用方案：

方案1：按分支自动部署（推荐，适合常规开发流程） #

比如让main分支自动部署到production，dev分支自动部署到development，修改你的.gitlab-ci.yml：

stages:
  - build
  - deploy

build-image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  only:
    - main
    - dev

deploy-dev:
  stage: deploy
  script:
    # 如果你是用kubectl直接更新镜像
    - kubectl set image deployment/your-app-name your-app-container=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n development
    # 要是用Helm的话，换成下面这句
    # helm upgrade your-app ./charts/your-app -n development --set image.tag=$CI_COMMIT_SHORT_SHA
  only:
    - dev
  environment:
    name: development
    url: https://dev.your-app.com  # 替换成你的开发环境访问地址

deploy-prod:
  stage: deploy
  script:
    - kubectl set image deployment/your-app-name your-app-container=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n production
    # Helm版本：helm upgrade your-app ./charts/your-app -n production --set image.tag=$CI_COMMIT_SHORT_SHA
  only:
    - main
  environment:
    name: production
    url: https://prod.your-app.com
  when: manual  # 生产环境强烈建议加手动确认，防止误部署

解释：通过only字段指定分支触发对应的部署任务，environment字段能让GitLab跟踪每个环境的部署状态和历史，生产环境的when: manual能避免代码合并后自动部署到生产的风险。

方案2：用GitLab变量手动选择部署环境 #

如果需要灵活选择部署目标（比如临时把测试镜像部署到生产验证），可以用变量控制：

deploy:
  stage: deploy
  script:
    - |
      if [ "$DEPLOY_ENV" == "development" ]; then
        NAMESPACE="development"
      elif [ "$DEPLOY_ENV" == "production" ]; then
        NAMESPACE="production"
      else
        echo "Invalid DEPLOY_ENV value, must be development or production"
        exit 1
      fi
    - kubectl set image deployment/your-app-name your-app-container=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -n $NAMESPACE
  variables:
    DEPLOY_ENV: "development"  # 设置默认值为开发环境
  when: manual

之后你可以在GitLab项目的Settings -> CI/CD -> Variables里添加DEPLOY_ENV变量，或者在触发流水线时手动选择这个变量的值。

三、调整Kubernetes资源文件（可选，如果你用yaml文件全量部署） #

要是你的部署是用kubectl apply整个yaml文件，而不是只更新镜像，那可以把命名空间参数化，用envsubst或者Helm这类模板工具：
比如创建deployment-template.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-app-name
  namespace: ${NAMESPACE}  # 用变量占位符
spec:
  replicas: ${REPLICAS}
  template:
    spec:
      containers:
      - name: your-app-container
        image: ${IMAGE_TAG}
        # 其他容器配置...

然后在CI脚本里替换变量并部署：

# 替换变量并部署
envsubst < deployment-template.yaml | kubectl apply -f -

其中NAMESPACE、REPLICAS、IMAGE_TAG都可以通过GitLab CI变量传递。

四、验证部署 #

• 触发对应分支的流水线（或者手动触发选择环境），然后在Kubernetes里检查：

kubectl get pods -n development
kubectl get pods -n production

• 也可以在GitLab的CI/CD -> Environments页面查看每个环境的部署状态和历史记录。

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