<b>Argo CD ломается не в Git, а в том, как вы собираете манифесты и права</b>

<b>Argo CD ломается не в Git, а в том, как вы собираете манифесты и права</b>

Argo удобен, пока у вас один кластер и один путь деплоя. Дальше начинают всплывать типовые ошибки: конфиг живёт в нескольких репозиториях, Helm values расходятся между средами, а app-of-apps превращается в неуправляемую цепочку зависимостей.

Чтобы Argo не стал точкой хаоса, держите базовый каркас:
— один источник правды для манифестов;
— явное разделение проектов, namespaces и ролей;
— синхронизацию только через Git, без ручных правок в кластере;
— отдельные приложения для инфраструктуры и workload’ов;
— health checks и sync waves там, где ресурсы зависят друг от друга.

Самая частая ловушка — смешивать доставку и сборку. Argo хорошо применяет уже собранные артефакты, но не должен знать, как они рождаются. Сборка уезжает в ci_cd, а Argo получает только то, что можно безопасно задеплоить и откатить.

Второй риск — слишком широкие права у service account и AppProject. Если приложение может писать куда угодно, один ошибочный манифест превращается в инцидент на весь kubernetes. Ограничивайте namespaces, cluster-scoped ресурсы и источники репозиториев сразу, а не после первого сбоя.

Если хотите, чтобы Argo был предсказуемым, проектируйте его как часть observability и monitoring: логи синка, события, health статусы и алерты на drift должны быть видны до того, как это заметит трафик.