В Kubernetes есть механизм проверки работоспособности, с помощью которого можно узнать, работает контейнер в pod’е или нет.

Источник: https://wideops.com/
Источник: https://wideops.com/

Проверка работоспособности kubelet поддерживает три типа проверок работоспособности: 

  1. Проба запуска (startup).

  2. Проба работоспособности (liveness).

  3. Проба готовности (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/

Проба готовности (readiness)

Проба готовности проверяет, готово ли приложение обслуживать запросы.

Если не готово, IP pod’а удаляется из списка конечных точек сервиса.

Источник: https://wideops.com/
Источник: https://wideops.com/

kubelet производит с pod’ом три типа действия:

  1. Выполняет команду в контейнере.

  2. Проверяет состояние определённого порта в контейнере.

  3. Выполняет запрос 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: ~

Настройка проб

В пробах можно настроить несколько значений:

  1. initialDelaySeconds: через сколько секунд после запуска контейнера начинаются пробы работоспособности или готовности.
    По умолчанию — 0 секунд. Минимальное значение — 0.

  2. periodSeconds: сколько секунд проходит между пробами.
    По умолчанию — 10 секунд. Минимальное значение — 1.

  3. timeoutSeconds: через сколько секунд истекает время ожидания пробы.По умолчанию — 1 секунда. Минимальное значение — 1.

  4. successThreshold: сколько проб подряд должно завершиться успехом, чтобы проверка считалась успешной после проваленной пробы.
    По умолчанию — 1. Для пробы работоспособности должно быть 1. Минимальное значение — 1.

  5. 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 можно настроить дополнительные параметры:

  1. path: путь для доступа на HTTP-сервере.

  2. port: имя или номер порта для доступа к контейнеру. Номер должен находиться в диапазоне от 1 до 65535.

  3. host: имя хоста для подключения; по умолчанию — IP pod’а. Можно задать хост в заголовках HTTP.

  4. httpHeaders: кастомные заголовки для запроса. HTTP разрешает повторяющиеся заголовки.

  5. 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

Комментарии (1)


  1. onegreyonewhite
    10.10.2022 19:46
    +3

    Считаю ужасной практикой в livenessProbe делать http-запросы. Это проверка, что контейнер не зомби, т.е. запущены нужные процессы. Эту проверку надо делать максимально часто, чтобы мёртвый процесс действительно мёртв был. И эта проверка не должна ни в коем случае зависеть от нагрузки и сокетов. А то получится, что у вас нагрузка выросла и контейнер делает себе харакири. В итоге на другие распределяется нагрузка, и они тоже делают себе харакири. Кластер лежит, пользователи недоумевают, CTO порет ремнем SRE - такая себе картина.

    Для readinessProbe это нормально и если сильно нагрузка бахнула, то они действительно могут и должны на время выпасть из обмена, пока не переварят. Такую проверку можно делать реже, чтоб тоже не загадить подключения. Но эта проверка действительно будет делать то, что нужно - проверять, что сервис может принимать подключения и обрабатывать их.

    Например, в приведённом деплойменте nginx, можно было бы проверить наличие процесса nginx для проверки жизни в контейнере, что прям сложность O(1) имеет. Тогда период можно в одну секунду поставить, чтоб мгновенно пезагрузить. А читабельность оставить как есть. Но для Cloud Native лучше livenessProbe отдельно реализовывать: проверять, что нужный процесс не просто запущен, но имеется активность внутри. Если это какой-то циклический обработчик, то можно писать файлик (даже пустой) и проверять время последнего изменения.