Что такое GitLab Agent (для Kubernetes)?

GitLab Agent for Kubernetes (ранее известный как GitLab Kubernetes Agent) — это компонент, который устанавливается внутри Kubernetes-кластера и устанавливает безопасный туннель обратного соединения с GitLab. Это позволяет GitLab безопасно взаимодействовать с кластером без необходимости открывать входящие порты (например, для kubectl) в кластере или хранить его учетные данные в GitLab CI/CD переменных.

Решаемые проблемы и преимущества перед старым подходом (Runner + kubeconfig):

• Безопасность: Нет необходимости в статическом kubeconfig файле с долгоживущими токенами или сертификатами в секретах GitLab. Агент использует короткоживущие токены и инициирует соединение из кластера в GitLab (аутбанд).
• Много-кластерность: Один проект GitLab может управлять несколькими кластерами через разных агентов.
• GitOps: Прямая интеграция с GitLab для развертываний по модели GitOps. Вы можете определить желаемое состояние манифестов в репозитории, и агент будет синхронизировать его с кластером.
• Расширенный функционал: Помимо CI/CD, агент используется для интеграции кластера с GitLab для отображения объектов Kubernetes, сбора метрик, управления уязвимостями контейнеров.

Типичный процесс установки и настройки:

1. В GitLab: В меню вашего проекта или группы переходите в Infrastructure > Kubernetes clusters и добавляете новый кластер, выбирая способ Connect a cluster (agent). GitLab сгенерирует уникальный токен для агента.
2. В Kubernetes-кластере: Устанавливаете агента, используя этот токен. Стандартный способ — через Helm-чарт.

Пример установки через Helm (в gitlab-agent namespace):

# Добавить репозиторий
helm repo add gitlab https://charts.gitlab.io
helm repo update

# Установить агента
helm upgrade --install gitlab-agent gitlab/gitlab-agent 
    --namespace gitlab-agent --create-namespace 
    --set config.token=glagent-xxxxxxxxxxxxxxxx 
    --set config.kasAddress=wss://gitlab.example.com/-/kubernetes-agent/ 
    --set image.tag=v16.10.0

Пример использования в .gitlab-ci.yml для развертывания через агента (без kubectl в раннере):

deploy_to_production:
  stage: deploy
  image: alpine:latest
  script:
    # Вместо настройки kubectl, используем встроенную интеграцию.
    # GitLab передаст контекст кластера через переменные окружения.
    - |
      echo "Deploying using GitLab Agent connection..."
      # Здесь может быть вызов helm, kustomize или отправка манифестов
      kubectl --agent-id ${CI_KAS_AGENT_ID} apply -f k8s/manifests/
  only:
    - main

В моей практике использование GitLab Agent значительно упростило управление доступом к production-кластерам, позволив отказаться от хранения чувствительных kubeconfig и реализовать чистый GitOps-пайплайн, где изменения в манифестах в main ветке автоматически применяются агентом.