Как зонд Живости / Готовности связывается со стручком?

Question

Я очень новичок в k8s, поэтому извиняюсь, если вопрос не имеет смысла или является неправильным / глупым.

У меня настроен датчик живучести для моего определения модуля, который просто подключается к API работоспособности и проверяет его статус ответа, чтобы проверить его работоспособность.

У меня вопрос, хотя я понимаю, цель исследования жизнеспособности / готовности ... что именно они? Являются ли они просто еще одним типом модулей, которые запускаются, чтобы попытаться связаться с нашим модулем через настроенный API? Или это какой-то легкий процесс, который выполняется внутри самого модуля и пытается выполнить вызов API?

Кроме того, как зонд взаимодействует с модулем? Нужно ли нам настраивать службу для модуля, чтобы зонд мог получить доступ к API, или это внутренний процесс без дополнительной настройки?

Answer 1

Краткий ответ: kubelet обработайте эти проверки, чтобы убедиться, что ваша служба работает, и если нет, она будет заменена другим контейнером. Kubelet работает на каждом узле вашего кластера, вам не нужно настраивать какие-либо дополнительные параметры.

Вам не нужно , чтобы настроить служебную учетную запись для работы зондов, это внутренний процесс, обрабатываемый kubernetes.

Из Kubernetes документация :

A Зонд является диагностикой c, периодически выполняемой Кубеле на контейнере. Чтобы выполнить диагностику c, kubelet вызывает обработчик , реализованный Контейнером. Существует три типа обработчиков:

• ExecAction : выполняет указанную команду внутри контейнера. Диагностика c считается успешной, если команда завершается с кодом состояния 0.

• TCPSocketAction : выполняет проверку TCP по IP-адресу контейнера на указанный порт. Диагностика c считается успешной, если порт открыт.

• HTTPGetAction : выполняет HTTP-запрос Get против IP-адреса контейнера на указанном порту и пути , Диагностика c считается успешной, если ответ имеет код состояния больше или равный 200 и меньше 400.

Каждый зонд имеет один из трех результатов:

• Успех: Контейнер прошел диагностику c.
• Сбой: Контейнер не прошел диагностику c.
• Неизвестно: Диагностика c не выполнена, поэтому нет необходимо выполнить действие.

При желании kubelet может выполнять и реагировать на три типа датчиков при работе контейнеров:

• livenessProbe: указывает, является ли контейнер это работает. В случае сбоя датчика жизнеспособности кублет убивает Контейнер, и Контейнер подвергается политике перезапуска . Если Контейнер не обеспечивает проверку живучести, состояние по умолчанию: Success.

• readinessProbe: Указывает, готов ли Контейнер к запросам на обслуживание. В случае сбоя проверки готовности контроллер конечных точек удаляет IP-адрес модуля из конечных точек всех служб, соответствующих модулю. Состояние готовности по умолчанию до начальной задержки составляет Failure. Если Контейнер не обеспечивает проверку готовности, по умолчанию используется состояние Success.

• startupProbe: указывает, запущено ли приложение в Контейнере. Все остальные зонды отключаются, если предоставляется пробный запуск, пока он не будет успешным. Если пробный запуск завершается неудачно, kubelet убивает Контейнер, и Контейнер подвергается политике перезапуска . Если Контейнер не предоставляет пробный запуск, состояние по умолчанию: Success.

Answer 2

Для сетевых датчиков они запускаются из кублета на узле, где работает модуль. Пробники Exe c запускаются по тому же механизму, что и kubectl exe c.