плохая практика. В приложении лучше делать проверки на доступность необходимых ему сервисов.
Если без этих сервисов приложение не может работать, то лучше просто на redinessProbe не отвечать

у тебя может быть два типа отказов

1. эластик не успел загрузиться
2. эластик работал, но сдох, пока твое приложение работало

идеальный вариант - да, т.е. приложение запущено, как бы работает, но говорит, что не готово

это через пробы организоввывать?

и да, и нет - в смысле да - они нужны, в смысле - недостаточно, т.к. у тебя само приложение должно эти кейсы отрабатывать как-то

и давать нужные ручки для проб

вот я об этом и спрашивал изначально, на каком уровне более правильно это фиксить

через приложение, которое отвечает/не отвечает на redinessProbe. Вообще микросеврисы предполагают делать так, и куб расчитан именно на такое  - каждый сервис может работать независимо, порядок запуска не должен быть важен.  Остальное все костыли и легаси как правило

скажите, если я использую kubeseal чтобы закрыть секрет локально, через kubectl то мне нужно, чтобы мой контекст указывал на мой кластер, в котором будет деплоится под и секрет, чтобы его можно было распечатать. Но происходит интересное:
kubectl create secret generic source-file-name.any --from-file=source-file-name.any --dry-run=client -o=yaml | kubeseal --controller-namespace sealed-secrets --format yaml - создаю локально запечатанный секрет, все нормально.
Пушу в гитопс репо, и под создается, но замаунтить вольюм не может, так как не создается секрет или точнее из логов: type: 'Warning' reason: 'ErrUnsealFailed' Failed to unseal: no key could decrypt secret
Смотрю на свои контексты:
kubectl get context - нет нужного контекста. Теперь вопрос: как добавить контекст? контекст, который дает доступ к самому кластеру есть. Мне наш девопс говорит, что мне нужно, чтобы у контекста было именно то самое имя. Но если я создаю контекст с нужным именем
kubectl config create-context my-context-name он не привязан к кластеру ...

"каждый сервис может работать независимо, порядок запуска не должен быть важен" - окай, нужные ответы получены :D

всем спасибо

это кстати часто в литературе указывается, если нужны авторитетные источники можешь поискать

а кто пользуется autoscaler в  aws eks: сталкивались, что не скейлет даун?
2020-08-28T10:51:30.880257284Z I0828 10:51:30.880230       1 cluster.go:148] Detailed evaluation: ip-10-138-3-45.eu-west-1.compute.internal for removal
2020-08-28T10:51:30.880285052Z I0828 10:51:30.880247       1 cluster.go:168] Detailed evaluation: node ip-10-138-3-45.eu-west-1.compute.internal cannot be removed: replication controller for ****/service1-7f948b856h6w88 has too few replicas spec: 824645097612 min: 3
2020-08-28T10:51:30.880291897Z I0828 10:51:30.880256       1 cluster.go:148] Detailed evaluation: ip-10-138-3-212.eu-west-1.compute.internal for removal
2020-08-28T10:51:30.880298152Z I0828 10:51:30.880266       1 cluster.go:168] Detailed evaluation: node ip-10-138-3-212.eu-west-1.compute.internal cannot be removed: replication controller for ****/service2-bd7b97896-6q4jq has too few replicas spec: 824647245228 min: 3
2020-08-28T10:51:30.880359642Z I0828 10:51:30.880316       1 scale_down.go:920] No node to remove

создал https://github.com/kubernetes/autoscaler/issues/3479

https://prnt.sc/u9ig2f
у меня такие вот права глобально цепляется эта роль при появлении нового юзера, проблема пока одна - не видно подов в проектах( чего не хватает не подскажешь?

В гуе не видно ?

ага

Read only чем не подошёл ?

В остальном твоя табличка похоже, что правильная

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