GitLab Runner部署实践：物理机、Docker与Kubernetes方案详解

1. GitLab CI Runner部署核心思路

在现代化开发流程中，持续集成（CI）已成为团队协作的标配基础设施。作为GitLab生态的核心组件，GitLab Runner承担着流水线任务的实际执行工作。不同于简单的工具安装，Runner部署需要综合考虑执行环境、资源隔离、网络策略等多维度因素。

我经历过从单机Docker Runner到Kubernetes集群的完整演进路径，也踩过资源竞争、缓存失效等典型坑位。本文将基于生产级实践，详解三种典型场景下的部署方案：本地物理机部署、Docker容器化部署、Kubernetes集群部署，每种方案都附带性能调优参数和避坑指南。

2. 环境准备与方案选型

2.1 硬件资源规划

Runner的性能直接影响流水线执行效率。根据我们的压力测试数据：

• CPU：每个并发任务需要至少1个物理核心（非超线程）
• 内存：基础服务消耗约500MB，每个Java构建任务需预留2-4GB
• 磁盘：推荐SSD存储，机械硬盘会使缓存效率下降60%以上

实测案例：某中型项目（日均200次构建）的资源配置：

bash复制# 推荐配置
concurrent = 8
resource_class = "large"  # 4核8G

2.2 网络拓扑设计

企业级部署常见两种网络模式：

1. 出站代理模式（适合严格管控环境）：

   ini复制[runners.docker]
     http_proxy = "http://proxy.example.com:8080"
     no_proxy = "internal.net,172.16.0.0/12"
   

2. 直接连通模式（低延迟场景）：

   bash复制iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
   

关键提示：当使用Docker executor时，必须开放对registry.gitlab.com的访问权限，否则会因镜像拉取失败导致任务卡死。

3. 三种主流部署方案详解

3.1 物理机直接部署

适用场景：

• 需要直接访问宿主机硬件（如GPU加速）
• 对IO性能要求极高的编译任务

安装步骤：

bash复制# 添加官方源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# 安装特定版本（推荐锁定版本）
sudo apt-get install gitlab-runner=15.11.0

# 注册Runner
sudo gitlab-runner register \
  --url "https://gitlab.com/" \
  --registration-token "PROJECT_REGISTRATION_TOKEN" \
  --executor "shell" \
  --tag-list "physical-machine,high-io"

性能调优：

ini复制# /etc/gitlab-runner/config.toml
[[runners]]
  limit = 10 # 最大并发任务数
  output_limit = 4096 # 日志输出限制(MB)
  [runners.cache]
    Type = "s3"
    Path = "gitlab_runner_cache"
    Shared = true

3.2 Docker容器化部署

优势：

• 环境隔离彻底
• 快速水平扩展

典型docker-compose配置：

yaml复制version: '3'
services:
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./config:/etc/gitlab-runner
    environment:
      CI_SERVER_URL: "https://gitlab.com"
      REGISTRATION_TOKEN: "PROJECT_TOKEN"
      RUNNER_EXECUTOR: "docker"
      DOCKER_IMAGE: "alpine:latest"

关键参数说明：

• privileged=true：允许在容器中运行Docker（DinD模式）
• shm_size=2gb：解决大型测试套件内存不足问题

3.3 Kubernetes集群部署

Helm Chart配置要点：

bash复制helm upgrade --install gitlab-runner \
  -n gitlab-runner \
  --set runnerRegistrationToken="PROJECT_TOKEN" \
  --set rbac.create=true \
  --set runners.config="[[runners]]\n  [runners.kubernetes]\n    namespace = \"{{.Release.Namespace}}\"\n    cpu_limit = \"2\"\n    memory_limit = \"4Gi\"\n" \
  gitlab/gitlab-runner

Pod资源模板示例：

yaml复制# values.yaml
runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{.Release.Namespace}}"
        service_account = "gitlab-runner"
        [runners.kubernetes.pod_annotations]
          cluster-autoscaler.kubernetes.io/safe-to-evict = "false"
        [runners.kubernetes.pod_resources]
          limits = { cpu = "2000m", memory = "4Gi" }
          requests = { cpu = "500m", memory = "1Gi" }

4. 高级配置与优化策略

4.1 分布式缓存方案

S3缓存配置示例：

toml复制[runners.cache]
  Type = "s3"
  Path = "gitlab_runner_cache"
  Shared = true
  [runners.cache.s3]
    ServerAddress = "s3.amazonaws.com"
    BucketName = "my-runner-cache-bucket"
    BucketLocation = "us-east-1"
    Insecure = false

本地缓存清理策略：

bash复制# 添加cron定时任务
0 3 * * * find /var/lib/gitlab-runner/cache -type f -mtime +7 -delete

4.2 安全加固措施

1. RBAC最小权限原则：

   yaml复制# Kubernetes角色定义
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["create", "delete", "get", "list"]
   

2. Docker socket代理（替代直接挂载/var/run/docker.sock）：

   dockerfile复制FROM quay.io/jpetazzo/dind
   CMD ["dockerd-entrypoint.sh", "--host", "tcp://0.0.0.0:2375", "--tlsverify=false"]
   

5. 故障排查手册

5.1 常见错误代码速查

5.2 日志分析技巧

查看实时日志：

bash复制journalctl -u gitlab-runner -f -n 100

关键日志线索：

• WARNING: Failed to process runner → 通常需要重启服务
• ERROR: Preparation failed → 检查executor配置
• WARNING: API is unreachable → 网络连通性问题

6. 性能基准测试数据

以下是我们对三种部署方式的压测结果（基于8核16G环境）：

实际部署时建议：

• 开发环境：Docker方案（快速部署）
• 生产环境：Kubernetes方案（弹性伸缩）
• 特殊需求：物理机方案（极致性能）