Kubernetes 上的 GitLab + ArgoCD 实践（二）：使用自建 GitLab Runner 完善 CI 流程

老年DBA2025-10-27 15:35

文章目录

从共享 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 自动同步。
bash 复制代码 
┌────────────┐      ┌─────────────────────┐      ┌───────────────┐     
│ 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创建

  1. 进入gitops-repo项目 -> 设置 -> CI/CD -> Runner，点击"新建项目Runner"，填写信息（比如标签、描述等）

  2. GitLab 默认只会把 Job 分配给标签匹配的 Runner，这里将runner 标签（Tags)设置为k8s

  3. 然后点击"创建"，就会生成一个令牌。这个令牌是专门给这个预先创建的Runner使用的。

    请记下下图中--token部分显示的"glrt-"开头的token,之后在k8s集群设置时要使用

  4. 检视runner

    页面上虽然已经能看到 Runner，但它会显示为灰色，那是因为它还没真正"上线"。换句话说，GitLab 只是记录了 Runner 的配置，还没有收到来自实际执行节点的注册与心跳信号，因此暂时无法投入工作。

Gitlab-runner 设置

gitlab-runner安装有多种方式，但推荐使用用 Helm：

首先添加Helm 仓库，并更新本地 Helm 仓库缓存

增加repo并update

bash 复制代码 
helm repo add gitlab https://charts.gitlab.io
helm repo update

安装

  1. 创建namespace
bash 复制代码 
kubectl create namespace gitlab-runner
  1. 安装gitlab-runner
  • glrt-xxxxx：换成你在 GitLab project(项目)中新建 Runner 得到的 认证 token
  • runners.executor=kubernetes：关键，告诉 Runner job 要跑在 K8s Pod 中
  • tags: 指定为k8s，与先前在gitlab上建立的runner tags保持一致
bash 复制代码 
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 后，可以通过以下指令查看当前命名空间内的所有资源：

bash 复制代码 
 kubectl get all -n gitlab-runner

你会看到 Helm 已经为 Runner 创建好一整套运行所需的组件，其中最核心的是一个 Deployment，以及由它管理的 Runner Pod。

bash 复制代码 
NAME                                                    READY   STATUS    RESTAR                                                                                        TS       AGE
pod/demo-project-runner-gitlab-runner-c664b4cc5-zb6lg   1/1     Running   29 (30                                                                                        m ago)   17h

NAME                                                READY   UP-TO-DATE   AVAILAB                                                                                        LE   AGE
deployment.apps/demo-project-runner-gitlab-runner   1/1     1            1                                                                                                   17h

NAME                                                          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)   17h

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/demo-project-runner-gitlab-runner   1/1     1            1           17h

NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/demo-project-runner-gitlab-runner-c664b4cc5   1         1         1       17h

同时回到gitlab,将会看到gitlab上的runner已经被点亮

CI过程

Clone repo

bash 复制代码 
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 的方式，不需要额外修改。

bash 复制代码 
stages:
  - build
  - update-gitops

variables:
  IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
 
build-image:
  stage: build
  tags:
    - k8s
  image: 
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  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-gitops
  tags:
    - k8s
  image: alpine:3.18
  before_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:main
  only:
    - main

push repo

bash 复制代码 
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 流程》

让我们继续把自动化的"最后一公里"走到底

相关推荐
老朋友此林4 小时前
一文速通k8s基础概念原理Kubernetes
云原生·容器·kubernetes
VermiliEiz7 小时前
k8s的calico出现ipset报错解决方法
云原生·容器·kubernetes
ydswin9 小时前
K8s注解的指令模式：元数据如何控制集群行为
kubernetes
做运维的阿瑞10 小时前
Kubernetes网络通信与Pod基础详解：从架构图看K8s核心组件
云原生·容器·kubernetes
sunyanchun11 小时前
gitlab上传新仓库，保留原仓库提交记录，原仓库远程地址已经失效，只有本机还有提交记录
gitlab·1024程序员节
Dreamboat-L11 小时前
从零开始在云服务器上部署Gitlab
运维·服务器·gitlab
丈剑走天涯1 天前
kubernetes 源码编译（ubuntu） kubernetes-1.34.1
java·容器·kubernetes·1024程序员节
睡不醒的猪儿2 天前
k8s部署自动化工具jenkins
云原生·kubernetes·自动化·jenkins
KevinPedri2 天前
测试：uk8s创建监控和告警同步飞书等渠道
docker·kubernetes·云计算·1024程序员节
热门推荐
01GitHub 镜像站点02BongoCat - 跨平台键盘猫动画工具03UV安装并设置国内源04GitLab 零基础入门指南：从安装到项目管理全流程05Linux下V2Ray安装配置指南06Burp与其他安全工具联动及代理设置教程07jdk21下载、安装（Windows、Linux、macOS）08NVIDIA显卡驱动、CUDA、cuDNN 和 TensorRT 版本匹配指南09Labelme从安装到标注：零基础完整指南10HTML5 敲击乐：从零搭建交互式前端音乐项目