208
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Обзор и использование проб в Kubernetes

Время чтения 3 минуты
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
208
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Привет! На связи Александр Бархатов, я DevOps-инженер в крупнейшем продуктовом холдинге. При использовании Kubernetes нужно быть внимательным: при запуске приложения нужно убедиться, что оно отвечает, например, на сетевые запросы. Проверить, как работает приложение, можно с механизмом проб (probes). Сегодня мы рассмотрим Liveness Probe, Readiness Probe и Startup Probe и разберемся, чем они облегчают жизнь разработчикам.

Обзор и использование проб в Kubernetes

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 и рассмотрели, как их применять. С таким инструментом гораздо легче следить за состоянием приложений в запуске, но важно пользоваться им правильно: некорректная настройка проб может ухудшить работоспособность приложений.

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники