Являются ли отказы зонда живучести Kubernetes добровольными или непроизвольными сбоями?

У меня есть приложение, развернутое в Kubernetes, которое зависит от внешнего приложения. Иногда соединение между этими двумя переходит в недопустимое состояние, и это можно исправить только путем перезапуска моего приложения.

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

Это отлично работает, однако я боюсь, что если это внешнее приложение выйдет из строя (например, ошибка подключения возникнет не только из-за недопустимого состояния модуля), все мои модули немедленно перезапустятся, и мое приложение станет полностью недоступен. Я хочу, чтобы он продолжал работать, чтобы функциональность, не зависящая от плохой службы, могла продолжаться.

Мне интересно, предотвратит ли этот сценарий бюджет нарушения работы модуля, поскольку он ограничивает количество модулей из-за добровольного сбоя. Однако в документации K8s не указывается, является ли отказ датчика живучести добровольным нарушением. Они?


kubernetes livenessprobe
person roim    schedule 27.04.2021    source источник
comment
Возможно ли перенести внешнее приложение в ваш кластер Kubernetes? Это не даст прямого ответа на ваш вопрос, но я думаю, вы могли бы взглянуть на следующие статьи: 1, 2, 3   -  person Dawid Kruk    schedule 27.04.2021
comment
@DawidKruk, внешнее приложение, к сожалению, - это Azure CosmosDB, у которого нет лучших клиентских драйверов для среды, в которой я нахожусь. Однако у меня были аналогичные проблемы с использованием ioredis для подключения к моему собственному кластеру Redis, поэтому я посмотрю. Спасибо!   -  person roim    schedule 27.04.2021

Ответы (2)


arrow_upward
1
arrow_downward

Я бы сказал, согласно документации:

Добровольные и непроизвольные сбои

Поды не исчезают, пока кто-то (человек или контроллер) не уничтожит их, или пока не произойдет неизбежная ошибка оборудования или системного программного обеспечения.

Мы называем эти неизбежные случаи непроизвольными сбоями приложения. Примеры:

  • аппаратный сбой физической машины, поддерживающей узел
  • администратор кластера по ошибке удаляет ВМ (экземпляр)
  • сбой облачного провайдера или гипервизора приводит к исчезновению виртуальной машины
  • паника ядра
  • узел исчезает из кластера из-за сетевого раздела кластера
  • выселение модуля из-за того, что узел вне ресурсов < / а>.

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

Остальные случаи мы называем добровольными нарушениями. К ним относятся как действия, инициированные владельцем приложения, так и действия, инициированные администратором кластера. Типичные действия владельца приложения включают:

  • удаление развертывания или другого контроллера, который управляет модулем
  • обновление шаблона модуля развертывания, вызывающее перезапуск
  • прямое удаление модуля (например, случайно)

Действия администратора кластера включают:

- Kubernetes.io: Документы: Концепции: Рабочие нагрузки: Модули: Сбои

Итак, ваш пример совершенно другой, и, насколько мне известно, это не добровольное или непроизвольное нарушение.

Также взгляните на другую документацию Kubernetes:

Срок службы стручка

Как и отдельные контейнеры приложений, поды считаются относительно эфемерными (а не долговечными) объектами. Поды создаются, им присваивается уникальный идентификатор (UID) и запланированы на узлы, где они остаются до завершения (в соответствии с политикой перезапуска) или удаления. Если узел умирает, то запланированные для этого узла модули являются запланировано на удаление по истечении периода ожидания.

Стручки сами по себе не восстанавливаются. Если модуль Pod запланирован на узел, который затем выходит из строя, модуль удаляется; Точно так же Pod не переживет выселение из-за нехватки ресурсов или обслуживания узла. Kubernetes использует абстракцию более высокого уровня, называемую контроллером, который обрабатывает работу управление относительно одноразовыми экземплярами Pod.

- Kubernetes.io: Документы: Концепции: Рабочие нагрузки: модули: жизненный цикл модуля: время существования модуля

Контейнерные зонды

Кубелет может опционально выполнять и реагировать на три типа зондов при запущенных контейнерах (с акцентом на livenessProbe):

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

- Kubernetes.io: Документы: Концепции: Рабочие нагрузки: модули: жизненный цикл модуля: зонды контейнеров

Когда следует использовать зонд живучести?

Если процесс в вашем контейнере может аварийно завершиться самостоятельно, когда он сталкивается с проблемой или становится нездоровым, вам не обязательно нужна проверка живучести; кубелет автоматически выполнит правильное действие в соответствии с restartPolicy пода.

Если вы хотите, чтобы ваш контейнер был остановлен и перезапущен в случае сбоя зондирования, укажите зонд живучести и укажите restartPolicy из Always или OnFailure.

- Kubernetes.io: Документы: Концепции: Рабочие нагрузки: Модули: Жизненный цикл модуля: Когда следует использовать пробу запуска

Согласно этой информации, было бы лучше создать настраиваемый зонд жизнеспособности, который должен учитывать внутренние проверки работоспособности процесса и проверку работоспособности внешних зависимостей (жизнеспособности). В первом сценарии ваш контейнер должен остановить / завершить ваш процесс, в отличие от второго случая с внешней зависимостью.

Отвечая на следующий вопрос:

Мне интересно, предотвратит ли этот сценарий бюджет сбоя модуля.

В этом конкретном случае PDB не поможет.

Я считаю, что придание большей видимости комментарию, который я сделал с дополнительными ресурсами по этому вопросу, может оказаться полезным для других членов сообщества:

person Dawid Kruk    schedule 13.05.2021

arrow_upward
0
arrow_downward

Мне интересно, предотвратит ли этот сценарий бюджет сбоя модуля.

Да, помешает.

Как вы заявили, когда pod выходит из строя (или сбой узла), ничто не может сделать поды недоступными. Однако для некоторых служб требуется, чтобы всегда работало минимальное количество модулей.

Может быть и другой способ (Stateful resource), но это один из простейших доступных ресурсов Kubernetes.

Примечание. Вы также можете использовать процентное значение вместо абсолютного числа в поле minAvailable. Например, вы можете указать, что 60% из всех модулей с меткой app=run-always должны быть запущены постоянно.

person Gupta    schedule 27.04.2021
comment
ОП спрашивал о добровольных сбоях. Из их вопроса похоже, что они уже знают о PDB. - person zerkms; 27.04.2021
comment
да, они знают, но согласно его требованию. Это минимальные усилия для достижения. Я отредактировал свой ответ. Пусть он вернется и поделится своим мнением ... Кроме того, это то, что требует более тщательного исследования, чем прямого ответа. Согласовано? - person Gupta; 27.04.2021
comment
Да, помешает. --- вы уверены, что PDB не позволяет зондам живучести перезапустить модуль? - person zerkms; 27.04.2021
comment
@Gupta Мне нужно согласиться с вами по поводу вашего последнего комментария. Не могли бы вы отредактировать свой ответ в поддержку последнего сделанного вами комментария (с loose-loose ситуацией), чтобы он был более заметным и более четко объяснил обстоятельства? - person Dawid Kruk; 27.04.2021
comment
Редактировать комментарии- Я не это имел в виду. Это то, что необходимо решить на уровне приложения. С одной стороны, PDB пытается сделать модуль готовым в соответствии с его природой реализации, а с другой стороны, Liveness Probe попытается перезапустить модуль, чтобы сделать его работоспособным. - person Gupta; 27.04.2021
comment
@Gupta, есть ли у вас какие-либо ссылки или тесты, подтверждающие это? В противном случае мне, возможно, придется в ближайшем будущем запустить свой собственный - person roim; 28.04.2021
comment
Для справки я бы посоветовал поискать Kubernetes в книге действий manning.com / books / kubernetes-in-action? query = kuber, глава 15 - person Gupta; 28.04.2021
comment
@ roim- Считаете ли вы, что мой ответ приемлем, если да, примите. - person Gupta; 02.05.2021