Мы используем NLB в AWS, подключенном к нашему кластеру EKS через входной контроллер nginx. Некоторые из наших запросов получают случайный таймаут шлюза 504.
Мы думаем, что отладили проблему с нашим входом nginx. Основываясь на некоторых рекомендациях Stackoverflow, мы поигрались с заголовками Connection.
Мы также заметили другое поведение с нашим 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: "")
Заранее спасибо!
Мы думаем, что наша проблема была связана с этим:
Мы используем внутренний nlb с нашим контроллером входящего трафика nginx с целями, зарегистрированными по идентификатору экземпляра. Мы обнаружили, что таймаут 504 и X секунд ожидания имели место только в приложениях, которые совместно использовали узел с одной из реплик нашего входящего контроллера. Мы использовали комбинацию nodeSelectors, меток, taints и допусков, чтобы принудительно установить контроллеры входа на их собственный узел, и, похоже, это устранило таймауты.
Мы также изменили настройку externalTrafficPolicy на Local.
У меня была та же проблема, что и у J. Koncel, когда мои приложения, которые совместно использовали те же узлы, что и входной контроллер nginx, были единственными, у которых был таймаут 504.
Вместо использования nodeSelectors и taints / терпимости я использовал антиаффинность Pod: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity.
Я добавил метку в спецификацию для моего nginx-ingress-controller
podType: ingress
Затем я обновил файлы yml для приложений, которые не должны планироваться в том же экземпляре, что и nginx-ingress-controller, следующим образом:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: podType
operator: In
values:
- ingress
topologyKey: "kubernetes.io/hostname"
На данный момент я не могу комментировать, но следующая строка должна помочь вам добавить параметр externalTrafficPolicy:
kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'