![](https://habrastorage.org/getpro/habr/upload_files/016/d80/bc8/016d80bc86e41499073deb99d378aaca.png)
В Kubernetes есть механизм проверки работоспособности, с помощью которого можно узнать, работает контейнер в pod’е или нет.
![Источник: https://wideops.com/ Источник: https://wideops.com/](https://habrastorage.org/getpro/habr/upload_files/627/b04/acb/627b04acb29627331cf0cbcd1ed7565a.gif)
Проверка работоспособности 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)
Проба работоспособности проверяет, выполняется контейнер или нет.
Если проба не находит живой контейнер, автоматически выполняется политика перезапуска контейнера.
![Источник: https://wideops.com/ Источник: https://wideops.com/](https://habrastorage.org/getpro/habr/upload_files/671/e13/aae/671e13aaebff7cc61b977618bed39128.gif)
Проба готовности (readiness)
Проба готовности проверяет, готово ли приложение обслуживать запросы.
Если не готово, IP pod’а удаляется из списка конечных точек сервиса.
![Источник: https://wideops.com/ Источник: https://wideops.com/](https://habrastorage.org/getpro/habr/upload_files/b1d/6c8/f66/b1d6c8f666e83d156f40afc50b4b0bec.gif)
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 отдельно реализовывать: проверять, что нужный процесс не просто запущен, но имеется активность внутри. Если это какой-то циклический обработчик, то можно писать файлик (даже пустой) и проверять время последнего изменения.