Лимит одновременного подключения к нодпорту Kubernetes - PullRequest
Новая
       93

Лимит одновременного подключения к нодпорту Kubernetes

0 голосов
/ 15 декабря 2018

Я работаю в Kubernetes с AWS EKS.Я выполняю некоторые нагрузочные тесты для службы узлового порта и вижу ограничение одновременного соединения ~ 16k-20k при попадании на узел, на котором модуль не работает.Мне интересно, есть ли какой-нибудь способ увеличить количество одновременных подключений.

Итак, я запускаю службу нодпорта с только 1 модулем, который запланирован на узле А. Запущенный тест загрузки пытаетсяподключите как можно больше одновременных подключений к веб-сокету.Веб-сокеты просто спят и посылают сердцебиения каждые 30 секунд, чтобы поддерживать соединение.

Когда я указываю нагрузочный тестер (tsung) на узел A, я могу получить до 65k одновременных веб-сокетов, прежде чем модуль получит OOMKilled, поэтому память будетограничивающий фактор, и это нормально.Реальная проблема заключается в том, что когда я указываю нагрузочный тестер на узел B, и iptables kube-proxy перенаправляет соединение на узел A, внезапно я могу получить только около 16k-20k одновременных соединений websocket до того, как соединения начнут зависать.Согласно netstat, они застревают в состоянии SYN_SENT. 

netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n
...
20087 ESTABLISHED
30969 SYN_SENT

Единственное, что я могу проверить, это мой лимит контратаки, и он выглядит нормально.Вот что я получу для узла B. 

net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_max = 131072
net.nf_conntrack_max = 131072

Вот диапазон портов.Я не уверен, имеет ли это значение (я не уверен, что DNAT и SNAT используют порты), но диапазон, кажется, намного выше 16 тыс. 

net.ipv4.ip_local_port_range = 32768    60999

Ограничение дескриптора файла и настройки TCP ядраодинаковы для узла A и узла B, поэтому я думаю, что исключает их.

Есть ли что-то еще, что может ограничивать число одновременных соединений, пересылаемых через iptables / netfilter?

1 Ответ

0 голосов
/ 16 декабря 2018

У вас всегда будет худшая производительность при попадании в NodePort, где ваш модуль не работает.По сути, ваши пакеты проходят через дополнительные прыжки, пытаясь (через iptables) получить конечный пункт назначения.

Я бы рекомендовал использовать исходный IP для службы NodePort .По сути, исправьте вашу службу следующим образом: 

$ kubectl patch svc <your-service> -p '{"spec":{"externalTrafficPolicy":"Local"}}'

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

В качестве альтернативы, если вы хотите рассмотреть что-то более эффективное,Вы можете использовать прокси-режим ipvs или что-то вроде BPF / Cillium для наложения.

...