Как развернуть GitLab в Kubernetes: своя площадка для кода и сборок
5 ноября 2026 г.
GitLab в Kubernetes устанавливается официальным Helm-чартом. Helm это пакетный менеджер Kubernetes, он ставит приложения чартами, пакетами манифестов с настройками. Манифест это описание объекта кластера в YAML, кластер это группа серверов под управлением Kubernetes. Чарт даёт штатный способ развернуть контейнерную установку системы в собственном кластере, в том числе в управляемом кластере VK Cloud (сервис Managed Containers). Порядок установки расписан в разделах Prepare to deploy и Deploy официальной документации GitLab Helm chart. В результате у команды появляется своя площадка с репозиториями, задачами и сборочным конвейером CI/CD, которая работает в вашем облаке и подчиняется вашим правилам.
Свой GitLab разворачивают, когда код не должен покидать контур компании, сборкам нужны свои мощности без очередей, а доступами хочется управлять из собственного каталога пользователей. Для компаний с требованиями по защите информации свой GitLab в российском облаке закрывает ещё и вопрос расположения данных.
Что понадобится до начала: кластер Kubernetes с запасом ресурсов, доменное имя для веб-интерфейса, внешние PostgreSQL и Redis (хранилище данных в памяти для кэша и очередей) и объектное хранилище (облачное хранилище файлов по протоколу S3). Чарт умеет поднять PostgreSQL и Redis внутри кластера, но документация чарта прямо требует внешние сервисы и объектное хранилище, а для production советует референсную архитектуру под ваше число пользователей, где за пределы кластера при любом размере установки выносится и Gitaly, хранилище репозиториев.
Шесть шагов до работающего GitLab
1. Готовим кластер с запасом.
GitLab состоит из набора сервисов: веб-интерфейс, очередь задач, хранилище репозиториев. Требования к ресурсам берите из раздела Prepare to deploy документации чарта, там названы минимальные ядра и память для кластера, под сборки добавляйте сверху. Создайте кластер в личном кабинете VK Cloud (инструкция) и размер группы worker-узлов (серверов кластера, на которых работают контейнеры) сверьте с требованиями из документации чарта.
2. Разворачиваем зависимости.
PostgreSQL и Redis создаём в сервисе управляемых баз Cloud Databases (инструкция), версии и параметры берите из требований текущей версии чарта. Адреса и учётные данные затем уходят в параметры установки, а встроенные в чарт копии отключаются.
3. Подключаем объектное хранилище.
GitLab складывает в хранилище по протоколу S3 артефакты сборок, LFS-объекты (большие файлы Git вне репозитория), загрузки, пакеты, реестр образов (хранилище контейнерных образов) и резервные копии. По документации по внешнему объектному хранилищу под каждый тип данных заводится отдельный бакет, именованное хранилище файлов, а общий бакет на всё ломает восстановление из резервной копии. В VK Cloud для этого создаётся аккаунт с ключами Access Key ID и Secret Key и набор бакетов (быстрый старт VK Object Storage), реквизиты прописываются в параметрах чарта.
4. Ставим Helm-чарт.
Добавляете репозиторий чартов GitLab и задаёте параметры установки: домен, издателя сертификатов, классы хранения (типы дисков для томов кластера), адреса базы, Redis и бакетов. Встроенные в чарт ingress-nginx и cert-manager отключаем в параметрах установки и указываем класс Ingress (имя контроллера, который будет вести трафик) и объект ClusterIssuer от аддонов VK Cloud, о них следующий шаг. Конкретные команды и значения берите из документации чарта, они меняются от версии к версии, поэтому сверяйтесь с первоисточником, а не со статьями.
5. Открываем доступ.
Доменное имя направляем на балансировщик аддона Ingress NGINX, облачную точку входа трафика с внешним IP. Аддон это дополнительный компонент кластера из личного кабинета, а этот аддон принимает HTTP-трафик по доменным именам (установка). GitLab поднимает несколько поддоменов (gitlab, registry, kas), поэтому на балансировщик направляется wildcard-запись домена, запись DNS сразу на все поддомены. Сертификаты выпускает cert-manager с настроенным объектом ClusterIssuer, настройками удостоверяющего центра (установка).
6. Запускаем сборки.
GitLab Runner работает в том же кластере и выполняет задачи конвейера в отдельных подах, единицах запуска контейнеров. Когда сборок становится больше, группа узлов расширяется вертикально (машины покрупнее) или горизонтально (больше машин), в том числе автоматически (масштабирование узлов кластера).
На схеме ниже контур целиком: разработчики отправляют код в GitLab через Ingress, внутри кластера рядом с GitLab работают поды GitLab Runner со сборками, артефакты и образы уходят в бакеты объектного хранилища по S3. База и Redis стоят за пределами кластера в Cloud Databases, поэтому на схеме их нет.
Пять ошибок при установке
1. Кластер впритык. GitLab стартует, а первая же параллельная сборка упирается в нехватку ресурсов, и очередь задач начинает расти. Запас под сборки считается как лимит ресурсов одной задачи Runner, умноженный на число одновременных сборок. Закладывается он при создании кластера, а не после жалоб команды.
2. База и Redis внутри чарта на боевой установке. Встроенные копии удобны для проверки, но у них нет резервных копий, реплик и обновлений на стороне облака. Переезд на внешние сервисы потом означает миграцию данных под нагрузкой, дешевле начать с Cloud Databases.
3. Артефакты во встроенном MinIO чарта или в одном бакете. Встроенный MinIO живёт на одном томе фиксированного размера, и он заканчивается в самый неудобный момент, а восстановление из резервной копии при общем бакете работает некорректно. Объектное хранилище с отдельными бакетами подключается сразу, на третьем шаге, пока данных мало и перенос дешёвый.
4. Runner без ограничений. Сборки без лимитов процессора и памяти вытесняют сам GitLab с его же узлов. Лимиты задаются в настройках Runner, значения подбираются по замеру реальной сборки проекта.
5. Обновление вслепую. Порядок обновления меняется от версии к версии, поэтому перед сменой версии чарта читаются замечания к выпуску в документации GitLab, а обновление сначала прогоняется на тестовой установке.
Частые вопросы
1. Потянет ли кластер из двух worker-узлов?
Закладывайте узлы по требованиям из документации чарта и оставляйте запас под сборки. При нескольких параллельных сборках конвейер потребляет больше, чем сам GitLab.
2. Можно ли разнести GitLab и сборки?
Да, схема такая: сам GitLab работает где угодно, а в Kubernetes остаются только Runner и сборочные поды. Так кластер отдаётся под его прямое назначение, под масштабируемые задачи.
3. Зачем внешнее объектное хранилище, если чарт поднимает своё?
Артефакты и образы растут с каждой сборкой, а у тома в кластере размер фиксирован, бакет же расширяется сам и к кластеру не привязан.
4. Как обновлять GitLab?
Командой helm upgrade с новой версией чарта, порядок и предупреждения по версиям собраны в документации GitLab.
5. Нужен ли отдельный кластер под GitLab?
Пока в кластере кроме GitLab живут только тестовые окружения, хватает отдельной группы узлов. Отдельный кластер заводят, когда сборки начинают мешать боевым сервисам соседством.
Короче говоря для заметки:
-
Штатный путь: официальный Helm-чарт, параметры и команды из документации GitLab, под production внешние PostgreSQL, Redis и объектное хранилище.
-
Домен и сертификаты закрывают аддоны Ingress NGINX и cert-manager, как и для любого сервиса в кластере.
-
Артефакты, образы и резервные копии уводим в объектное хранилище по S3, отдельный бакет на каждый тип данных.
-
Сборки масштабируются вместе с группой worker-узлов, вплоть до автоматического расширения.
Оставьте заявку, чтобы получить консультацию
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
Узнавайте о выходе новых статей в блоге первыми!
Будем держать в курсе новостей и облачных трендов
Почитать по теме
10 сентября
Как работает git reset: разница между soft, mixed и hard
10 сентября
Git rebase vs merge: в чём разница и когда что использовать
6 ноября
