Comments 3
Считаю ужасной практикой в livenessProbe делать http-запросы. Это проверка, что контейнер не зомби, т.е. запущены нужные процессы. Эту проверку надо делать максимально часто, чтобы мёртвый процесс действительно мёртв был. И эта проверка не должна ни в коем случае зависеть от нагрузки и сокетов. А то получится, что у вас нагрузка выросла и контейнер делает себе харакири. В итоге на другие распределяется нагрузка, и они тоже делают себе харакири. Кластер лежит, пользователи недоумевают, CTO порет ремнем SRE - такая себе картина.
Для readinessProbe это нормально и если сильно нагрузка бахнула, то они действительно могут и должны на время выпасть из обмена, пока не переварят. Такую проверку можно делать реже, чтоб тоже не загадить подключения. Но эта проверка действительно будет делать то, что нужно - проверять, что сервис может принимать подключения и обрабатывать их.
Например, в приведённом деплойменте nginx, можно было бы проверить наличие процесса nginx для проверки жизни в контейнере, что прям сложность O(1) имеет. Тогда период можно в одну секунду поставить, чтоб мгновенно пезагрузить. А читабельность оставить как есть. Но для Cloud Native лучше livenessProbe отдельно реализовывать: проверять, что нужный процесс не просто запущен, но имеется активность внутри. Если это какой-то циклический обработчик, то можно писать файлик (даже пустой) и проверять время последнего изменения.
"Например, в приведённом деплойменте nginx, можно было бы проверить наличие процесса nginx для проверки жизни в контейнере, что прям сложность O(1) имеет. "
Не совсем понял зачем проверять процесс nginx процесс если у него обычно pid 1 (не считая всяких tini) и под убивается если умирает процесс?
Тут кажется была статья, в которой описывалось, что как раз выполнение команд в контейнере гораздо сложнее, чем выполнение http запроса. И там был кейс, в котором как раз частый запрос liveness через команды контейнера приводил в зависанию всего кластера
Проверки работоспособности в Kubernetes