Установка GitLab Runner на Kubernetes с помощью Helm chart

Полное руководство по развертыванию CI/CD исполнителя в Kubernetes кластере

12 февраля 2026 • Арно Фернандес

Введение

Автоматизация CI/CD с GitLab Runner и Kubernetes

Использование CI/CD систем для быстрой сборки и развертывания программного обеспечения стало стандартом в профессиональной разработке. Команды, использующие CI/CD системы, могут собирать, тестировать и развертывать каждый коммит из своего репозитория.

Вместе с CI/CD системами, инструменты автоматизированного развертывания и оркестрации, такие как Kubernetes, заняли центральное место в современных дата-центрах с полностью контейнеризированными рабочими нагрузками.

Автоматизированный пайплайн для сборки, тестирования и развертывания вашего кода становится реальностью при интеграции CI/CD системы с Kubernetes. Создание такой системы становится простым с помощью GitLab Runner и Kubernetes кластера.

В этом руководстве я покажу, как настроить CI/CD систему GitLab и запустить её на Kubernetes кластере — для полностью автоматизированных релизов.

Конфигурация Helm chart

Базовая установка

Добавьте репозиторий GitLab и установите chart Репозиторий Helm: https://charts.gitlab.io, Chart: gitlab/gitlab-runner

values.yaml для production

values.yaml

gitlabUrl: https://gitlab.com
runnerToken: glrt-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        namespace = "{{ default .Release.Namespace .Values.runners.jobNamespace }}"
        image = "ubuntu:20.04"
        privileged = true
      [[runners.kubernetes.volumes.empty_dir]]
        name = "docker-certs"
        mount_path = "/certs/client"
        medium = "Memory"

Объяснение securityContext

privileged = true и allowPrivilegeEscalation = true

Почему Docker-in-Docker требует привилегированного режима

Для работы Docker-in-Docker в Kubernetes требуется:

privileged = true — доступ к устройствам ядра и монтирование файловых систем
allowPrivilegeEscalation = true — возможность повышения привилегий для Docker daemon

Безопасность

Эта конфигурация необходима для полного доступа к устройствам ядра и сетевым возможностям Docker.

Docker-in-Docker с TLS

Конфигурация GitLab CI/CD pipeline

.gitlab-ci.yml

build-backend:
  stage: build
  image: docker:24.0
  services:
    - name: docker:24.0-dind
      command:
        - "--mtu=1400"
      variables:
        HEALTHCHECK_TCP_PORT: "2376"
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: 1
    DOCKER_CERT_PATH: "$DOCKER_TLS_CERTDIR/client"

Пояснение параметров:

--mtu=1400 — решение сетевых проблем в некоторых окружениях
DOCKER_TLS_CERTDIR: "/certs" — путь к сертификатам TLS
DOCKER_TLS_VERIFY: 1 — включение проверки TLS сертификатов

Решение сетевых проблем

Настройка MTU

В некоторых сетевых окружениях (особенно при использовании VPN, overlay сетей или определенных провайдеров) могут возникать проблемы с фрагментацией пакетов.

Параметр --mtu=1400 уменьшает Maximum Transmission Unit для Docker daemon, что помогает избежать фрагментации пакетов.

Когда нужно настраивать MTU?

Если в логах видны ошибки сети, таймауты соединений или проблемы с загрузкой образов — попробуйте уменьшить MTU. Типичные значения: 1500 (стандарт), 1400 (для большинства VPN), 1300 (для сложных сетей).

Заключение

Как мы видим, настройка GitLab Runner на Kubernetes не является сложной задачей. С помощью регистрационного токена из GitLab мы можем легко авторизовать нового Runner. Затем простые ConfigMap и Deployment используются для запуска Runner в Kubernetes кластере.

Используя Kubernetes executor на Runner, пайплайны могут автоматически масштабироваться по кластеру по мере роста спроса на ваши задачи сборки. Хотя базовый Runner уже мощный, подключение Docker daemon к Runner позволяет ему собирать Docker контейнеры.

После того как Runner запущен и работает, мы можем выполнять CI/CD пайплайны и развертывать сборки на Kubernetes кластере — всё на 100% автоматизировано.

Установка GitLab Runner в Kubernetes с помощью Helm chart предоставляет мощное решение для CI/CD. Ключевые аспекты:

Использование privileged = true с allowPrivilegeEscalation = true для обеспечения работы Docker-in-Docker
Настройка Docker-in-Docker с TLS для безопасной коммуникации
Решение сетевых проблем через настройку MTU при необходимости
Использование emptyDir volumes для хранения сертификатов TLS

Нужна помощь с CI/CD?

Мы поможем настроить GitLab Runner и CI/CD pipeline для ваших проектов. Свяжитесь с нами для консультации.

Обсудить проект