Связь между модулями, когда 2 модуля находятся на одном узле, время от времени дает сбой (EKS 1.13) - PullRequest
0 голосов
/ 24 октября 2019

Симптом

Запросы к приложениям время от времени дают http 504 или длительное время ожидания (кратное 12 с).

У нас есть проблема со связью pod-pod, когда 2 модуля находятся на одном и том же узле в kubernetes.

Например, от входа nginx в модуль приложения на одном и том же узле от модуля приложения до модуля. модуль приложения на том же узле от модуля приложения до модуля Rabbitmq Eventbus на том же узле

Наша инфраструктура

EKS с классическими ELB (как внутренними, так и внешними) (несеть lb) на службе доступа nginx. Службы балансировки нагрузки имеют внешнюю сеть, локальную политику. EKS 1.13 с версией узла 1.13.8 (eks optimized ami)

TCPDUMP

Folowing - полезный вывод tcpdump из модуля приложения, пытающегося подключиться к шине событий, котораявыходит из строя. Успешно выполняется после нескольких попыток, чаще всего (обычно после 12 с):

13: 44: 46.744764 IP customer-reports-service-5b4d8c48b-vj4db.35196> eventbus-rabbitmq.kube-system. svc.cluster.local.5672: Флаги [S], seq 1434468571, победа 26883, варианты [mss 8961, sackOK, TS val 4064032250 ecr 0, nop, wscale 7], длина 0

13: 44:46.751000 IP ip-10-0-161-173.eu-west-1.compute.internal> customer-reports-service-5b4d8c48b-vj4db: превышено время ICMP в пути, длина 68

информация об этомtcpdump: 1. модуль приложения делает запрос к модулю событий на том же узле 2. узел отправляет превышенное время icmp модулю приложения. Вероятно, запрос никогда не попадает в шину событий.

Возможный обходной путь

использует pod anti affinity, чтобы убедиться, что каждый модуль eventbus, каждый входной модуль nginx, каждый шлюз API работаетна разных узлах наши сервисы приложений

Но я ищу реальное решение проблемы.

Другая связанная ссылка

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip Режим шпильки в моей настройке EKS - это шпилька-вет. Существует следующая инструкция: убедитесь, что у Kubelet есть разрешение на работу в / sys на узле. Но я не уверен, как это сделать, так как на EKS интерфейсов cbr0 нет, он использует интерфейсы eni

1 Ответ

1 голос
/ 24 октября 2019

Хорошо, сразу после публикации вопроса AWS предоставил мне решение проблемы:

ВЫПУСК: https://github.com/aws/amazon-vpc-cni-k8s/issues/641

Понизьте плагин VPC CNI до v1.5.3 до1.5.5 выпущен: обновите daemonset и перезапустите все узлы

...