Установка пишет в репозиторий, а не в кластер

Команда установки приложения не делает установку в кластер. Она записывает желаемое состояние в репозиторий проекта, коммитит изменение и отправляет канонический GitOps-источник. Дальше состояние применяет ArgoCD.

Разница выглядит формальной и меняет почти всё.

Что меняется

Приложение, удалённое из кластера руками, вернётся. Владелец состояния — репозиторий, а не последняя выполненная команда. Кластер сходится к описанию непрерывно.

Установка становится обратимой понятным способом: откат — это откат коммита, а не поиск того, что именно команда наделала.

Обзор изменений становится возможным. Добавление приложения — это дифф, который можно посмотреть до применения и обсудить.

История появляется сама. Вопрос «когда у нас появился этот сервис и кто его поставил» имеет ответ без отдельной системы учёта.

Чего это стоит

Установка перестаёт быть мгновенной. Между командой и работающим приложением стоит цикл сверки, и он занимает время.

Поэтому у команды есть режим ожидания: при интерактивном запуске она по умолчанию ждёт, пока состояние станет синхронизированным и здоровым. Для скриптов и непрерывной интеграции ожидание отключается флагом, а таймаут задаётся явно.

Значение по умолчанию выбрано по типу запуска, а не одно на всех: человек за терминалом почти всегда хочет дождаться, скрипт почти всегда не хочет.

Почему не ставить напрямую

Прямая установка в кластер быстрее и понятнее в моменте. Её проблема в том, что она создаёт состояние, которого нет в описании.

Через полгода в кластере работает набор приложений, часть из которых поставлена командой, часть — вручную во время аварии, часть — коллегой, который уже не в проекте. Описание при этом выглядит полным. Расхождение обнаруживается при попытке воспроизвести окружение.

Запись в репозиторий делает расхождение невозможным по построению: если приложения нет в репозитории, его не должно быть в кластере, и наоборот.

Локальный источник без внешнего сервера

Возражение на это правило звучит так: не у всех есть свой Git-сервер.

Локальный GitOps-запуск решает это. Если указанная папка пуста, инструмент сам создаёт рабочее дерево, локальный удалённый репозиторий внутри проекта, файл источника, первый коммит и отправку.

Это не обход GitOps и не запасной путь. Это тот же канонический источник, просто расположенный локально — с тем же поведением и теми же гарантиями, что и с внешним сервером. Позже источник можно переключить на внешний, не меняя способ работы.

Что остаётся ручным

Решение о том, что ставить. Инструмент не предлагает набор приложений и не досоздаёт зависимости молча — метаданные о зависимостях в каталоге есть, но выбор остаётся за человеком.

Причина та же, что и в остальном: значения по умолчанию для состава инфраструктуры — плохая идея, потому что их никто потом не пересматривает.