Деплой — это коммит: как GitOps делает гибридную инфраструктуру управляемой

Есть два способа выкатить что-то в Kubernetes из пайплайна. Первый — дать CI доступ к кластеру и выполнить kubectl apply или helm upgrade. Второй — записать желаемое состояние в git и позволить контроллеру в кластере привести реальность к нему. ViVA построена на втором, и это решение определяет очень многое.

Почему CI не ходит в кластер

Когда пайплайн применяет манифесты напрямую, кластер перестаёт быть воспроизводимым: его состояние — результат последовательности успешных и не очень джобов. Откат означает «найти, что применялось до», а аудит — «пролистать логи CI».

В ViVA джобы деплоя — ml:deploy:* для моделей и app:deploy:* для сервисов — пишут values.yaml в GitOps-репозиторий и открывают merge request. Argo CD согласует кластер с репозиторием и показывает статус в портале. Кластер в любой момент равен репозиторию, а история прода — это git log.

Один шаблон наполнения — для всех кластеров

Наполнение кластера платформой описано в каталоге platform/_template: Argo CD, HAProxy Ingress, cert-manager, Vault, Keycloak, VictoriaMetrics с Grafana, Loki, хранилище RustFS, MLflow, KServe, операторы CloudNativePG, Percona MongoDB, Valkey, RabbitMQ и Strimzi, JupyterHub, Feast, Airflow, GitLab Runner, DefectDojo. Джоба platform:bootstrap рендерит шаблон в platform/<кластер> и применяет корневое Application — остальное делает Argo CD.

Кластер в Yandex Cloud, кластер в cloud.ru и кластер на своих серверах через Kubespray получают одно и то же наполнение. Разница между ними — имя каталога. Окружения сервиса при этом могут жить на разных кластерах: dev — в облаке, prod — в своём контуре.

apps/<target>/<env>/<model>/values.yaml           текущее состояние
apps/<target>/<env>/<model>/values.previous.yaml   предыдущее, для отката
charts/model-serving/                              Helm-чарт InferenceService
platform/_template/                                app-of-apps наполнения кластера
platform/<кластер>/                                отрендеренная копия для кластера

Кто имеет право писать

В GitOps-репозиторий пишет служебный бот по project access token, который джоба получает из Vault кластера по OIDC. У людей права на запись в прод-каталоги не нужны: они меняют код и параметры пайплайна, а состояние прода меняется через MR с автором, ревью и статусом пайплайна.

Merge request'ы для staging и canary мержатся автоматически, когда пайплайн зелёный. Промоушен в прод — отдельная ручная стадия, и это единственное место, где нужен человек.

Что это даёт

• Откат — копия файла. values.previous.yaml восстанавливается одной джобой.
• Аудит бесплатно. Каждое изменение прода — коммит с автором, ревью и ссылкой на пайплайн.
• Гибрид без боли. Переезд сервиса или модели между облаком и своими серверами — смена целевого каталога.
• Портал видит правду. Статус Argo CD, версия чемпиона и состояние сервинга приходят из того же источника, что и деплой.

Как это выглядит для сервисов и инфраструктуры — в разделе Возможности.