Микросервисное управление временем готовности и готовности - PullRequest
Новая
       2

Микросервисное управление временем готовности и готовности

0 голосов
/ 17 апреля 2020

У меня есть модули, развернутые в кластере kubernetes, с некоторыми запросами HTTPS. Я делаю нагрузочное тестирование для API с одновременными пользователями в секунду.

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

liveness:
  initialDelaySeconds: 60
  periodSeconds: 20
  timeoutSeconds: 60
  successThreshold: 1
  failureThreshold: 4

readiness:
  initialDelaySeconds: 60
  periodSeconds: 20
  timeoutSeconds: 60
  successThreshold: 1
  failureThreshold: 4

livenessProbe:
   httpGet:
    path: /health
    port: 8000
    scheme: HTTPS
readinessProbe            
   httpGet:
    path: /health
    port: 8000
    scheme: HTTPS

Как мне избежать этих сбоев? Это из-за того, что мое приложение не может обслуживать запросы на живость?

1 Ответ

0 голосов
/ 20 апреля 2020

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

Пожалуйста, проверьте описание pod для журналов событий, которые приводят к перепланированию модуля, это можно сделать с помощью kubectl describe pod <pod_name>. Возможно, у вашего модуля недостаточно памяти или процессора, поэтому вы можете посмотреть запросы и ограничения в Управление вычислительными ресурсами для контейнеров .

Вы упомянули, что готовность и liveness пробники не работают во время выполнения теста, что указывает на то, что вы используете http / https до предела, который больше не может обслуживать запросы.

Чтобы выполнить пробу, кублет отправляет запрос HTTPS GET на сервер, который работает в контейнере и прослушивает порт 8000. Если обработчик для пути сервера /health возвращает код успеха, то кублет считает контейнер живым и исправным. Если обработчик возвращает код ошибки, кублет убивает контейнер и перезапускает его.

Любой код, больший или равный 200 и меньший, чем 400, указывает на успех. Любой другой код указывает на сбой.

Чтобы смягчить эти сбои, вы можете увеличить timeoutSeconds и / или failureThreshold, но я думаю, что вы должны работать над процессом, обслуживающим запросы.

Также я рекомендую прочитать это замечательное руководство. Лучшие практики Kubernetes: Настройка проверок состояния здоровья с помощью датчиков готовности и живучести .

...