GitLab Runner с Kubernetes executor: масштабируемый CI/CD

Стандартный GitLab Runner с shell или docker executor работает на одном сервере — количество параллельных задач ограничено его ресурсами. Kubernetes executor запускает каждую CI/CD-задачу в отдельном поде кластера: под создаётся при старте задачи и удаляется по завершении. Это даёт:

• Автомасштабирование: 100 параллельных пайплайнов потребляют ресурсы только во время выполнения
• Изоляция: каждая задача работает в чистом окружении без артефактов от предыдущих сборок
• Гибкость: разные задачи используют разные образы — Java 17, Node 20, Python 3.12 — без предустановки на хосте
• Экономия: в облаке (GKE, YMK) поды используют ресурсы кластера, масштабируемого через Cluster Autoscaler

В этом руководстве развернём GitLab Runner в Kubernetes через Helm, настроим кеширование, секреты, лимиты ресурсов и оптимизируем пайплайны.

Добавляем Helm-репозиторий GitLab:

helm repo add gitlab https://charts.gitlab.io
helm repo update

Создаём файл значений values.yaml:

gitlabUrl: https://gitlab.company.ru/
runnerToken: "glrt-xxxxxxxxxxxxxxxxxxxx"

rbac:
  create: true
  clusterWideAccess: false

runners:
  config: |
    [[runners]]
      name = "k8s-runner"
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "gitlab-ci"
        image = "ubuntu:22.04"
        privileged = false
        cpu_limit = "2"
        cpu_request = "500m"
        memory_limit = "4Gi"
        memory_request = "1Gi"
        service_cpu_limit = "1"
        service_memory_limit = "2Gi"
        poll_timeout = 600
        [runners.kubernetes.pod_annotations]
          "cluster-autoscaler.kubernetes.io/safe-to-evict" = "true"
        [runners.kubernetes.node_selector]
          "workload" = "ci"
        [runners.kubernetes.pod_labels]
          "app" = "gitlab-ci-job"

Деплоим:

kubectl create namespace gitlab-ci
helm install gitlab-runner gitlab/gitlab-runner \
    --namespace gitlab-ci \
    -f values.yaml

Без кеша каждая задача скачивает зависимости заново (npm install, pip install, mvn dependency:resolve). Настроим кеширование через S3-совместимое хранилище:

# В values.yaml добавляем секцию кеша
runners:
  cache:
    cacheType: s3
    s3BucketName: gitlab-ci-cache
    s3BucketLocation: ru-central1
    s3ServerAddress: storage.yandexcloud.net
    secretName: s3-cache-secret

Создаём секрет:

kubectl create secret generic s3-cache-secret \
    --namespace gitlab-ci \
    --from-literal=accesskey="YCAJE..." \
    --from-literal=secretkey="YCP..."

В .gitlab-ci.yml используем кеш:

build:
  stage: build
  image: node:20-alpine
  tags: [k8s]
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run build

Кеш сохраняется между запусками пайплайна для одной ветки. Первый запуск загружает зависимости, последующие используют кеш.

Сборка образов в Kubernetes — нетривиальная задача, так как privileged-режим создаёт риски безопасности. Безопасные альтернативы:

Для передачи секретов (API-ключи, пароли БД) в CI-задачи используйте Kubernetes secrets через конфигурацию Runner:

# В values.yaml
runners:
  config: |
    [[runners]]
      executor = "kubernetes"
      [runners.kubernetes]
        namespace = "gitlab-ci"
        [runners.kubernetes.pod_security_context]
          run_as_non_root = true
          run_as_user = 1000
        [[runners.kubernetes.volumes.secret]]
          name = "app-secrets"
          mount_path = "/secrets"
          read_only = true

Создаём секрет в кластере:

kubectl create secret generic app-secrets \
    --namespace gitlab-ci \
    --from-literal=DB_PASSWORD="p@ssw0rd" \
    --from-literal=API_KEY="sk-xxx"

В задаче секреты доступны как файлы в /secrets/. Также можно использовать GitLab CI/CD Variables (Settings → CI/CD → Variables) — они передаются как переменные окружения в каждую задачу.

Несколько практик для ускорения CI/CD в Kubernetes:

Финальный этап пайплайна — деплой приложения в тот же или другой кластер:

deploy-production:
  stage: deploy
  tags: [k8s]
  image: bitnami/kubectl:1.29
  environment:
    name: production
    url: https://app.company.ru
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  script:
    - kubectl config use-context $KUBE_CONTEXT
    - kubectl set image deployment/myapp \
        app=${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHA} \
        --namespace production
    - kubectl rollout status deployment/myapp \
        --namespace production --timeout=300s

Для Helm-деплоев:

deploy-helm:
  stage: deploy
  tags: [k8s]
  image: alpine/helm:3.14
  script:
    - helm upgrade --install myapp ./chart \
        --namespace production \
        --set image.tag=${CI_COMMIT_SHA} \
        --set replicas=3 \
        --wait --timeout 5m