Что ты несешь?
> Лютый зоопарк - это натравливать gitops operator на репу с исходниками программы

Зоопарк это когда у тебя много разношерстных зверей сидят в разных клетках.
У тебя 2 репо и 2 тулзы связаные с деплоем - собиратель образов и "gitops operator". У меня 1 репо и 1 тулза и для сборки и для деплоя (и даже команда одна). Вот и подумай у кого зоопарк, если результат один - приложение раскатано в кубер и определяется кодом в гите.
И давай пожалуйста конкретику, почему запускать программу развертывания над кодом это плохо? Мы хотим чтобы состояние в кластере определялось состоянием кода - над чем собственно еще запускать (по определению)? То что вы делаете со 2 репо и отрендереными чартами - это совсем не похоже на то что состояние приложения определяется кодом приложения. Это вторичная ненужная сущность усложняющая систему и ломающая изначальный посыл. У вас на самом деле только конфигурация приложения определяется кодом, а само приложение, его код - нет, оно осталось за скобками когда-то кем-то собраным в образ и мы должны этому свято верить.
> С таким отбитым подходом, какие инструменты не придумывай, всё равно фигня получится, потому что сюр изначально заложен в архитектуру.

В чем отбитость подхода? Можно конкретики?
Что является критерием отбитости? Забыли добавить сущностей ради сущностей?
> gitops operator

Постоянно офигеваю над этими хипсторами нахватавшимися непойми чего на курсах.
У них у всех как на подбор gitops - это не абстрактный подход (отделенный от реализации) по тому как надо делать деплоймент, а это конкретная реализация gitops operator работающая по модели pull... и вообще в 80% случаев это конкретная программа - argo cd.
Сначала они настраивают по стековерфлоу свою argo cd, а потом в их голове оказывается что получившееся и есть gitops, и они лезут со своим выдуманным "gitops" пачкать интернет.
Печально.