А чего Графане передаете? Зачем?

Да как минимум белую тему и настройки ссо)

а, понятно!

Коллеги, подскажите пожалуйста. Есть helm chart, содержащий деплойменты, скажем a, b, c. Каждый содержит описание одного пода. Можно ли сделать так, чтобы поды, описанные в b и c стартовали ТОЛЬКО после того как успешно стартанул под и деплоймента a?

то что надо! Из инит-контейнера буду пинговать под a (у него заранее известный внутренний адрес) - когда запингуется, стартану b и c. Спасибо

а зачем статичный адрес у пода, если есть сервисы

правильное решение будет научить приложения дожидаться своих зависимостей, и фейлить redinessProbe пока этого не произошло

++

Безусловно. На практике этого удаётся достичь малой кровью куда реже, чем кажется на первый взгляд. То нет контроля над всем приложением, то над библиотеками, то разные аннотации и "магия"... Но как цель - прекрасно. Хотя бы подумать стоит обязательно. Если спрингбут или дропвизард или нода - то нечего думать вообще. Там есть контролируемая вами точка входа и возможность свернуться и развернуться.  Однако initContainer - палочка-выручалочка чаще, чем того хотелось бы.

на ноде легко это сделать, я частенько делаю. В java я не умею, но наверняка и там это реализуемо. Не можешь сам поставь задачу на программиста. Мы же за devops, заборов между прогерами и опсами быть не должно. Ну или всегда можно запилить это через sidecar, который результат проверки кидает в emtydir, а redinessProbe проверяет этот файлик в emtydir.
Initcontainer - плохая практика для таких кейсов, так как в случае падения приложения "a" уже после старта, во время работы приложения "b" - неизвестно что произойдет. Так как "b" не умеет проверять доступность "a" и переподключаться к нему, а вместо этого был запилен костыль в виде init container

выстраивать зависимости именно при запуске приложений в k8s - бэд практика

+

Или argocd & sync waves 😬

Кстати, хороший совет насчёт sidecar и emptyDir.
Я-то сам севера на джаве больше 20 лет пишу. И вот кинулся недавно все перевести (несколько десятков компонент) и руки опускаются. То есть решить можно, конечно. Но блин иногда просто проще целиком все переписать:)
В любом случае - для всех новых разработок под куб непростительно не отслеживать зависимости и не поддерживать readiness и адекватное поведение переподключениий. Куча туториалов и мало препятствий. Причём неважно, это рельсы, питон, джава или нода

интересно, что там на Java такого, что трудно просто чекать доступность сервиса от которого зависит текущее приложение, а в случаях когда тот сервис недоступен выдавать 503.  Или речь идет о глобальной задаче - перевести legacy приложение в cloud native, тогда да - лучше вообще забить и оставить его не в кубе

Ну типа того. Типичный пример - подключена библиотека через jar в которой есть @WebListener аннотация и её автоматом подхватывает веб контейнер. И там ожидается что в переменных окружения есть url базы и пароль доступа. Но обработки падения или недоступности нет. При постановке задачи база была HA.

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