Блог

У меня есть служба приложений, работающая с 2 модулями, которые получают трафик от другой службы в кластере Kubernetes.

Я столкнулся с проблемой, из-за которой мои модули прекращают работу и не выполняют запросы на полет.

Поэтому, чтобы исправить это, я добавил перехват предварительной остановки жизненного цикла модуля pod, чтобы ждать 250 секунд для завершения всех ожидающих запросов и установить terminationGracePeriodSeconds равным 300 секундам.

 lifecycle:
  preStop:
    exec:
      command:
      - /bin/sleep
      - "250"
 

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

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

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

Затем я вхожу в узел и проверяю IPtables, чтобы получить правила пересылки таблицы IP, чтобы проверить, сохраняется ли IP-адрес модуля, но правила пересылки IP-таблиц были обновлены сразу же, когда модуль переходит к завершению.

 >sudo iptables -t nat -L  KUBE-SVC-MYVS2X43QAGQT6BT -n | column -t
Chain                      KUBE-SVC-MYVS2X43QAGQT6BT  (1   references)
target                     prot                       opt  source       destination
KUBE-SEP-HDK3MJ4L3R3PLTOQ  all                        --   <IP>    <IP>    /*  default/test-cart-service:http  */  statistic  mode  random  probability  0.50000000000
KUBE-SEP-237VYZFMFXN2THCB  all                        --   <IP>    <IP>    /*  default/test-cart-service:http  */

>sudo iptables -t nat -L KUBE-SEP-HDK3MJ4L3R3PLTOQ -n | column -t
Chain           KUBE-SEP-HDK3MJ4L3R3PLTOQ  (1   references)
target          prot                       opt  source          destination
KUBE-MARK-MASQ  all                        --   <IP>  <IP>    /*  default/test-cart-service:http  */
DNAT            tcp                        --   <IP>  <IP>  /*  default/test-cart-service:http  */  tcp  to:<IP>:<PORT>

>sudo iptables -t nat -L KUBE-SEP-HDK3MJ4L3R3PLTOQ -n | column -t
iptables: No chain/target/match by that name.

 

Таким образом, таблицы были немедленно обновлены kube-прокси, но, тем не менее, модуль получает трафик.

Я попытался перенаправить службу напрямую, а также подключить ее к сетевому потоку (ELB-> Ingress-> Service-> pod), думая, что это может быть проблема с балансировкой нагрузки, но результаты те же.

K8s управляется Amazon EKS (1.20), а входная служба отображается на Amazon classic Load Balancer (ELB).

Я не уверен, чего мне не хватает. Если это ошибка EKS или что-то связанное с поведением k8s.

Обновить:

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