GitLab Runners на Kubernetes: оптимизация затрат в масштабе гипермасштаба с исполнителем Kubernetes

Технический глубокий обзор: GitLab Runners на Kubernetes, установка оператора, значения Helm, автомасштабирование и модель затрат FinOps. Для краткой версии прочитайтеПерестаньте платить за простаивающий CI.

Большинство команд оплачивают непрерывную интеграцию так, будто каждый вечер и каждый выходной — всё ещё понедельник утром. Серверы остаются горячими. Диск остаётся выделенным. Никто не сливает код — и счёт не замечает. Это предложение не лозунг; это стандартная форма фиксированного парка runners.

Эта длинная статья является техническим дополнением к практическому руководству поGitLab Server и GitLab Runner на Kubernetes: как исполнитель Kubernetes превращает каждую задачу CI во временный под, как это позволяет динамическое планирование и отмену планирования мощности, и как эта архитектура открываетогромную экономиюза счёт возврата CPU, RAM и хранилища, когда спрос обваливается ночью и в выходные.

Сначала посмотрите оба сеанса, затем используйте эту страницу как письменную архитектуру и модель затрат.

1. Runners & pipelines— автомасштабирование рабочих нагрузок GitLab Runner на Kubernetes.

Смотреть: Полное руководство по GitLab Runners и CI/CD на Kubernetes· Простая версия:Перестаньте платить за простаивающий CI

2. GitLab Server on HA Kubernetes— разверните GitLab с помощью Operator за считанные минуты.

Смотреть: Развертывание GitLab в HA Kubernetes кластере с помощью Operator· Документация:Установка GitLab Operator

1. Тезис

GitLab на Kubernetes + executor Kubernetesменяет единицу измерения мощности CI с «машины, которой мы владеем весь месяц» на «поды (и ноды), которые мы арендуем на задачу». Менеджер runners остаётся компактным и всегда доступным. Поды задач появляются для сборки и исчезают после неё. С автоматическим масштабированием кластера рабочие ноды следуют по той же кривой. Вот так вы защищаете пропускную способность в понедельник утром и перестаете платить понедельничные цены за вторник в 03:00 и за тихие субботы.

В одном предложении — то же самое, что и в руководстве для новичков:provision для пика, de-provision для спада.

2. Дорогая привычка, описанная как архитектурный запах

Традиционный CI часто выглядит как постоянный флот: фиксированный набор машин для сборки, которые остаются «на всякий случай». Это работает, когда трафик стабилен. Это тратит деньги, когда спрос скачкообразный.

• Дневное время:разработчики пушат ветки, открывают merge requests, запускают тесты — спрос резко растёт.
• Вечера и ночи:активность падает; машины всё ещё потребляют CPU и RAM.
• Выходные:часто почти бездействующие — однако объёмы хранилища и облачные узлы могут всё ещё быть зарезервированы и оплачиваться.

Вы не платите за «выполненные сборки». Вы платите за мощность, которая существует независимо от того, пользуется ею кто-то или нет. Фиксированные флоты также накапливают липкое состояние: «работает на раннере 3», дрейфующие пакеты, кэши, которые никогда не истечают. Эластичные поды сами по себе не решают дисциплину, но они делают чистый лист по умолчанию.

3. Карта системы

Аналогия из простого руководства по-прежнему действует на этом слое: GitLab Runner — это рабочий; Kubernetes — диспетчер, который вызывает рабочих только когда приходят посылки (задачи), а затем отправляет их домой.

4. Установка GitLab на кластере (путь оператора)

Путь обучения Day 1 устанавливает GitLab с помощью официального оператора, поэтому сервер использует ту же Kubernetes основу, что и агенты. Видео-компаньонРазвертывание GitLab в кластере Kubernetes с высокой доступностью с помощью операторапроведёт вас через эту установку за несколько минут. Предварительные требования: кластер с ingress, Helm,kubectlи cert-manager, когда диаграмма управляет TLS.

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

helm install gitlab-operator gitlab/gitlab-operator \
  --create-namespace \
  --namespace gitlab-system

kubectl -n gitlab-system get deployment gitlab-controller-manager

# Apply the GitLab custom resource (pin chart version in the manifest)
kubectl -n gitlab-system apply -f deploy_gitlab_server.yaml

Пример формы CR (адаптируйте домен и адрес электронной почты издателя для вашей среды):

apiVersion: apps.gitlab.com/v1beta1
kind: GitLab
metadata:
  name: gitlab
spec:
  chart:
    version: "9.2.2"
    values:
      global:
        hosts:
          domain: "example.com"
        ingress:
          configureCertmanager: true
      certmanager-issuer:
        email: you@example.com

Первая установка обычно занимает около 10–15 минут, пока веб-сервис, Sidekiq, хранилища данных и связанные компоненты стабилизируются. Получите начальный пароль root из секрета кластера:

kubectl get secret gitlab-gitlab-initial-root-password -n gitlab-system \
  -o jsonpath='{.data.password}' | base64 -d

Справка:Установка GitLab Operator(вкладка Helm на этой странице). Обзор диаграммы:docs.gitlab.com/charts· руководство по установке:установка диаграмм.

5. GitLab Runner с исполнителем Kubernetes

GitLab Runner — это приложение, которое работает с GitLab CI/CD для выполнения задач в конвейере. С исполнителемKubernetesменеджер не компилирует на себе. Для каждой задачи он:

1. Создаёт под (плюс вспомогательные/сервисные контейнеры по конфигурации).
2. Передаёт логи обратно в GitLab.
3. Собирает артефакты и статус завершения.
4. Удаляет под — возвращая CPU и RAM в кластер.

Этот цикл создания/запуска/удаления — первый рычаг затрат. Завершённая работа не должна оставлять тёплую машину, выделенную на ночь.

5.1 Helm паттерн установки

Скрипты обучения создают пространство имён, передают токен регистрации и могут устанавливать более одного релиза (например, runners на базе Alpine и Ubuntu), чтобы задания могли выбирать разные окружения. Официальная процедура:Установка GitLab Runner по диаграмме Helm; справочник значений:Настройка диаграммы GitLab Runner Helm.

helm upgrade --install --namespace gitlab-runner gitlab-runner-alpine \
  -f config-runner-alpine.yaml \
  --set serviceAccount.create=true \
  gitlab/gitlab-runner \
  --create-namespace

Получение токенов из интерфейса GitLab (runners экземпляра / группы / проекта) или из управляемых оператором секретов. Предпочитайте современные токены аутентификации runners; токены регистрации устарели к GitLab 18.Никогда не коммитьте активные токены— скрипты лабораторий иногда содержат заполнители, которые необходимо заменить локально.

5.2 Параметры, важные для масштабирования и изоляции

Из шаблонов Workstation (gitlab-runner-values-template.yaml/ сгенерированныеconfig-runner-*.yaml):

gitlabUrl: http://gitlab-webservice-default.gitlab-system.svc.cluster.local:8080/
concurrent: 2
rbac:
  create: true
  clusterWideAccess: true
runners:
  privileged: true
  config: |
    [[runners]]
      environment = ["GIT_SSL_NO_VERIFY=1"]
      [runners.kubernetes]
        namespace = "gitlab-runner"
        image = "alpine/git:latest"
        service_account = "gitlab-runner"
        privileged = true

Конкурентность без CPU лишь удлиняет очередь. Сочетайтеconcurrentс реальным запасом мощности узлов или автоматическим масштабированием узлов.

6. Автомасштабирование на двух (а на самом деле четырёх) уровнях

«Автомасштабирование GitLab Runners на Kubernetes» — это не один переключатель. Наложите эти рычаги:

1. Эластичность подов задач— встроена в исполнитель Kubernetes. Ноль задач → ноль подов задач. Это само по себе устраняет большинство потерь на уровне каждой задачи на общем кластере.
2. Runnerconcurrentи несколько деплоиментов runners— разделяйте alpine и ubuntu (или CPU и более крупные сборщики), чтобы специализированная мощность не простаивала из-за неверного распределения.
3. Автомасштабирование кластера / узлов— ожидающие поды добавляют узлы; пустые узлы покидают кластер после вечерней суеты.
4. Опциональная политика, учитывающая расписание— снижение лимитов параллельности или масштабирование пулов узлов по календарю для ночей и выходных как дополнительная страховка поверх естественного падения спроса.

Гипермасштаб — та же история, но с более резкой амплитудой: распределяйте нагрузку при глубоких очередях, а затем агрессивно снимайте ресурсы, чтобы тихая половина недели не напоминала загруженную половину на инвойсе.

6.1 Замечание о «простоях» в смысле GitLab Runner

Некоторые исполнители поддерживают небольшое количество горячих простаивающих машин, чтобы без задержки холодного запуска принимать следующую задачу. На Kubernetes холодный запуск обычно означает создание пода (секунды), а не запуск виртуальной машины (минуты). Предпочитайте позволять подам уходить в ноль и принимать небольшую задержку по расписанию, вместо того чтобы держать ночную смену пустых узлов «на всякий случай». Если всё же нужно поддерживать минимальный уровень, ориентируйтесь на реальность дежурства — а не на шторм слияний в понедельник.

6.2 Динамическое предоставление и снятие с эксплуатации (provision/de-provision) по всей цепочке

Проследите один пайплайн-задачу:

1. Разработчик пушит; GitLab создаёт задачу в очереди ожидания.
2. Менеджер раннеров берёт задачу и запрашивает под у API.
3. Если в кластере не хватает CPU/ОЗУ, автоскейлер добавляет ноду (предоставление).
4. Под запускает скрипт, загружает артефакты, завершается.
5. Под удаляется; ресурсы возвращаются в пул (снятие с эксплуатации на уровне задачи).
6. Когда множество нод стоит пустыми после порога масштабирования вниз — типично вечером и на все выходные — ноды уходят (снятие с эксплуатации на уровне инфраструктуры).

Именно этот полный цикл означает, что видео говорит о GitLab Runners в гипермасштабе для оптимизации затрат: не какая-то одна изысканная флага, а жизненный цикл задач + эластичность кластера, работающие вместе.

7. Модель затрат: где появляются огромные экономии в долларах

Будьте точны. Автоскейлинг не делает сборки бесплатными. Он предотвращает оплату пиковых тарифов в непиковые часы. Экономия достигается за счёт соответствия расходов реальному спросу — четыре пункта из простого руководства, расширенные для операторов.

7.1 Масштабирование вверх только тогда, когда работают люди (или боты)

Когда загруженное утро приносит десятки пайплайнов, Kubernetes планирует множество под задач параллельно до пределов параллелизма и кластера. Пропускная способность проявляется, когда давление слияний реально.

7.2 Резко сокращайте масштаб при исчезновении спроса

Когда задачи завершаются, поды исчезают. С кластерным автомасштабированием (или правильно настроенным пулом узлов) неиспользуемые облачные узлы покидают пул. Ночи и выходные — обычно самые тихие окна для продуктовых команд — это первая ёмкость, за которую стоит перестать платить.

7.3 Перестаньте тратить CPU, RAM и хранилище

За месяц тихие часы доминируют в расписании. Возврат ночей и выходных — это то, гдеэкономия в долларах накапливается.

7.4 Платите за результаты, а не за мебель

Вы всё ещё платите за GitLab и за тонкий контрольный план (менеджер runners + основы кластера). За что вы перестаёте платить — это склад пустых стульев.

7.5 Работавшая интуиция (не искусственный бенчмарк)

Предположим, что дневная работа устойчиво требует эквивалента 20 занятых слотов исполнителей, а ночи и выходные — всего 2. Фиксированный парк, рассчитанный на 20 слотов, оплачивается 24/7. Эластичный пул оплачивает ~20 в течение дня и ~2 (плюс контрольную плоскость) в периоды затишья. Для многих команд продуктов тихие часы составляют значительную часть месяца — поэтому их возврат — это то, как экономия становитсяогромнойбез изобретения маркетингового процента. Финансы умножают цены за локальные часы работы узлов; задача архитектуры — сделать так, чтобы пустые часы действительно были пустыми в биллинговом аккаунте.

Огромная экономия проявляется, когда пик понедельника больше не диктует счёт за вторник в 3 часа ночи — и когда тишина субботы наконец выглядит тихой и на счётном билле тоже.

7.6 За что вы всё ещё платите намеренно

• Компоненты GitLab Server — размер под пользователей и координацию CI, а не под ферму компиляторов.
• Менеджер Runners Развёртывания — малый по сравнению с фермами задач.
• Целенаправленные кэши (прокси зависимостей, PVC) — полезны, но имеют размер; кэши — это не бесплатное хранилище.
• Привилегированный DinD — удобно и тяжёл; рассмотрите Kaniko/BuildKit, когда плотность и изоляция важнее привычности.

8. Практическое применение конвейеров CI/CD

С подключёнными агентами.gitlab-ci.ymlопределяет стадии и задачи. GitLab расписывает; исполнитель Kubernetes материализует поды. Держите конвейеры честными в вопросах стоимости:

• Быстро проваливайте линтинг и юнит-тесты до тяжёлых сборки образов.
• Используйтеrules/workflow, чтобы ветки-черновики не раздували полные матрицы.
• Предпочитайте общие кэши с чёткими ключами вместо неограниченного роста дисков на виртуальную машину.
• Назначайте задачи в соответствующий пул агентов (alpine vs ubuntu, малые vs крупные сборщики).

stages: [lint, test, build]

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

lint:
  stage: lint
  image: alpine:3.19
  script:
    - echo "cheap checks first"

test:
  stage: test
  tags: [kubernetes, alpine]
  script:
    - echo "unit tests"

build:
  stage: build
  tags: [kubernetes, dind]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - echo "heavy image build only on default branch"

Экономическая идея та же, что и платформу: не расписывайте дорогую работу, когда дешёвая проверка уже бы провалила, и не держите специализированные агенты в тепле для задач, которые никогда не придут в субботу.

9. Заметки по безопасности и аренде

Временные поды улучшают гигиену (меньше «липкого» состояния), но привилегированный DinD и кластерный RBAC могут расширить радиус поражения. Практические дефолты для большинства команд:

• Запускайте поды задач в выделенном namespace с ResourceQuotas и LimitRanges.
• По возможности предпочитайте небрегламентированные сборки; изолируйте агентов DinD за конкретными тегами.
• Избегайте монтирования долгосрочных облачных учётных данных в каждую задачу; внедряйте краткосрочные токены на конвейер.
• Относитесь к токенам регистрации агентов как к секретам — вращайте их при уходе людей или совместном использовании лабораторий.
• Если несколько команд разделяют кластер, разделяйте менеджеров агентов (и опционально пулы нод), чтобы один шумный сосед не держал горячим весь парк — и сохраняйте экономическую историю атрибутируемой по командам.

10. Наблюдаемость, доказывающая экономию

Вы не можете утверждать экономию в ночное время и по выходным, не посмотрев. Отслеживайте хотя бы:

Если количество подов падает ночью, но счёт за узлы не падает, следующие настройки масштабирования — не GitLab — являются следующим рычагом.

11. Фиксированные ВМ против исполнителей Kubernetes (таблица решений)

Выбирайте фиксированные ВМ только тогда, когда у вас действительно плоский спрос 24×7 или ограничения, запрещающие использование кластера. Все остальные со спайковыми, управляемыми людьми конвейерами, платят «налог на мебель».

12. Чего вы не теряете

Автоматическое масштабирование не означает «отсутствие контроля». Вы по-прежнему задаёте параллельность, разрешённые образы, привилегии DinD, политику сети и область регистрации. Суть в том, чтобы сохранить эти средства контроля, позволяя неиспользуемой мощности испаряться — тот же уровень уверенности, что и в простом тексте, теперь обеспечиваемый RBAC, пространствами имён и отдельными релизами runner.

13. Операционный контрольный список

1. Версии оператора/диаграммы; обновление — осознанное действие.
2. Вращайте токены runners; перед публикацией очищайте токены лаборатории из любого скрипта.
3. Раздельные пространства имён: GitLab система vs задачи runners.
4. Следите заожидающимипод-контейнерами — рост ожидающих означает нехватку параллелизма или ёмкости узлов в пиковые моменты.
5. Следите зачасами простоя узлов— узлы, простаивающие ночью, указывают на задержку масштабирования или необходимость настройки политики пула.
6. Ограничьте привилегированные runners только задачами, которые в них нуждаются.
7. Делайте резервные копии GitLab независимо от эластичности runners.
8. Пересматривайте счёт по часам недели после запуска эластичного CI — ночные и выходные часы должны явно снизиться.

14. Для кого это

• Инженеры платформы и SREs, внедряющие GitLab CI на Kubernetes.
• Руководители DevOps, заменяющие стационарные VM runners на под-контейнеры исполнителей.
• Партнёры из инженерии и финансов, которым нужно, чтобы CI работал как утилитарная услуга с оплатой по использованию, а не как мебель.

15. Официальная документация GitLab

Эти страницы являются каноническими ссылками для описанных выше развёртываний Helm и поведения масштабирования. При изменении версий предпочитайте их блоговым постам.

Сервер GitLab на Kubernetes

• Установка оператора GitLab— оператор + путь установки Helm, используемый в обучающем руководстве.
• Диаграммы GitLab Helm— документация по «зонтичной» диаграмме.
• Установка GitLab с помощью диаграммы Helm— при развёртывании GitLab через диаграммы, а не через оператор.
• Поддиаграмма gitlab-runner (диаграмма GitLab)— runner, встроенный рядом с GitLab в основной диаграмме (отличается от отдельной диаграммы runner).

Диаграмма GitLab Runner Helm

• Установка GitLab Runner с помощью диаграммы Helm—helm repo add gitlab, установка/обновление, примечания к диаграмме OCI.
• Настройка диаграммы GitLab Runner Helm—concurrent, шаблоны конфигурации, RBAC, кэши, выбор образов.
• диаграмма gitlab-runnervalues.yaml— полные значения по умолчанию (включая опциональные заглушки HPA).

Kubernetes executor и автомасштабирование

• Kubernetes executor— job pods, helpers, services (например, DinD), resource requests, RBAC verbs.
• Настройка автомасштабирования (Kubernetes executor / chart)— пауза pods,[runners.kubernetes.autoscaler], периодические политики (idle по ночам/в выходные).
• Автомасштабирование GitLab Runner— общая модель автомасштабирования (также охватывает распределённое кэширование).
• Планирование и управление флотом GitLab Runner— масштабирование и операции на уровне флота.
• Продвинутая конфигурация (config.toml)— глобальныеconcurrentи executor-секции, встроенные в Helmrunners.config.

CI-задачи, сборки и настройки runner в GitLab

• Настройка runners в GitLab— регистрация, теги, run-untagged, защищённые runners.
• Использование Docker для сборки образов в CI— DinD и альтернативы (актуально, когдаprivileged/ Docker service включён в значения runner).

Для контроля затрат в ночное время и в выходные комбинируйте: (1) Kubernetes executor job pods, которые снижаются до нуля, (2) chartconcurrentи политики автомасштабированияс off-peak, и (3) автомасштабирование кластера/узлов, чтобы пустые узлы покидали пул — как описано в разделах 6–7.

16. Возврат к видео и репозиторию

Сессия YouTube —Полный GitLab за ~20 минут. Масштабирование рабочих нагрузок GitLab Runner с помощью Kubernetes— демонстрирует GitLab на Kubernetes, runners через Helm, и историю стоимости гипермасштаба: динамическое создание и удаление инфраструктуры, чтобы вы не платили пиковые тарифы за бездействующие ночи и выходные. Используйте подсказку сборки курсаgitlab-runners-k3s-hyperscale-course.prompt.mdв этом репозитории, с официальными документами выше как версионным источником истины. Для нетехнического изложения одних и тех же идей см.Перестаньте платить за бездействующий CI.

Заключительные слова

Kubernetes не просто размещает GitLab Runners. При правильном использовании он меняет экономику CI:создание по требованию, удаление при простое, возврат CPU/ОЗУ/хранилища, когда люди уходят домой. Это паттерн гипермасштаба — доступный любой команде, готовой обменять постоянный флот на очередь подов.

Начните с видео, разверните оператора + runner Helm в лаборатории, включите автоматическое масштабирование узлов, а затем проверьте, наконец ли в субботу на инвойсе тихо.

ОпубликованоWorkstation.