Liveness Probe
Liveness-проба помогает контролировать состояние приложения: показывает, работает ли под с запущенным приложением или нет. Проверки выполняются периодически. В случае, если под не пройдет проверку Liveness-пробы, Kubernetes автоматически перезапустит под с приложением. Если же под с приложением запущен, проверка Liveness-пробы игнорируется.
Liveness-пробы не должны быть ресурсоемкими. Если вызывать их каждую секунду, кластер Kubernetes будет расходовать дополнительные ресурсы, а это плохое решение.
Важно грамотно использовать Liveness-пробы: их неправильная настройка может существенно навредить работоспособности приложения. Бывают случаи, когда при неправильной настройке такой пробы запущенные поды начинают хаотично перезапускаться. В качестве проверки для Liveness-пробы никогда не используйте подключения к сторонним службам, например к веб-серверу.
Readiness Probe
Readiness-проба помогает проверить, готов ли под с запущенным приложением принимать сетевой трафик. Важная особенность Readiness-пробы в том, что если проверка будет неуспешной (в нашем случае — если приложение не сможет принимать сетевой трафик), то под с приложением будет исключен из балансировки. Это значит, что новые запросы перестанут на него поступать, но сам под продолжит работу и не будет принудительно завершен. Такую особенность можно использовать, чтобы «освободить» приложение от потока поступающего сетевого трафика. Как только приложение возобновит прием трафика, под вернется обратно в балансировку.
Readiness-проба полезна больше всего, когда приложение работает со сбоями и временно не может принимать входящий трафик. Она сообщает Kubernetes, что приложение находится на этапе запуска, прежде чем начнет получать и обрабатывать сетевой трафик.
Также Readiness-пробы широко используются при первоначальном запуске: при старте масштабных приложений им может потребоваться некоторое время на запуск. Readiness-проба гарантирует, что Kubernetes не будет отправлять трафик до тех пор, пока приложение полностью не запустится.
Startup Probe
Startup-проба проверяет, что приложение на запуске прошло инициализацию и готово принимать запросы. Когда под с приложением запущен, Kubernetes считает, что приложение в нем работает и может принимать запросы.
Однако некоторые приложения могут долго запускаться. Если Kubernetes попытается отправить запрос до запуска, они не обработаются. Предотвратить такие ситуации помогают Startup-пробы, которые сообщают кластеру Kubernetes о готовности приложения к работе. Только после этого Kubernetes будет считать, что они работают.
Использование проб на практике
Перейдем к практическому использованию проб в Kubernetes. Всё, о чем мы поговорили в статье, я протестировал на двухнодовом кластере Kubernetes версии 1.27.14.
Для начала протестируем Liveness-пробу. Некоторые приложения, которые работают долгое время, со временем могут выйти из строя. Восстановить их можно будет только при помощи перезапуска. Воссоздадим эту ситуацию: в качестве запускаемого приложения выберем образ с busybox (пакет прикладных программ), внутри которого будет создан файл с именем healthy в директории /tmp. Каждые пять секунд проба будет выполнять команду cat /tmp/healthy. По истечении 30 секунд после запуска контейнера файл healthy будет удален. После этого под должен быть перезапущен.
Создаем новый файл с объектом типа pod:
nano liveness_probe.yaml
с содержимым:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: registry.k8s.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Создаем под в Kubernetes-кластере с командой:
kubectl create -f liveness_probe.yaml
При помощи команды
kubectl describe pod liveness-exec
убедимся, что что Liveness-проба создана и запущена:
Итак, проба запущена — на это указывает строка Started container liveness. Ждем 30 секунд и смотрим статус пробы еще раз:
kubectl describe pod liveness-exec
Теперь ситуация другая: проба не смогла стартовать, потому что ранее созданный файл удален. Проверка не пройдена, под был перезапущен — на это указывает строка Container liveness failed liveness probe, will be restarted. В строке RESTARTS об информации пода мы тоже видим, что он перезапущен:
Теперь перейдем к использованию Readiness Probe. Для нее возьмем образ с nginx.
Иногда приложение временно не может принимать сетевой трафик: во время старта грузится большой объем данных или приложение зависит от запуска другого сервиса. В таких случаях завершать принудительно работу приложения не нужно, но и отправлять ему сетевые запросы тоже нет необходимости. Readiness-проба оповещает кластер о том, что приложение временно не готово принимать трафик.
Создаем новый файл
nano liveness_probe.yaml
с содержимым:
apiVersion: v1
kind: Pod
metadata:
name: example-nginx-pod
spec:
containers:
- name: nginx-test
image: nginx
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
Создаем под в Kubernetes-кластере при помощи команды:
kubectl create -f readiness_probe.yaml
Потом смотрим статус Readiness-пробы:
kubectl describe pod example-nginx-pod
Readiness-проба отображается в статусе failed — это означает, что контейнер еще недоступен по порту 8080 (например, он всё еще запускается) и трафик не будет направлен, пока приложение полностью не стартует.
Переходим к использованию Startup-пробы. Она помогает убедиться, что приложение действительно запущено и готово принимать запросы. Создадим ситуацию, когда мы подготовили файл deployment для запуска nginx, но ошиблись в имени файла и вместо nginx.conf задали nginx.conf-error.backup. В таком случае сработает Startup-проба, которая сообщит: такого файла не существует. Создаем новый файл:
nano startup_probe.yaml
с содержимым:
apiVersion: apps/v1
kind: Deployment
metadata:
name: k8s-probes
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
startupProbe:
initialDelaySeconds: 1
periodSeconds: 2
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 1
exec:
command:
- cat
- /etc/nginx/nginx.conf-error.backup
Создаем deployment в Kubernetes-кластере при помощи команды:
kubectl create -f startup_probe.yaml
Смотрим статус Startup-пробы:
kubectl describe pod <имя_пода>
Startup-проба завершилась с ошибкой, потому что файла nginx.conf-error.backup нет в контейнере с приложением.
В статье мы познакомились с пробами в Kubernetes и рассмотрели, как их применять. С таким инструментом гораздо легче следить за состоянием приложений в запуске, но важно пользоваться им правильно: некорректная настройка проб может ухудшить работоспособность приложений.
