GKE Ingress медленно набирает готовность / живучесть пода

Мне удалось создать кластер с помощью GKE, успешно используя gce ingress. Однако Ingress долго определяет, что служба готова (я уже установил livenessProbe и readinessProbe). Мои поды настроены

Containers:
...
  gateway:
    Liveness:   http-get http://:5100/api/v1/gateway/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:5100/api/v1/gateway/healthz delay=0s timeout=1s period=10s #success=1 #failure=3
...

и вход

...
Name:             main-ingress
  Host                              Path  Backends
  ----                              ----  --------
  <host>
                                    /api/v1/gateway/    gateway:5100 (<ip:5100>)
                                    /api/v1/gateway/*   gateway:5100 (<ip:5100>)
                                                        web:80 (<ip>)
Annotations:
  ingress.kubernetes.io/backends:               {"k8s-be-***":"HEALTHY","k8s-be-***":"HEALTHY","k8s-be-***":"HEALTHY"}
  kubernetes.io/ingress.allow-http:             false

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

Я также заметил, что когда установлены livenessProbe и readinessProbe, проверка работоспособности Backend, генерируемая ingress-gce, выглядит следующим образом

Backend
Timeout: 30 seconds

Backend Health check
Interval: 70 seconds
Timeout: 1 second
Unhealthy threshold: 10 consecutive failures
Healthy threshold: 1 success

Если я просто разверну простой модуль nginx без указания livenessProbe и readinessProbe, сгенерированный бэкэнд будет следующим:

Backend
Timeout: 30 seconds

Backend Health Check
Interval: 60 seconds
Timeout: 60 seconds
Unhealthy threshold: 10 consecutive failures
Healthy threshold: 1 success

Является ли проверка работоспособности Backend основной причиной медленного получения данных? Если да, есть идеи, как это ускорить?


ОБНОВЛЕНИЕ Хотел уточнить, прочитав ответ @ yyyyahir ниже

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

Однако я также заметил, что когда я выпускаю новую версию службы (через Helm - для развертывания установлено значение Recreate, а не RollingUpgrade) ИЛИ, если модуль умер (нехватка памяти) и перезапущен, требуется некоторое время, прежде чем бэкэнд снова работает, несмотря на то, что Pod уже находится в рабочем / работоспособном состоянии (это с существующими Ingress и Load Balancer в GCP). Есть ли способ ускорить это?


person GantengX    schedule 17.12.2019    source источник


Ответы (1)


При использовании GCE Ingress необходимо дождаться времени инициализации балансировщика нагрузки до бэкэнда. сервис считается исправным.

Учтите, что при использовании этого класса входящего трафика вы полагаетесь на инфраструктуру GCE, которая автоматически должна предоставлять балансировщик нагрузки HTTP (S) и все его компоненты перед отправкой запросов в кластер.

Когда вы настраиваете развертывание без readinessProbe, значения по умолчанию будут применены к проверке работоспособности балансировщика нагрузки:

Backend Health Check
Interval: 60 seconds
Timeout: 60 seconds
Unhealthy threshold: 10 consecutive failures
Healthy threshold: 1 success

Однако использование readinessProbe добавит значение readinessProbe к конфигурации проверки работоспособности по умолчанию. Итак, в вашем случае у вас было 10 секунд + 60 по умолчанию = 70.

Backend Health check
Interval: 70 seconds
Timeout: 1 second
Unhealthy threshold: 10 consecutive failures
Healthy threshold: 1 success

Обратите внимание, что GKE будет использовать readinessProbe только для установки проверки работоспособности в балансировщике нагрузки. Живучесть никогда не выбирается.

Это означает, что наименьшее значение всегда будет значением проверки работоспособности балансировщика нагрузки по умолчанию, 60. Поскольку эти значения устанавливаются автоматически при вызове балансировщика нагрузки из GKE, изменить их невозможно.

Подводя итоги, вы должны дождаться периода подготовки балансировщика нагрузки (примерно 1-3 минуты) плюс значение periodSeconds, установленное в вашем readinessProbe.

person yyyyahir    schedule 17.12.2019
comment
Спасибо за ответ и ссылку на код! Я пытался посмотреть код ingress-gce, но не нашел. Я обновил свой вопрос, чтобы прояснить свой вопрос (который я пропустил ранее). Есть мысли по этому поводу? - person GantengX; 17.12.2019
comment
Я попытался воспроизвести информацию, которую вы опубликовали. Я постоянно скручивал развертывание рабочих 3 реплик. Я провалил это с помощью двух тестов: сначала уменьшил масштаб до 0, а второй обновил ошибочным изображением. Оба сразу начали возвращать 502-е. Я заметил, что когда я масштабировал / повторно развертывал рабочий образ, потребовалось около 20 секунд, чтобы начать нормально обслуживать запросы (учтите, что на тот момент ни одна реплика не была исправной). Ты об этом говоришь? Я также заметил, что веб-интерфейс почти никогда не выбирал изменения, и потребовалось много времени, чтобы пометить BE как работоспособный / нездоровый, не так ли? - person yyyyahir; 18.12.2019
comment
Кроме того, где вы видите ошибку? Как вы измеряете эту задержку? - person yyyyahir; 18.12.2019
comment
Ага, именно так, как вы описали. На самом деле я не проводил должного измерения задержки, но в целом мой опыт составляет около ~ 1 минуты перед обычным обслуживанием запроса. Не уверен, что можно что-то сделать на данный момент, если честно - person GantengX; 19.12.2019
comment
Судя по всей этой информации, переменная здесь - это развернутое изображение. Если вы установите минимальные значения для readinessProbe, это может быть связано с процессом в вашем собственном контейнере, политика извлечения изображений, контейнеры инициализации (если есть) и т. д. Возможно, лучший способ решить эту проблему - это проверить там. - person yyyyahir; 23.12.2019
comment
Верно. Посмотрим на это. Спасибо! - person GantengX; 24.12.2019