В Kubernetes существует три типа проб, предназначенных для проверки работоспособности подов. В этой статье рассказано, как использовать эти пробы, а также объяснены отличия между ними.

Пробы — важнейшая возможность Kubernetes, обеспечивающая удобное предоставление услуг, что незаменимо для конечных пользователей. По своей сути пробы регулярно отслеживают, может ли под адекватно обрабатывать трафик, и при необходимости принимают меры, например, выполняют перезапуск.

ReadinessProbe: Обеспечение готовности службы

Что такое ReadinessProbe?

ReadinessProbe — это ресурс, который следует учитывать при создании сервиса.

Сервис направляет трафик на поды, соответствующие его YAML-меткам, не проверяя состояние пода. Если после запуска пода требуется время для конфигурации, то он может быть не готов к обработке входящего трафика, что приведет к ошибкам.

Для решения этой проблемы используется ReadinessProbe. Сконфигурировав ReadinessProbe в YAML-файле пода, можно просигнализировать управляющему слою Kubernetes, чтобы тот не направлял трафик от сервиса к поду, пока он не будет готов.

Как настроить ReadinessProbe

Существует три основных паттерна для создания ReadinessProbe:

1. HTTP: Проверяет готовность пода, отправляя HTTP-запрос. Код ответа от 200 до 399 указывает на готовность.
2. Команда: Определяет готовность путем выполнения команды. Если команда возвращает код выхода, равный 0, значит, под готов.
3. TCP: Проверяет готовность, пытаясь установить TCP-соединение. Успешно установленное соединение означает готовность.

Давайте рассмотрим каждый из этих случаев на примерах:

1. HTTP:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-readinessprobe
spec:
  containers:
  - name: nginx
    image: nginx
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

Здесь initialDelaySeconds задает время ожидания перед первой проверкой работоспособности, а periodSeconds — частоту проверок. Эта конфигурация отправляет HTTP GET-запрос на конечную точку /ready через 5 секунд после запуска пода и затем с интервалом 5 секунд. Если код состояния HTTP находится в диапазоне 200-399, под считается готовым и начинает принимать запросы от службы.

2. Команда

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      initialDelaySeconds: 5
      periodSeconds: 5

Этот шаблон задает команду. Если cat /tmp/ready возвращает код выхода, равный 0 (что означает, что файл существует), то под считается готовым. Ваше приложение должно быть запрограммировано на создание этого файла, когда он будет готов.

3.TCP

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

В этом шаблоне вы указываете TCP-порт. Под готов, если он может принимать соединения через TCP-порт 80. Это полезно для приложений, которые не используют HTTP или не могут разместить определенный файл.

При разработке реальных приложений эффективнее применять вызов конечных точек, связанных с состоянием приложения. Например, если приложение использует базу данных, вы можете вызвать внутреннюю страницу, которая открывает соединение с MySQL, чтобы подтвердить, что приложение может взаимодействовать с базой данных. Вместо простой страницы, возвращающей 200, тестовая страница, которая действительно пытается установить соединение с базой данных, повышает надёжность приложения.

LivenessProbe: Поддержание активности вашего приложения

Что такое LivenessProbe?

Проба LivenessProbe аналогична ReadinessProbe. В то время как ReadinessProbe позволяет просигнализировать о готовности пода к обработке трафика, LivenessProbe используется для постоянной проверки работоспособности.

Сервисы не могут определить, активен под или нет, и могут продолжать посылать трафик на неработающий под.

Установив LivenessProbe, Kubernetes постоянно проверяет состояние пода. При обнаружении каких-либо проблем он перезапускает под.

Как настроить LivenessProbe

Шаблоны настройки такие же, как и для ReadinessProbe. Давайте рассмотрим все методы настройки по очереди.

1.HTTP

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-livenessprobe
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

В этом примере для проверки состояния используется HTTP-запрос GET. Он отправляет запрос на конечную точку /health через 15 секунд после запуска пода и каждые 20 секунд после этого. Если код ответа находится в диапазоне 200-399, то под считается исправным.

2. Команда

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 15
      periodSeconds: 20

В этом примере выполняется cat /tmp/healthy. Если код выхода равен 0 (файл существует), то под исправен.

3.TCP

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

В этом примере с сокетом TCP состояние пода определяется по тому, способен ли он принимать соединения через порт TCP 80.

StartupProbe: Работа с медленно запускающимися приложениями

Что такое StartupProbe?

StartupProbe — это относительно новая функция, появившаяся в Kubernetes 1.16 в виде альфа-версии и усовершенствованная в последующих версиях. Она стала стабильной в Kubernetes 1.20.

StartupProbe предназначена для проверки работоспособности приложений, которые долго запускаются. В отличие от LivenessProbe и ReadinessProbe, StartupProbe выполняется только во время начального запуска контейнера.

Для приложений, запуск которых занимает много времени, LivenessProbe может преждевременно определить, что Под неисправен, и вызвать перезапуск. StartupProbe решает эту проблему, временно приостанавливая проверки LivenessProbe и ReadinessProbe до тех пор, пока приложение не запустится и не стабилизируется.

Как настроить StartupProbe

Опять же, существует три варианта:

1.HTTP

apiVersion: v1
kind: Pod
metadata:
  name: slow-start-app
spec:
  containers:
  - name: myapp
    image: myapp
    startupProbe:
      httpGet:
        path: /start
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

В этом примере для проверки состояния запуска используется HTTP GET-запрос. Он отправляет запросы к конечной точке /start каждые 10 секунд. failureThreshold установлен на 30, что означает, что проба допустит до 30 отказов перед завершением работы пода.

2. Команда

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    startupProbe:
      exec:
        command:
        - cat
        - /tmp/start
      failureThreshold: 30
      periodSeconds: 10.

В этом примере проверяется состояние запуска путем выполнения команды cat /tmp/start. Приложение считается запущенным, если команда возвращает код выхода 0. Проверка происходит каждые 10 секунд, допускается до 30 сбоев.

3.TCP

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    startupProbe:
      tcpSocket:
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

В этом примере с TCP-сокетами приложение считается запущенным, если под может принимать соединения на TCP-порт 8080. Проверка происходит каждые 10 секунд, при этом допускается не более 30 сбоев.

Эффективное сочетание трех проб

В Kubernetes объединение ReadinessProbe, LivenessProbe и StartupProbe позволяет повысить надёжность за счет сокращения аномальных соединений и улучшает эффективность благодаря автоматизированному мониторингу состояния. Как объясняется, каждая проба служит своей цели, а при их сочетании можно осуществлять более детальный мониторинг и адекватно реагировать на текущее состояние приложений.

Роли трех проб

Давайте подытожим роли трех проб:

• StartupProbe: Используется при первом запуске приложения, особенно полезен для медленно запускающихся приложений. До тех пор, пока этот проба не будет успешной, работа LivenessProbe и ReadinessProbe приостановлена.
• LivenessProbe: Регулярно проверяет, запущено ли приложение, и перезапускает Под при обнаружении проблем.
• ReadinessProbe: Проверяет готовность приложения к обработке трафика, предотвращая маршрутизацию трафика до тех пор, пока готовность не будет установлена.

Пример конфигурации

Вот пример конфигурации в формате YAML, объединяющей три пробы:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp
    startupProbe:
      httpGet:
        path: /startup
        port: 8080
      failureThreshold: 30
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

В приведенном примере:

• StartupProbe: Контролирует запуск приложения, проверяя конечную точку /startup. Допускает до 30 сбоев, проверяя каждые 10 секунд, максимум 300 секунд.
• LivenessProbe: Начинает работу через 5 секунд после завершения проверок StartupProbe, проверяя корректность работы приложения через конечную точку /health, и при необходимости перезапускает под. Проверки выполняются каждые 10 секунд.
• ReadinessProbe: Запускается через 5 секунд после завершения проверки StartupProbe, определяя, готово ли приложение к приему трафика через конечную точку /ready. Если приложение не готово, оно не будет принимать трафик. Проверки повторяются с интервалом в 5 секунд.

Правильно сочетая эти три пробы, вы можете убедиться, что приложение запускается правильно, работает стабильно и обрабатывает трафик в нужное время.

Для последних версий Kubernetes функции проверки работоспособности на основе grpc также доступны в альфа-версии. Более подробная официальная информация приведена на странице https://kubernetes.io/ja/docs/concepts/workloads/pods/pod-lifecycle/#probe-check-methods

Заключительные размышления

Используя возможности проб в Kubernetes, о которых рассказано в этой статье, можно повысить надёжность и отказоустойчивость приложений. В реальных условиях правильная настройка этих проб является ключевым фактором для поддержания качества обслуживания и повышения удобства работы пользователей. Я надеюсь, что эта статья пригодится вам в вашем путешествии по Kubernetes.