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

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

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

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

Я про Роберта :)

Я про Роберта :)

У меня все тоже самое + нужно держать разные версии приложения. Например deployment с image: v1, смотрит в базу db1, deployment с image: v2 смотрит в базу db2 и так далее.

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

БД отдельно не хочу менеджить, опять же - пусть все через куб создается, даже если оно реально вне куба расположено

Я вот думал как эту проблему можно решить, и придумал git-deploy-proxy, который разворачивается непосредственно в кубе и каждый git push он инициализирует деплой. Пользователь видит output в режиме реального времени. Если деплой прошёл успешно то коммит проходит в upstream-репо.

БД отдельно не хочу менеджить, опять же - пусть все через куб создается, даже если оно реально вне куба расположено

я создал внешний сервис, и прокинул в ингресе, но что-то не так работает, не пойму где накосячил

Всем ку.
ПОдскажите можно ли из пода получить все эндпоинты (поды) сервиса в текущем нэйспэйсе.
Нужно приложению для принудительной очистки эндпоинта

Тоже рабочий вариант, но мне было бы удобнее сделать свой легковесный дескриптор, типа

apiVersion: lol/kek
kind: MyDeploymentTemplate
metadata:
  name: myAwesomeAppTemplate
spec:
  image: foo/bar:baz
  ...

И при апдейте имейджа в этом темплейте будут апдейтиться все деплойменты в том же неймспейсе, созданные из него. Поддержка нескольких версий сразу в одном неймспейсе не нужна вроде, поэтому над этим не думал

Первый доклад от wunderman thompson

Ребят куда копать?)
Деплою Jenkins k8s on-premise с calico и metallb.

kubectl logs  pod/jenkins-1609752171-0 -n jenkins
error: a container name must be specified for pod jenkins-1609752171-0, choose one of: [jenkins config-reload] or one of the init containers: [init]

та мне кажется усложнение. В helm чарте ты можешь же range пройти по грубо говоря apps из values и создать несколько одинаковых деплойментов но с разными секретами

Например в values такое:

apps:
  android:
         secret: 'android'
  facebook:
    secret: 'facebook'
  fbinstant:
    secret: 'fbinstant'


А дальше range по ним и подставляешь нужный тебе секрет в deployment.

То. есть мысль такая, не факт что создавать оператор для такого имеет смысл, оператор это доп сложность и доп баги. Но дело твое конечно