Тайм-аут Nginx на входе 504 на EKS с подключением NLB к входу на Nginx

Question

Мы используем NLB в AWS, подключенном к нашему кластеру EKS через входной контроллер nginx. Некоторые из наших запросов получают случайный тайм-аут 504.

Мы думаем, что отладили проблему до нашего входа в nginx. Основываясь на некоторых рекомендациях Stackoverflow, мы поиграли с заголовками подключений. 1) Устанавливаем Connection "close", это никак не отразилось 2) Устанавливаем Connection "keep-alive" снова без эффекта

Мы также заметили другое поведение с нашим proxy_read_timeout, когда прошло 60 секунд, когда наш запрос от браузера будет выполнен за 60.xx секунд. Когда мы сократили его до 30, он стал 30.xx, 20 стал 20.xx. Мы перешли к 1, но все еще получаем случайные 504 тайм-аута шлюза и не понимаем, почему proxy_read_timeout имеет такое поведение в нашей среде.

Мы хотим понять, каков эффект proxy_read_timeout и почему мы получаем поведение выше? Также есть способ установить Connection "" на нашем входе в nginx (мы не можем сделать это через nginx.ingress.kubernetes.io/connection-proxy-header: "")

Заранее спасибо!

Answer 1

Мы думаем, что наша проблема была связана с этим:

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html#loopback-timeout

Мы используем внутренний nlb с нашим входным контроллером nginx, с целями, зарегистрированными по идентификатору экземпляра.Мы обнаружили, что 504 тайм-аута и X секунд ожидания происходят только в приложениях, которые совместно используют узел с одной из наших реплик входного контроллера.Мы использовали комбинацию nodeSelectors, label, taints и допусков, чтобы принудительно установить входные контроллеры на их собственный узел, и это, по-видимому, устранило тайм-ауты.

Мы также изменили настройку externalTrafficPolicy на Local.