Готовность Kubernetes Probe exec KO, проверка живучести же exec OK

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

Сконфигурированный как readinessProbe, двоичный файл не может связаться с моим сервером и получить необходимую информацию. Он подключается к TCP-сокету. Но он работает правильно, когда я настроил его как livenessProbe.

Конфигурация. Чтобы все заработало, я только изменил тип с readinessProbe на livenessProbe.

"readinessProbe": {
              "exec": {
                "command": [
                  "/opt/bin/ready_probe",
                  "--check_ready_traffic",
                  "--service=myServer-service"
                ]
              },
              "initialDelaySeconds": 60,
              "timeoutSeconds": 5
            },

Служба предназначена для сервера, чтобы зарегистрировать его хост и порт. Хорошо.

Используемая версия: kubernetes v1.1.0-origin-1107-g4c8e6f4

Спасибо.


kubernetes probe
person Clau St    schedule 29.02.2016    source источник
comment
Kubernetes не делает различий между двумя типами зондов. Он запускает одну и ту же логику выполнения для них обоих. Какие события вы видите при выходе из строя проверки готовности?   -  person Vishnu Kannan    schedule 02.03.2016
comment
Я также подумал, что логика exec такая же, но то, как запускается exec, очевидно, отличается от 2. Когда проверка готовности терпит неудачу, я получаю ожидаемый сигнал, отличный от 0, что для меня означает потерю связи (что Я вижу в журналах). Нет других событий, написанных kube   -  person Clau St    schedule 07.03.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

Нет никакой разницы в исполнении двух типов зондов - различаются только последствия:

  • сбой живучести: перезагружает контейнер, в конечном итоге
  • отказ готовности: отключает связь

В зависимости от вашего контейнера отказ живучести может быть относительно безобидным - вы можете даже не заметить этого.

Однако, когда вы используете зонд готовности, связь с вашим контейнером будет отключена до после прохождения зондирования. Это означает, что простое действие включения проблемы готовности с initialDelaySeconds: 60 предотвратит соединение службы с вашим модулем в течение первой минуты - независимо от состояния связанного контейнера. Эта задержка может иметь каскадные последствия, если зависимые модули / службы не настроены для ее обработки.

Для проверки живучести это " очень важно " для настройки initialDelaySeconds (как это было сделано в вопросе). Для проверки готовности это может быть не так важно - и вы можете предпочесть, чтобы он был равен нулю (по умолчанию), чтобы учитывают возможность более быстрого запуска.

Вот код: https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/prober

person Brent Bradburn    schedule 01.02.2019