如何配置CI/CD使用GitLab Agent替代基于证书的Kubernetes集成

一、调整.gitlab-ci.yml配置 #

要让CI/CD切换到GitLab Agent，需移除旧的证书认证逻辑，添加Agent的连接配置：

1. 清理旧配置

   • 删除项目CI变量中与旧Kubernetes证书集成相关的内容，比如KUBECONFIG、KUBE_CA_PEM、KUBE_TOKEN等。
   • 移除.gitlab-ci.yml里所有依赖旧集群认证的代码，比如之前用的kubernetes模板、硬编码的证书路径等。

2. 添加Agent连接逻辑
   在需要操作Kubernetes的CI作业中，配置kubectl通过GitLab Agent完成认证与集群连接。示例配置如下：

   deploy_to_gke:
     stage: deploy
     image: bitnami/kubectl:latest
     script:
       # 配置kubectl使用GitLab Agent
       - kubectl config set-cluster gke-agent-cluster --server=https://kubernetes-agent.gitlab.com:443
       - kubectl config set-context gke-agent-context --cluster=gke-agent-cluster
       - kubectl config use-context gke-agent-context
       - kubectl config set-credentials gitlab-agent --token="$CI_JOB_TOKEN"
       # 执行部署操作
       - kubectl apply -f ./k8s/manifests/
       - kubectl rollout status deployment/my-app
     rules:
       - if: $CI_COMMIT_BRANCH == "main"
   

   注：CI_JOB_TOKEN是GitLab自动注入的变量，用于向Agent发起认证，无需手动配置。

二、验证是否通过Agent执行 #

可以通过以下方式确认CI作业已切换到Agent：

1. 查看CI作业日志
   运行流水线后，检查作业日志：

   • 可临时在script中添加kubectl config view命令，确认集群地址为https://kubernetes-agent.gitlab.com:443，凭证条目使用的是CI_JOB_TOKEN。
   • 若日志中无旧证书相关加载信息，且部署命令正常执行，说明已切换成功。

2. 查看Agent Pod日志
   在GKE集群中找到GitLab Agent的Pod，查看其运行日志：

   # 替换为你的Agent命名空间和Pod名称
   kubectl logs -n gitlab-agent gitlab-agent-xxxxxx-xxxxx
   

   日志中会显示来自CI作业的认证请求和集群操作记录，比如包含你的项目路径、CI作业ID的条目。

3. 临时禁用旧配置测试
   移除所有旧的Kubernetes证书相关变量或配置，重新运行流水线。如果流水线仍能正常完成部署，说明已完全依赖GitLab Agent；若出现认证错误，则需排查残留的旧配置。

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