Почему я вижу повторные передачи по сети с помощью iperf3?

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

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

под-а под-Б на 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

удаление моста Кубе из уравнения приводит к нулевой ретрансляции. Я проверил host-a to pod-b и видел те же ретрансляции.

Я был запущен dropwatch и видя следующее на прием host (сервер 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 Linux стабильный 1632.3.0. Имя хоста Linux 4.14.19-coreos #1 SMP Wed Feb 14 03: 18: 05 UTC 2018 x86_64 GNU/Linux

любая помощь или указатели были бы очень признательны.

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

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

13
задан dlamotte
19.12.2022 4:33 Количество просмотров материала 2503
Распечатать страницу

2 ответа

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

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

считаете ли вы, что замеченные ошибки вызваны меньшим MTU?

1
отвечен Murali-Reddy 2022-12-20 12:21

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

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

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
отвечен dlamotte 2022-12-20 14:38

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх