Поделитесь опытом, как можно заимплементить следующий юзкейс: Есть stateless приложение, общающееся

с БД. Надо его деплоить и масштабировать, делаем Deployment объект с нужным имейджем, прописываем в окружение ссылку на секрет, где лежат креденшелы к БД. При создании новой версии приложения меняем имейдж версию. Всё просто и красиво.
Но что если инстансы этого приложения должны разговаривать с разными инстансами БД? Придется делать несколько деплойментов, и несколько секретов (на каждую БД). Плюс несколько ингрессов, чтобы клиента отправлять в нужную группу инстансов. Ок, делаем условный хелм чарт, при создании группы объектов переменными разруливаем.
И теперь при апдейте версии приложения нам нужно апдейтить не 1 деплоймент, а сразу целую кучу. Руками делать это чревато ошибками.
Но ок, пишем скрипт, который вытягивает деплойменты по лейблам, и проставляет им всем новую версию. Криво, но в общем случае должно работать.
А теперь сверху добавим требование, чтобы при создании новой такой группы инстансов приложения дергались ещё и внешние системы - ту же БД не хочется создавать руками (а в облаке можно запросить инстанс через API), и есть ещё пара интеграций, которые при создании/удалении группы инстансов нужно вызывать.

Получается, что при добавлении группы инстансов (деплоймента и всей пачки сопутствующих объектов) нужно ещё и сходить в несколько систем, и дернуть их руками (или через скрипт). А при удалении произвести обратные действия.

TL;DR нужно:
1) создавать/апдейтить/удалять кубовые объекты (деплойменты, секреты, ингрессы)
2) дергать при изменениях внешние API
3) при изменении версии приложения апдейтить имейдж во всех деплойментах (а не просто во всех репликах одного деплоймента), где это приложение крутится

Появляется желание это дело автоматизировать, и свести админскую деятельность к минимуму.
Напрашивается очевидная мысль написать под это кастомный оператор. Пока думаю в этом направлении, но, может, есть способы сделать это всё проще, и я упускаю что-то очевидное?

Оператор - да, но это слишком общо, ты же конкретику хочешь

У меня все тоже самое + нужно держать разные версии приложения. Например deployment с image: v1, смотрит в базу db1, deployment с image: v2 смотрит в базу db2 и так далее. Разруливаю довольно просто. Ребята из проекта сами решают когда и какой образ надо задеплоить и дергают нужную задачу в CI для этого, выбирая в ней нужную версию. Если им удобней описывать где какая версия через репу, то делаю тоже самое только теперь они правят репу и ставят там нужные им образы и пушат вместо того чтобы дергать задачу в CI но сути не меняет.

Тоже рабочий вариант, но мне было бы удобнее сделать свой легковесный дескриптор, типа apiVersion: lol/kek kind: MyDeploymentTemplate metadata: name: myAwesomeAppTemplate spec: image: foo/bar:baz ... И при апдейте имейджа в этом темплейте будут апдейтиться все деплойменты в том же неймспейсе, созданные из него. Поддержка нескольких версий сразу в одном неймспейсе не нужна вроде, поэтому над этим не думал

та мне кажется усложнение. В helm чарте ты можешь же range пройти по грубо говоря apps из values и создать несколько одинаковых деплойментов но с разными секретами Например в values такое: apps: android: secret: 'android' facebook: secret: 'facebook' fbinstant: secret: 'fbinstant' А дальше range по ним и подставляешь нужный тебе секрет в deployment. То. есть мысль такая, не факт что создавать оператор для такого имеет смысл, оператор это доп сложность и доп баги. Но дело твое конечно

Если бы проблема была только в кубовых ресурсах, то я бы на темплейтинге и остановился, возможно, да. Но мне нужно дополнительные ресурсы менеджить вне кластера, и не хочется этого делать руками, потому что я обязательно накосячу. А единожды написав отлаженный процесс, я получу возможность косячить меньше. Есть готовые операторы, которые часть того что мне нужно умеют делать. Но не 100%, и их придется деплоить несколько штук, что тоже доп. сложность. Мне проще написать свое кастомное легковесное решение

а вдруг уже есть решения? И можно кубовыми манифестами рулить внешними ресурсами. Например вот смотри: https://aws.amazon.com/blogs/containers/aws-controllers-for-kubernetes-ack/ И еще специально под этот кейс придумали: https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/ мб твой провайдер/облако поддерживает service catalog для куба. Например aws: https://aws.amazon.com/blogs/opensource/provision-aws-services-kubernetes-aws-service-broker/