Коллеги, подскажите пожалуйста. Есть helm chart, содержащий деплойменты, скажем a,

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

https://stackoverflow.com/questions/50838141/how-can-we-create-service-dependencies-using-kubernetes/50838829#50838829

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

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

++

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

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

+

Или argocd & sync waves 😬

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

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

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

Так вопрос HA базы эт больше к куберу, сделай сервис и прокси высокодоступный, для приложения эндпоинт никогда не изменится

А если сеть «моргнула» все, приклад в нуллпоинтер крашится? За такое и до кубера руки отрывать надо было.

Да я же разве спорю. Моргала. Крашалась. Сисопы приходили отрывать руки :) А кому щас легко? Не, ну реально очень мало где нет какого-то бардака. Поэтому люди, которые умеют писать надёжный код сидят на критических для бизнеса компонентах. Но это отступление... а то мы так дойдём до того, что сейчас за кадры идёт не борьба, а бешеная война в сев Америке. Тек сектор растёт, иммиграция стоит, работы невпроворот, аутсорсить большинству владельцев страшно или неудобно.

Да я как системный инженер страдаю. Столько лет уже в айти, а воз и ныне там. Разрабы думаю что инфра всё стерпит.

И пи-эмы тоже думают, что стерпит. И сроки часто нереальные поэтому. И так по всей цепочке от бизнеса до измотанного разбуженного алертами в 5 утра дежурного сетевика. Но вообще об этой проблеме надо говорить. Вешать баги на фреймворки. Публиковать решения в блогах. Нетфликс в свое время круто эту тему подняли, хаос обезьяны, брейкеры и т.д., но с тех пор их стек стал неподъемным для среднего стартапа. Я всяко с вами.

а если хочется избежать постоянное падения и перезапуска сервисов? это жрет очень много цпу, старт java приложухи очень дорогая операция

readinessProbe != livenessProbe

ну да и что, я про падения при запуске

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

контейнеры не перезапускаются из-за redinessProbe