Kubernetes 上的 GitLab + ArgoCD 实践（二）：使用自建 GitLab Runner 完善 CI 流程
文章目录
- 从共享 Runner 到自建 Runner
- CI流程
- GitLab Runner
- Gitlab-runner创建
- Gitlab-runner 设置
- 增加repo并update
- 安装
- 验证gitlab-runner安装
- CI过程
- Clone repo
- 微调CI文件
- push repo
- 验证
- 结语：CI 是起点，不是终点
从共享 Runner 到自建 Runner
在上篇文章Kubernetes 上的 GitLab + ArgoCD 实践（一）：实现基础 CI/CD 流程
中，我们已经将CI的流程大致走了一遍，不过当时使用的是 GitLab 已有的 Runner（通常是 Shared Runner 或 GitLab 托管 Runner）。这种方式虽然入门简单，但在真实生产环境中，我们往往需要更高的资源掌控权，例如：
- 构建镜像时能直接访问 Kubernetes 集群内部服务
- 避免企业内部代码或镜像流量暴露到外网
- 根据项目规模灵活扩容 Runner 资源
- 支持 GPU、ARM 等特殊编译环境
- 可自定义缓存、网络、安全策略
所以，这一篇文章我将在上篇文章的基础上进行微调，所以，这一篇文章我将在上篇文章的基础上进行微调，实现自建 Runner 与 GitLab 项目之间的对接，并再次完成镜像构建与推送的完整 CI 流程，使 CI/CD 流程真正做到在自己掌控的基础设施上稳定运行。
CI流程
上一篇文章中的CI流程：
- GitLab 执行 CI → 构建镜像 → 更新 gitops repo → ArgoCD 自动同步。
本篇文章中的CI流程： - 自建 GitLab Runner 在本地/K8s 中执行 CI → 构建镜像（使用 Kaniko） → 更新 gitops repo → ArgoCD 自动同步。
┌────────────┐ ┌─────────────────────┐ ┌───────────────┐
│ Developer │ ---> │ GitLab Server │ ---> │ GitLab Runner │
│ (push) │ │ (trigger pipeline) │ │ (build+update)│
└────────────┘ └─────────────────────┘ └───────────────┘│▼┌─────────────┐│ ArgoCD ││ syncs to k8s│└─────────────┘GitLab Runner
GitLab Runner 是用于在 GitLab 平台的 CI/CD 流水线中执行作业（job）的组件。
GitLab Runner 充当代理，将 GitLab 项目与能够运行作业的环境连接起来，这些环境可以是物理机器、虚拟机，或者 Docker 容器。
一个简短的例子：
执行job：GitLab Runner 负责执行在 job pipeline 中 定义的任务。这可以包括代码编译、自动化测试、application 交付，或软件开发周期中所需的其他任务。
想了解更详细内容，可以查看 GitLab 官方文档。
Gitlab-runner创建
-
进入gitops-repo项目 -> 设置 -> CI/CD -> Runner，点击“新建项目Runner”，填写信息（比如标签、描述等）
-
GitLab 默认只会把 Job 分配给标签匹配的 Runner，这里将runner 标签（Tags)设置为k8s
-
然后点击“创建”，就会生成一个令牌。这个令牌是专门给这个预先创建的Runner使用的。
请记下下图中–token部分显示的"glrt-"开头的token,之后在k8s集群设置时要使用
-
检视runner
页面上虽然已经能看到 Runner，但它会显示为灰色，那是因为它还没真正“上线”。换句话说，GitLab 只是记录了 Runner 的配置，还没有收到来自实际执行节点的注册与心跳信号，因此暂时无法投入工作。
Gitlab-runner 设置
gitlab-runner安装有多种方式，但推荐使用用 Helm：
首先添加Helm 仓库，并更新本地 Helm 仓库缓存
增加repo并update
helm repo add gitlab https://charts.gitlab.io
helm repo update
安装
- 创建namespace
kubectl create namespace gitlab-runner
- 安装gitlab-runner
- glrt-xxxxx：换成你在 GitLab project(项目)中新建 Runner 得到的 认证 token
- runners.executor=kubernetes：关键，告诉 Runner job 要跑在 K8s Pod 中
- tags: 指定为k8s，与先前在gitlab上建立的runner tags保持一致
helm install demo-project-runner gitlab/gitlab-runner \--namespace gitlab-runner \--create-namespace \--set gitlabUrl=https://gitlab.com \--set runnerRegistrationToken="glrt-g2_Ae6iUjsZ6yUC763vZ0G86MQpwOjE4cTBlcgp0OjMKdTppN3FuMxg.01.1j08wwxur" \--set runners.executor=kubernetes \--set rbac.create=true \--set serviceAccount.create=true \--set serviceAccount.name=gitlab-runner \--set runners.requestConcurrency=4 \--set runners.tags="k8s"
验证gitlab-runner安装
使用 Helm 安装完成 GitLab Runner 后，可以通过以下指令查看当前命名空间内的所有资源：
kubectl get all -n gitlab-runner
你会看到 Helm 已经为 Runner 创建好一整套运行所需的组件，其中最核心的是一个 Deployment，以及由它管理的 Runner Pod。
NAME READY STATUS RESTAR TS AGE
pod/demo-project-runner-gitlab-runner-c664b4cc5-zb6lg 1/1 Running 29 (30 m ago) 17hNAME READY UP-TO-DATE AVAILAB LE AGE
deployment.apps/demo-project-runner-gitlab-runner 1/1 1 1 17hNAME DESIRED CURRENT READY AGE
replicaset.apps/demo-project-runner-gitlab-runner-c664b4cc5 1 1 1 17h
root@k8sm01:~# kubectl get all -n gitlab-runner
NAME READY STATUS RESTARTS AGE
pod/demo-project-runner-gitlab-runner-c664b4cc5-zb6lg 1/1 Running 29 (30m ago) 17hNAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/demo-project-runner-gitlab-runner 1/1 1 1 17hNAME DESIRED CURRENT READY AGE
replicaset.apps/demo-project-runner-gitlab-runner-c664b4cc5 1 1 1 17h同时回到gitlab,将会看到gitlab上的runner已经被点亮
CI过程
Clone repo
mkdir -p /root/demo-cicd-project/app-repo
cd /root/demo-cicd-project/app-repo
git clone git@gitlab.com:mygroup/app-repo.git
微调CI文件
上一章中使用的 .gitlab-ci.yml 基本可以直接沿用。这里只做少量调整：为相关 Job 增加 tags，使它们能够被我们自建的 Runner 正确接手执行。镜像构建部分依旧沿用 Kaniko 的方式，不需要额外修改。
stages:- build- update-gitopsvariables:IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"build-image:stage: buildtags:- k8simage: name: gcr.io/kaniko-project/executor:debugentrypoint: [""]variables:DOCKER_AUTH_CONFIG: "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}"script:- | /kaniko/executor \--dockerfile=Dockerfile \--context=$CI_PROJECT_DIR \--destination=${IMAGE} # because gcr.io/kaniko-project/executor is a light image without sh shell, so it is changed to "command mode" instead of "script mode"#command:# - /kaniko/executor # - --dockerfile=Dockerfile # - --context=$CI_PROJECT_DIR # - --destination=${IMAGE}update-gitops:stage: update-gitopstags:- k8simage: alpine:3.18before_script:- apk add --no-cache git yq- git config --global user.email "ci@mydomain.com"- git config --global user.name "gitlab-ci"script:- git clone https://oauth2:${GITOPS_REPO_TOKEN}@${GITOPS_REPO_URL#https://} gitops#- git clone https://$GITOPS_REPO_USER:$GITOPS_REPO_TOKEN@${GITOPS_REPO_URL#https://} gitops- cd gitops- yq e '.spec.template.spec.containers[0].image = strenv(IMAGE)' -i ./myapp/deployment.yaml- git add .- git commit -m "Update image to $IMAGE"- git push origin HEAD:mainonly:- main
push repo
git add .
git commit -m "build image by gitlab-runner"
git push origin main
验证
当完成push后，应该会触发CI完成.gitlab-runner.yml文件中定义的build与update-gitops阶段
job状态显示”job succeeded
进入project对应的repo将会看到已经构建好的image
结语：CI 是起点，不是终点
通过本篇的实践，我们已经把 GitLab 自建 Runner 引入到 Kubernetes 中，并成功运行了完整的持续集成流程。现在，每一次代码提交都会触发自动构建、测试和反馈，让质量问题更早暴露，开发协作也不再依赖人工提醒。这种稳定、可重复的 CI 机制，是现代软件交付体系最重要的基石。
当然，CI 只是自动化之旅的一半。构建产物仍需要被可靠地推向各个环境，让应用真正落地到用户侧。也就是说，只有继续推进持续交付（CD），我们才能打通从代码到上线的全链路。下一篇将正式从 CI 扩展到 CD，带你使用 GitLab 与 ArgoCD，将部署能力纳入自动化体系之内，逐步实现 Kubernetes 上的 GitOps 交付流程。
下一篇敬请期待：
《Kubernetes 上的 GitLab + ArgoCD 实践（三）：使用 ArgoCD 打通 CD 流程》
让我们继续把自动化的“最后一公里”走到底