Я вижу повторные передачи между двумя модулями в кластере kubernetes, который я настраиваю. Я использую kube-маршрутизатор https://github.com/cloudnativelabs/kube-router для взаимодействия между хостами. Вот настройки:

host-a и host-b подключены к одним и тем же коммутаторам. Они находятся в одной сети L2. Оба подключены к вышеупомянутым коммутаторам с помощью связей LACP 802.3ad, и эти связи работают и работают должным образом.

pod-a и pod-b находятся на host-a и host-b соответственно. Я запускаю iperf3 между модулями и вижу ретрансляции.

root@pod-b:~# iperf3 -c 10.1.1.4
Connecting to host 10.1.1.4, port 5201
[  4] local 10.1.2.5 port 55482 connected to 10.1.1.4 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  1.15 GBytes  9.86 Gbits/sec  977   3.03 MBytes
[  4]   1.00-2.00   sec  1.15 GBytes  9.89 Gbits/sec  189   3.03 MBytes
[  4]   2.00-3.00   sec  1.15 GBytes  9.90 Gbits/sec   37   3.03 MBytes
[  4]   3.00-4.00   sec  1.15 GBytes  9.89 Gbits/sec  181   3.03 MBytes
[  4]   4.00-5.00   sec  1.15 GBytes  9.90 Gbits/sec    0   3.03 MBytes
[  4]   5.00-6.00   sec  1.15 GBytes  9.90 Gbits/sec    0   3.03 MBytes
[  4]   6.00-7.00   sec  1.15 GBytes  9.88 Gbits/sec  305   3.03 MBytes
[  4]   7.00-8.00   sec  1.15 GBytes  9.90 Gbits/sec   15   3.03 MBytes
[  4]   8.00-9.00   sec  1.15 GBytes  9.89 Gbits/sec  126   3.03 MBytes
[  4]   9.00-10.00  sec  1.15 GBytes  9.86 Gbits/sec  518   2.88 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  11.5 GBytes  9.89 Gbits/sec  2348             sender
[  4]   0.00-10.00  sec  11.5 GBytes  9.88 Gbits/sec                  receiver

iperf Done.

Подвох, который я пытаюсь отладить, заключается в том, что я не вижу повторных передач, когда запускаю один и тот же iperf3 напрямую через host-a и host-b (не через интерфейс моста, который создает kube-router). Итак, сетевой путь выглядит примерно так:

pod-a -> kube-bridge -> host-a -> L2 switch -> host-b -> kube-bridge -> pod-b

Удаление кубического моста из уравнения приводит к нулевым повторным передачам. Я проверил хост-a для pod-b и видел те же повторные передачи.

Я запускаю dropwatch и вижу следующее на принимающем хосте (по умолчанию сервер iperf3):

% dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
2 drops at ip_rcv_finish+1f3 (0xffffffff87522253)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
1 drops at __brk_limit+35f81ba4 (0xffffffffc0761ba4)
16991 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at tcp_v4_do_rcv+87 (0xffffffff87547ef7)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
2 drops at ip_rcv_finish+1f3 (0xffffffff87522253)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
3 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
16091 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at __brk_limit+35f81ba4 (0xffffffffc0761ba4)
1 drops at tcp_v4_do_rcv+87 (0xffffffff87547ef7)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
8463 drops at skb_release_data+9e (0xffffffff874c6a4e)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
2 drops at tcp_v4_do_rcv+87 (0xffffffff87547ef7)
2 drops at ip_rcv_finish+1f3 (0xffffffff87522253)
2 drops at skb_release_data+9e (0xffffffff874c6a4e)
15857 drops at skb_release_data+9e (0xffffffff874c6a4e)
1 drops at sk_stream_kill_queues+48 (0xffffffff874ccb98)
1 drops at __brk_limit+35f81ba4 (0xffffffffc0761ba4)
7111 drops at skb_release_data+9e (0xffffffff874c6a4e)
9037 drops at skb_release_data+9e (0xffffffff874c6a4e)

Отправляющая сторона видит капли, но ничего в тех количествах, которые мы видим здесь (1-2 макс на строку вывода; что, я надеюсь, нормально).

Кроме того, я использую 9000 MTU (на интерфейсе bond0 к коммутатору и на мосту).

Я использую CoreOS Container Linux Stable 1632.3.0. Имя хоста Linux 4.14.19-coreos # 1 SMP Ср. 14 февраля 03:18:05 UTC 2018 x86_64 GNU/Linux

Любая помощь или указатели будут высоко ценится.

обновление: пробовал с 1500 MTU, тот же результат. Значительные ретрансляции.

update2: кажется, что iperf3 -b 10G ... дает проблем между модулями и непосредственно на хосте (2x 10 Гбит NIC в LACP Bond). Проблемы возникают при использовании iperf3 -b 11G между модулями, но не между хостами. Является ли iperf3 умным в отношении размера сетевой карты, но не может использовать локальный мост?

|источник

3 ответа3

1

Автор кубе-роутера здесь. Kube-router использует плагин Bridge CNI для создания kube-bridge. Его стандартная сеть linux ничего специально не настроила для работы в сети. Для kube-bridge установлено значение по умолчанию 1500. У нас есть открытая ошибка, чтобы установить какое-то разумное значение.

https://github.com/cloudnativelabs/kube-router/issues/165

Как вы думаете, ошибки видны из-за меньшего MTU?

|источник
0

Похоже, что-то (NIC или ядро?) замедляет трафик при его выводе на интерфейс bond0 . В случае linux bridge (pod) "NIC" - это просто ветеран, который (когда я тестировал мой) достиг пика около 47 Гбит / с. Поэтому, когда iperf3 запрашивают отправку пакетов через интерфейс bond0 , он переполняет интерфейс и в результате отбрасывает пакеты (неясно, почему мы видим отбрасывание на принимающем хосте).

Я подтвердил, что если я применю класс tc qdisc для замедления интерфейса модуля до 10 Гбит / с, то при простом запуске iperf3 для другого модуля не будет никаких потерь.

tc qdisc add dev eth0 root handle 1:0 htb default 10
tc class add dev eth0 parent 1:0 classid 1:10 htb rate 10Gbit

Этого было достаточно, чтобы гарантировать, что запуск iperf3 без настройки пропускной способности не повлек за собой повторных передач из-за переполнения сетевого адаптера. Я буду искать способ замедлить потоки, которые выходили бы из NIC с помощью tc .

Обновление: Вот как можно замедлить трафик для всех, кроме локальной подсети с мостовым соединением.

tc qdisc add dev eth0 root handle 1:0 htb default 10
tc class add dev eth0 classid 1:5 htb rate 80Gbit
tc class add dev eth0 classid 1:10 htb rate 10Gbit
tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 10.81.18.4/24 classid 1:5
|источник
0

Нельзя, чтобы одно TCP-соединение превышало 10 ГБ с интерфейсом 20 ГБ. Теперь, если вы сделали iperf3 -P 2 он может работать в общей сложности 20 ГБ, в зависимости от настройки /sys/class/net/bond0/bonding/xmit_hash_policy на обоих хостах - по умолчанию это layer2+3 , но если вы установите его на layer3+4 (хэш на src/dst ip/port), он должен распределить нагрузку между двумя сетевыми картами до полной скорости вашего соединения.

Я наткнулся на этот пост с похожей проблемой, но у меня возникают падения, когда я запускаю iperfs с 2+ параллельными потоками общим объемом менее 20 ГБ между 10 ГБ * 2 связанными хостами в разных подсетях ... Juniper повторил проблему, но пока не дал хороших ответов :( Если они не могут понять это, возможно, Linux QoS - следующий шаг.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .