Есть ли способ настроить Istio для маршрутизации трафика на POD, который находится в состоянии завершения? - PullRequest
Новая
       8

Есть ли способ настроить Istio для маршрутизации трафика на POD, который находится в состоянии завершения?

0 голосов
/ 10 октября 2018

У меня есть кластер Kubernetes с двумя развернутыми сервисами: SvcA и SvcB - оба в сетке сервисов.

SvcA поддерживается одним Pod, SvcA_P1.Приложение в SvcA_P1 предоставляет HTTP-хук PreStop.При выполнении команды «kubectl сток» на узле, где находится SvcA_P1, Pod переходит в состояние «завершения» и остается в этом состоянии до тех пор, пока приложение не завершит свою работу (запрос на возврат не возвращается, и Kubernetes удаляет модуль).Работа для SvcA_P1 включает в себя выполнение текущих диалоговых (принадлежащих установленным сеансам) HTTP-запросов / ответов.Он может оставаться в состоянии «завершения» в течение нескольких часов, прежде чем завершится.

Когда Pod входит в фазу «завершения», появляется коляска Istio для удаления SvcA_P1 из пула.Запросы, отправленные SvcA_P1, например, из SvcB_P1, отклоняются с «нет работоспособного восходящего потока».

Есть ли способ настроить Istio / Envoy на:

  1. Продолжить отправку трафика / сеансовс привязкой к SvcA_P1 в состоянии «завершения»?
  2. Отклонять трафик без привязки сеанса к SvcA_P1 (без JSESSIONID, файлов cookie или специальных заголовков HTTP)?

Я играл сПравила назначения, изменяющие trafficPolicy.loadBalancer.consistentHash.[httpHeaderName|httpCookie] без удачи.Как только Посланник удаляет вышестоящий сервер, новое место назначения повторно хэшируется с использованием сокращенного набора серверов.

Спасибо,

Thor

1 Ответ

0 голосов
/ 10 октября 2018

Согласно документации Kubernetes , когда модуль должен быть удален, три вещи происходят одновременно:

  • Модуль Pod отображается как «Завершающий», когда указан в клиентских командах
  • Когда Kubelet видит, что Pod был помечен как завершающий, потому что на сервере API установлен «мертвый» таймер для Pod, он начинает процесс выключения pod.
    • Если модуль определил ловушку preStop, он вызывается внутри модуля.Если ловушка preStop все еще работает после истечения льготного периода, то шаг 2 вызывается с небольшим (2 секунды) продленным льготным периодом.
  • Pod удаляется из списка конечных точек для обслуживания,и больше не считаются частью набора запущенных модулей для контроллеров репликации.Блоки, которые медленно отключаются не могут продолжать обслуживать трафик, поскольку балансировщики нагрузки (например, прокси-сервер службы) удаляют их из своих вращений .

Как толькотак как Istio работает как ячеистая сеть ниже / позади Службы и сервисы Kubernetes больше не рассматривают Pod в состоянии завершения в качестве места назначения для трафика, настройка политик Istio мало помогает.

...