Почему Kubernetes сообщает о сбое проверки готовности, а также о сбое проверки живучести

У меня есть работающее развертывание Kubernetes моего приложения.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: my-app
        image: my-image
        ...
        readinessProbe:
          httpGet:
            port: 3000
            path: /
        livenessProbe:
          httpGet:
            port: 3000
            path: /

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

$ kubectl describe pod -l app=my-app

...
Events:
  Type    Reason     Age   From                                  Message
  ----    ------     ----  ----                                  -------
  Normal  Scheduled  4m7s  default-scheduler                     Successfully assigned XXX
  Normal  Pulled     4m5s  kubelet, pool-standard-4gb-2cpu-b9vc  Container image "my-app" already present on machine
  Normal  Created    4m5s  kubelet, pool-standard-4gb-2cpu-b9vc  Created container my-app
  Normal  Started    4m5s  kubelet, pool-standard-4gb-2cpu-b9vc  Started container my-app

Приложение имеет дефект и вылетает при определенных обстоятельствах. Я «вызываю» такое условие, а затем вижу следующее в событиях модуля:

$ kubectl describe pod -l app=my-app

...
Events:
  Type     Reason     Age               From                                  Message
  ----     ------     ----              ----                                  -------
  Normal   Scheduled  6m45s             default-scheduler                     Successfully assigned XXX
  Normal   Pulled     6m43s             kubelet, pool-standard-4gb-2cpu-b9vc  Container image "my-app" already present on machine
  Normal   Created    6m43s             kubelet, pool-standard-4gb-2cpu-b9vc  Created container my-app
  Normal   Started    6m43s             kubelet, pool-standard-4gb-2cpu-b9vc  Started container my-app
  Warning  Unhealthy  9s                kubelet, pool-standard-4gb-2cpu-b9vc  Readiness probe failed: Get http://10.244.2.14:3000/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  4s (x3 over 14s)  kubelet, pool-standard-4gb-2cpu-b9vc  Liveness probe failed: Get http://10.244.2.14:3000/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Normal   Killing    4s                kubelet, pool-standard-4gb-2cpu-b9vc  Container crawler failed liveness probe, will be restarted

Ожидается, что зонд живучести выйдет из строя и контейнер будет перезапущен. Но почему я вижу Readiness probe failed событие?


person Maksim Sorokin    schedule 07.10.2019    source источник
comment
У вас простая проблема. Либо ничего не обслуживает порт 3000 на пути / вашего приложения, либо kubelet не может достичь порта, поэтому время ожидания истекло.   -  person suren    schedule 07.10.2019


Ответы (4)


Как написал в комментарии @suren, проверка готовности по-прежнему выполняется после запуска контейнера. Таким образом, если определены оба теста живучести и готовности (а также fx, они одинаковы), и готовность, и тест живучести могут потерпеть неудачу.

Вот аналогичный вопрос с четким подробным ответом.

person Maksim Sorokin    schedule 08.10.2019

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

По умолчанию период проверки готовности составляет 10 секунд.

Вы можете узнать больше здесь: https://docs.openshift.com/container-platform/3.9/dev_guide/application_health.html

person Paul    schedule 07.10.2019
comment
Спасибо за комментарий. Но я явно продемонстрировал, что модуль работал более 5 минут без каких-либо ошибок проверки готовности. Только после вызова сбоя приложения в событиях появляется сбой зонда готовности. - person Maksim Sorokin; 07.10.2019
comment
Да, вначале модуль работает правильно, поэтому обе проверки в порядке, но когда вы завершаете работу приложения, порт 3000 больше не доступен (я полагаю), и поскольку обе проверки настроены для проверки этого порта, вы видите обе ошибки в События. Зонд готовности вызывается каждые 10 секунд, а не только при запуске. - person Paul; 07.10.2019

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

person Thomas    schedule 07.10.2019
comment
Но не следует ли использовать зонд готовности только до тех пор, пока модуль не будет запущен и работает? Я имею в виду, что после того, как капсула прошла зонд готовности, зонд готовности больше не проверяется? - person Maksim Sorokin; 07.10.2019
comment
Зонды готовности и живучести выполняются всегда, если они добавлены в yaml. Вы можете установить интервал, но он всегда проверяет. - person suren; 07.10.2019
comment
Проверка готовности постоянно оценивается, чтобы определить, должна ли конечная точка для модуля быть создана как часть службы (готово ли приложение к производственному трафику). Поскольку временная проблема может возникнуть в любой момент, проверка готовности выполняется, пока модуль работает. - person Thomas; 07.10.2019

предоставьте функцию / метод реализации на бэкэнде, вы можете создать / health с именем uri и написать здесь логику жизнеспособности, и готовность также может быть вашим выбором.

/ health uri, должен быть связан с реализацией функции, которая может вернуть код состояния 200, если все пойдет хорошо, иначе это может быть сбой

person Tushar Mahajan    schedule 07.10.2019