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

Собсвтенно именно поэтому для таких случаев liveness может навредить, что в статье и говорится, но для rediness это в самый раз

Проблема в том что там строе statefull джава приложение. Нельза масштабировать. Поэтому если кубик отключит от сети то пудет 502. клиентам не нравиться это

failureThreshold: 120
periodSeconds: 1

ну вот и выяснили, что как окозалось это просто legacy, да еще и statefull. Legacy и не cloud-native в кубе боль, шо поделать 🤷

Непойму теперь зачем она нужна

Так а как теперь startUp спасёт и что мешает сделать delay?

Так а зачем это. Ставь delay по максимому.

Как узнать имя секрета которое будет сгенерировано хелмом для postgresql в качестве зависимости? Попробовал {{ template "postgresql.secretName" . }} и получил

 executing "postgresql.secretName" at <.Values.global.postgresql.existingSecret>: nil pointer evaluating interface {}.existingSecret

Окей, тогда как без постоянного readness сделать обновление без даунтайма