Relay (KAS) — сервер, к которому подключаются агенты для Kubernetes, установленные в кластерах. Пока Relay не настроен, диалог «Подключение кластера Kubernetes» на странице «Кластеры Kubernetes» проекта вместо формы регистрации агента показывает сообщение «В вашем инстансе не настроен GitLab Relay (KAS). Попросите администратора Deckhouse Code установить его».

Включение Relay

В пакете для ОС Linux и в Omnibus Docker Relay установлен и запущен по умолчанию. В Helm-чарте Relay не разворачивается, пока не включён в значениях.

  • Пакет для ОС Linux
  • Omnibus Docker
  • Helm-чарт

Relay работает как служба gitlab-kas и не требует настройки. Чтобы отключить его, укажите в /etc/gitlab/gitlab.rb:

gitlab_kas['enable'] = false

Примените изменение:

sudo gitlab-ctl reconfigure

Relay работает как служба gitlab-kas внутри контейнера и не требует настройки. Чтобы отключить его, добавьте gitlab_kas['enable'] = false в файл /srv/code/config/gitlab.rb на хосте и примените изменение:

docker exec code gitlab-ctl reconfigure

Ключ, заданный в GITLAB_OMNIBUS_CONFIG, вступает в силу только после пересоздания контейнера с теми же томами. Оба места описаны на странице «Настройка» раздела аутентификации.

Включите Relay в values.yaml:

global:
  kas:
    enabled: true

Примените значения к релизу:

helm upgrade code oci://<CHART_REGISTRY>/code \
  --version <CHART_VERSION> \
  -n code \
  -f values.yaml

Адрес подключения

Агенты подключаются к Relay по протоколу WebSocket по его внешнему адресу.

  • Пакет для ОС Linux
  • Omnibus Docker
  • Helm-чарт

По умолчанию Relay отвечает на адресе инстанса по пути /-/kubernetes-agent/. При external_url 'https://code.example.com' адрес Relay — wss://code.example.com/-/kubernetes-agent/; при адресе инстанса со схемой http схема адреса — ws.

Чтобы Relay отвечал на отдельном хосте, укажите его в /etc/gitlab/gitlab.rb:

gitlab_kas_external_url 'wss://kas.example.com/'

Адрес принимает только схемы ws и wss. Для адреса со схемой wss поместите сертификат и ключ хоста в /etc/gitlab/ssl/kas.example.com.crt и /etc/gitlab/ssl/kas.example.com.key и создайте DNS-запись для kas.example.com, указывающую на сервер. Если включён Let’s Encrypt и этих файлов нет, хост Relay добавляется в сертификат Let’s Encrypt инстанса. Затем выполните sudo gitlab-ctl reconfigure.

Адрес задаётся теми же ключами, что и в пакете для ОС Linux, в файле /srv/code/config/gitlab.rb на хосте. С томами из быстрого старта сертификат и ключ отдельного хоста Relay размещаются в /srv/code/config/ssl/ на хосте. Изменение вступает в силу после docker exec code gitlab-ctl reconfigure; ключ, заданный в GITLAB_OMNIBUS_CONFIG, вступает в силу только после пересоздания контейнера.

Relay отвечает на отдельном хосте kas.<domain>, где <domain> — значение global.hosts.domain. Другое имя задаётся в global.hosts.kas.name. Создайте для этого хоста DNS-запись, указывающую на тот же адрес, что и веб-интерфейс.

В режиме certManager параметра global.codeHelm.ingress.tls.mode чарт выпускает сертификат хоста в Secret code-kas-tls. В режиме manual хост Relay использует Secret, указанный в gitlab.kas.ingress.tls.secretName, или Secret из global.ingress.tls.secretName, если первое значение пустое; сертификат в этом Secret покрывает имя хоста Relay. Значения описаны на странице «Расширенная настройка».

Проверка Relay

На странице «Admin» → «Обзор инстанса» → «Дашборд» блок «Компоненты» показывает строку «GitLab KAS» с версией Relay. Пока Relay отключён, строки нет. Значение «Неизвестно» означает, что инстанс не получил версию от Relay.

Проверьте состояние Relay:

  • Пакет для ОС Linux
  • Omnibus Docker
  • Helm-чарт
sudo gitlab-ctl status gitlab-kas
sudo gitlab-ctl tail gitlab-kas

Журналы службы находятся в /var/log/gitlab/gitlab-kas/.

docker exec code gitlab-ctl status gitlab-kas
docker exec code gitlab-ctl tail gitlab-kas
d8 k -n code get pods -l app=kas

Авторизация агентов на уровне инстанса

Раздел ci_access файла конфигурации агента .gitlab/agents/<AGENT_NAME>/config.yaml в проекте агента, где <AGENT_NAME> — имя агента, перечисляет проекты и группы, задания CI/CD которых могут использовать агент; каждый список принимает до 500 записей. По умолчанию раздел может перечислять проекты и группы внутри группы верхнего уровня, в которую входит проект агента; если проект агента находится в личном неймспейсе, — только проекты этого неймспейса. С авторизацией на уровне инстанса раздел может перечислять проекты и группы из любых групп верхнего уровня, а его ключ instance авторизует агент для всех проектов инстанса.

  1. Перейдите в «Admin» → «Настройки» → «Основные».
  2. Разверните раздел «GitLab Agent для Kubernetes».
  3. Установите флажок «Включить авторизацию на уровне инстанса».
  4. Нажмите «Сохранить изменения».

Агенты для Kubernetes

Агент для Kubernetes (agentk) работает в кластере и подключает его к Relay. Агент разворачивает в кластере пользователь, который его регистрирует, или администратор Deckhouse Code; установки Deckhouse Code агенты не разворачивают.

После регистрации агента диалог «Подключение кластера Kubernetes» показывает команду helm upgrade --install, которая устанавливает агент из чарта gitlab/gitlab-agent. Deckhouse Code предоставляет образ агента registry.deckhouse.ru/deckhouse/ee/packages/code/images/agentk. Чтобы установить агент из этого образа, добавьте в команду из диалога строку --set image.repository:

helm repo add gitlab https://charts.gitlab.io
helm repo update
helm upgrade --install <AGENT_NAME> gitlab/gitlab-agent \
    --namespace gitlab-agent-<AGENT_NAME> \
    --create-namespace \
    --set image.repository=registry.deckhouse.ru/deckhouse/ee/packages/code/images/agentk \
    --set image.tag=v<VERSION> \
    --set config.token=<TOKEN> \
    --set config.kasAddress=<RELAY_ADDRESS>

Значения <AGENT_NAME>, <VERSION>, <TOKEN> и <RELAY_ADDRESS> берутся из команды в диалоге.

←
Администрирование / Расширенный поиск
Администрирование / Резервное копирование и восстановление
→