Зачем? Зачем ныряешь в кроличью нору? Бери менеджед куб от облака. Не нужно его разворачивать

Ну, развертывание кубика как такового мне пожалуй рано и непонятно нужно ли. Мне больше интересно все что касается развертывания приложения в кластере k8s

Точно не туда. Ищи вражеские курсы.

Да как бы был на пачке курсов, был на воркшопах, просто уже устал от того что там все ходят вокруг да около но не дают цельной картины. Где-то про нюансы докера раскажут, где-то про нюансы инфраструктуры, но вот чтобы взять и рассказать как завернуть приложение в кубик со всеми нюансами  - такого не вижу. А те курсы что вижу, они очень приличные по времени. По 40-50-60 часов. Я боюсь что пока все пересмотрю, выйдет уже новая технология 🙂

Как завернуть прямо со всеми нюансами и 60 часов не хватит

Почему? Повторюсь - докер знаю. линукс тоже. Создать нужные контейнеры - без проблем. В общем и поды тоже. Развернуть деплоймент в облаке я уже тоже умею

Потому что может быть куча нюансов с сетями, разными ингрессами, шедулингом физических ресурсов etc

есть шаблонизатор helm template
вопрос у него есть условие на проверку существования файла?

Конкретнее?

Что хочешь?

чекать файл, если файл есть включать в манифест кусок кода

Напрямую нет, но сделать можно

Kodekloud посмотри, может, найдешь что-то интересное. Там интерактивные упражнения через katakoda

Возможно, меня сейчас какашками закидают, но мне понравилось

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

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

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

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

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

Доброго дня. Подскажите, а могу ли я прокинуть в ингресе  ресурс который находится не в куб-кластере, а nginx находящийся на том же дедике, но в lxc отдельном.?

Насчёт нескольких деплойментов - можно через тот же консул исхитриться ) т.е. есть некая матрица конфигов и приложение само с собой договаривается и определяет какой подтягивать, но сложно в реализации. Наверное, проще действительно разные деплоймент тащить

Да - если нужен короткий ответ

а если подлиннее), можешь пнуть на пример?