За счет чего происходит выстраивание деплоя Kubernetes на GitLab

Механизм деплоя в Kubernetes через GitLab CI/CD

Выстраивание деплоя Kubernetes на GitLab происходит за счет интеграции нескольких ключевых компонентов: GitLab CI/CD (непрерывная интеграция и доставка), Kubernetes API, GitLab Runner и специализированных инструментов деплоя (чаще всего kubectl и helm). Основой является файл .gitlab-ci.yml, который описывает весь пайплайн.

Ключевые компоненты архитектуры

1. GitLab CI/CD Pipeline: Автоматизированный workflow, определяемый в .gitlab-ci.yml. Он состоит из стадий (например, build, test, deploy), которые выполняются при событиях (push, merge request).
2. Kubernetes Integration в GitLab: Позволяет связать кластер K8s с проектом GitLab. Это создает:

    *   **Service Account** с необходимыми правами (RBAC) в кластере.
    *   **Kubernetes Secret** с сертификатом для аутентификации (`ca.crt`, `token`).
    *   **Переменные окружения** в проекте GitLab (`KUBE_URL`, `KUBE_CA_PEM`, `KUBE_TOKEN`), которые используются в пайплайне для доступа к API K8s.

1. GitLab Runner: Агент, который выполняет jobs пайплайна. Для деплоя в K8s часто используется Runner с исполнителем kubernetes, который сам запускает каждую job внутри Pod'а в целевом (или отдельном) кластере. Это обеспечивает изоляцию и динамическое создание окружений.
2. Инструменты деплоя: В jobs используются CLI-утилиты для взаимодействия с кластером:

    *   **`kubectl`** – для применения манифестов YAML/JSON.
    *   **`helm`** – для управления чартами (пакетами приложений).
    *   **`kustomize`** – для кастомизации манифестов.

Типичная последовательность деплоя в пайплайне

В файле .gitlab-ci.yml создается job на стадии deploy. Для работы с кластером необходимо настроить аутентификацию, обычно через указанные GitLab переменные.

Пример job для деплоя через kubectl:

deploy_to_production:
  stage: deploy
  image: bitnami/kubectl:latest # Используем образ с установленным kubectl
  script:
    # 1. Конфигурация доступа к кластеру
    - echo "$KUBE_CA_PEM" > ca.pem
    - kubectl config set-cluster my-cluster --server="$KUBE_URL" --certificate-authority=ca.pem
    - kubectl config set-credentials gitlab-sa --token="$KUBE_TOKEN"
    - kubectl config set-context my-context --cluster=my-cluster --user=gitlab-sa --namespace=production
    - kubectl config use-context my-context

    # 2. Непосредственное применение манифестов (например, обновление Deployment)
    - kubectl apply -f k8s/manifests/deployment.yaml
    - kubectl apply -f k8s/manifests/service.yaml
    # Или для обновления образа в конкретном Deployment
    - kubectl set image deployment/my-app container-name=registry.gitlab.com/group/project:$CI_COMMIT_SHORT_SHA

    # 3. (Опционально) Проверка статуса деплоя
    - kubectl rollout status deployment/my-app --timeout=60s
  only:
    - main # Запускать только при пуше в main ветку
  environment:
    name: production
    url: https://my-app.example.com # GitLab будет отображать ссылку на это окружение

Пример деплоя с использованием helm:

deploy_with_helm:
  stage: deploy
  image: alpine/helm:latest
  script:
    - echo "$KUBE_CA_PEM" > ca.pem
    - kubectl config set-cluster my-cluster --server="$KUBE_URL" --certificate-authority=ca.pem --embed-certs=true
    - kubectl config set-credentials gitlab-sa --token="$KUBE_TOKEN"
    - kubectl config set-context my-context --cluster=my-cluster --user=gitlab-sa
    - kubectl config use-context my-context

    # Установка или обновление релиза Helm
    - helm upgrade --install my-release ./helm/chart \
        --set image.tag=$CI_COMMIT_SHORT_SHA \
        --set ingress.hostname=$CI_ENVIRONMENT_SLUG.my-domain.com \
        --namespace production \
        --atomic --wait # Важные флаги для CI: откат при ошибке и ожидание готовности
  environment:
    name: production

Дополнительные возможности и best practices

• Auto DevOps: GitLab предлагает готовый пайплайн Auto DevOps, который автоматически определяет язык, собирает, тестирует и деплоит приложение в Kubernetes без глубокой настройки .gitlab-ci.yml. Он использует Helm под капотом.
• Review Apps: Динамическое создание временных окружений для каждого merge request на основе ветки. Обычно реализуется через развертывание в отдельном namespace с уникальным URL.
• GitLab Environments: Визуализация окружений (staging, production) в интерфейсе GitLab с отображением текущей версии приложения, статуса деплоя и прямой ссылки на приложение.
• Security: Для доступа к кластеру рекомендуется использовать ограниченные ServiceAccount с минимально необходимыми правами (RBAC). Токены и сертификаты хранятся как защищенные переменные (masked и protected variables).
• Шаблоны деплоя (Deployment templates): Можно вынести общую логику настройки kubectl/helm в before_script или использовать встроенные шаблоны GitLab.

Итог: Деплой в Kubernetes из GitLab – это автоматизированный процесс, управляемый кодом (пайплайном .gitlab-ci.yml), который использует встроенную интеграцию с K8s для безопасной аутентификации и стандартные инструменты экосистемы (kubectl, helm) для развертывания и обновления приложений в кластере. Это обеспечивает повторяемость, аудит изменений и скорость доставки.