В Kubernetes есть механизм проверки работоспособности, с помощью которого можно узнать, работает контейнер в pod’е или нет.
Проверка работоспособности kubelet поддерживает три типа проверок работоспособности:
Проба запуска (startup).
Проба работоспособности (liveness).
Проба готовности (readiness).
Проба запуска (startup)
Приложения с инфраструктурой и устаревшие приложения дольше запускаются при первой инициализации. В этом случае мы используем тот же метод проверки (команда, HTTP-запрос или проверка TCP), что и для остальных проб, но увеличиваем порог ожидания в секундах, чтобы приложение успело запуститься.
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
Проба работоспособности (liveness)
Проба работоспособности проверяет, выполняется контейнер или нет.
Если проба не находит живой контейнер, автоматически выполняется политика перезапуска контейнера.
Проба готовности (readiness)
Проба готовности проверяет, готово ли приложение обслуживать запросы.
Если не готово, IP pod’а удаляется из списка конечных точек сервиса.
kubelet производит с pod’ом три типа действия:
Выполняет команду в контейнере.
Проверяет состояние определённого порта в контейнере.
Выполняет запрос GET к IP-адресу контейнера.
Команда для пробы работоспособности
livenessProbe:
exec:
command:
- sh
- /tmp/status_check.sh
initialDelaySeconds: 10
periodSeconds: 5
HTTP-запрос для пробы работоспособности
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
Проверка TCP для пробы работоспособности
---
initialDelaySeconds: 15
livenessProbe: ~
periodSeconds: 20
port: 8080
tcpSocket: ~
Пробы готовности настраиваются так же, как пробы работоспособности.
Разница в том, что вместо livenessProbe мы указываем значение для readinessProbe.
Проба готовности
---
command:
- sh
- /tmp/status_check.sh
exec: ~
initialDelaySeconds: 5
periodSeconds: 5
readinessProbe: ~
Настройка проб
В пробах можно настроить несколько значений:
initialDelaySeconds: через сколько секунд после запуска контейнера начинаются пробы работоспособности или готовности.
По умолчанию — 0 секунд. Минимальное значение — 0.periodSeconds: сколько секунд проходит между пробами.
По умолчанию — 10 секунд. Минимальное значение — 1.timeoutSeconds: через сколько секунд истекает время ожидания пробы.По умолчанию — 1 секунда. Минимальное значение — 1.
successThreshold: сколько проб подряд должно завершиться успехом, чтобы проверка считалась успешной после проваленной пробы.
По умолчанию — 1. Для пробы работоспособности должно быть 1. Минимальное значение — 1.failureThreshold: сколько проб должно провалиться, чтобы пришлось перезапускать контейнер (или pod был помечен как неготовый, если речь о проверке готовности). По умолчанию — 3. Минимальное значение — 1.
Развёртывание Nginx
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-webserver
labels:
app: webserver
spec:
replicas: 1
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: webserver
image: nginx
imagePullPolicy: Always
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 3
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 3
Для HTTP get можно настроить дополнительные параметры:
path: путь для доступа на HTTP-сервере.
port: имя или номер порта для доступа к контейнеру. Номер должен находиться в диапазоне от 1 до 65535.
host: имя хоста для подключения; по умолчанию — IP pod’а. Можно задать хост в заголовках HTTP.
httpHeaders: кастомные заголовки для запроса. HTTP разрешает повторяющиеся заголовки.
scheme: схема для подключения к хосту (HTTP или HTTPS). По умолчанию — HTTP.
Еще больше про K8s
Для тех, кто хочет углубить свои знания в Kubernetes 11 ноября стартует новый поток Kubernetes:Мега. Вас ждет разбор кейсов вместе со спикерами и 6 часов практики.
На курсе вы: установите Kubernetes в ручном режиме, авторизуетесь в кластере, настроите autoscaling, разберете такие темы, как Open Policy Agent, Network Policy, безопасность и высокодоступные приложения, ротация сертификатов, аутентификация пользователей в кластере, хранение секретов, Horisontal Pod Autoscaler, создание собственного оператор K8s.
«Мега» подойдет всем, кому предстоит запускать Kubernetes в продакшн и отвечать за работу проекта в дальнейшем: специалистам по безопасности, системным инженерам, администраторам, архитекторам, DevOps и др.
Зачем нужен интенсив, когда есть документация?
Экономия времени: полтора месяца, вместо нескольких, которые вы потратили бы на чтение и самостоятельные эксперименты
Документация может месяцами лежать в папке «прочитать», а интенсив это конкретные даты.
Здесь есть практика, где помогают находить ошибки. Вас ждут ама-сессии со спикерами, обмен кейсами с единомышленниками и куратор, который поможет сформировать мотивацию на обучение.
Кстати, видеокурс доступен уже сейчас.
Узнать подробнее: https://slurm.club/3ehOUqr
onegreyonewhite
Считаю ужасной практикой в livenessProbe делать http-запросы. Это проверка, что контейнер не зомби, т.е. запущены нужные процессы. Эту проверку надо делать максимально часто, чтобы мёртвый процесс действительно мёртв был. И эта проверка не должна ни в коем случае зависеть от нагрузки и сокетов. А то получится, что у вас нагрузка выросла и контейнер делает себе харакири. В итоге на другие распределяется нагрузка, и они тоже делают себе харакири. Кластер лежит, пользователи недоумевают, CTO порет ремнем SRE - такая себе картина.
Для readinessProbe это нормально и если сильно нагрузка бахнула, то они действительно могут и должны на время выпасть из обмена, пока не переварят. Такую проверку можно делать реже, чтоб тоже не загадить подключения. Но эта проверка действительно будет делать то, что нужно - проверять, что сервис может принимать подключения и обрабатывать их.
Например, в приведённом деплойменте nginx, можно было бы проверить наличие процесса nginx для проверки жизни в контейнере, что прям сложность O(1) имеет. Тогда период можно в одну секунду поставить, чтоб мгновенно пезагрузить. А читабельность оставить как есть. Но для Cloud Native лучше livenessProbe отдельно реализовывать: проверять, что нужный процесс не просто запущен, но имеется активность внутри. Если это какой-то циклический обработчик, то можно писать файлик (даже пустой) и проверять время последнего изменения.