#nginx #nginx-ingress
#nginx #nginx-вход
Вопрос:
Мы используем NLB в AWS, подключенный к нашему кластеру EKS через входной контроллер nginx. Некоторые из наших запросов получают случайный тайм-аут шлюза 504.
Мы думаем, что мы отладили проблему с нашим входом nginx. Основываясь на некоторых рекомендациях Stackoverflow, мы поиграли с заголовками соединений. 1) Мы установили соединение «закрыть», это не имело никакого эффекта 2) Мы снова установили соединение «keep-alive» без эффекта
Мы также заметили другое поведение с нашим proxy_read_timeout, когда прошло 60 секунд, наш запрос из браузера будет выполнен через 60.xx секунд. Когда мы уменьшили его до 30, оно стало 30.xx, 20 стало 20.xx. Мы перешли к 1, но по-прежнему получаем случайные тайм-ауты шлюза 504 и не понимаем, почему proxy_read_timeout имеет такое поведение в нашей среде.
Мы хотим понять, каков эффект proxy_read_timeout и почему мы получаем такое поведение? Также есть ли способ установить соединение «» на нашем входе nginx (мы не можем сделать это через nginx.ingress.kubernetes.io/connection-proxy-header : «»)
Заранее спасибо!
Комментарии:
1. StackOverflow не является общим сайтом технической поддержки. Может быть, попробовать ошибку сервера ?
2. Теперь я также добавил ошибку сервера — serverfault.com/questions/963116 /…
3. Хорошая работа. Теперь вы можете удалить этот вопрос.
Ответ №1:
Мы думаем, что наша проблема была связана с этим:
Мы используем внутренний nlb с нашим контроллером входа nginx, с целями, зарегистрированными по идентификатору экземпляра. Мы обнаружили, что 504 тайм-аута и X секунд ожидания происходили только в приложениях, которые совместно использовали узел с одной из наших реплик контроллера входа. Мы использовали комбинацию nodeSelectors, меток, искажений и допусков, чтобы принудительно установить контроллеры входа на их собственный узел, и, похоже, это устранило тайм-ауты.
Мы также изменили наш параметр externalTrafficPolicy на локальный.