Фрагментация пакетов внутри контейнеров Kubernetes

У меня есть кластер Kubernetes с одним узлом, работающий на RHEL 7.

У меня также есть сервер Windows Server 2019.

Серверы Windows и RHEL представляют собой виртуальные машины на одном хосте.

Когда я сижу в командной строке RHEL и запускаюcurlдля получения документа размером 500 КБ по URL-адресу в IIS запрос выполняется «быстро» (менее 1 секунды).

Когда я запускаю тот же запрос из контейнера, работающего в модуле Kubernetes, запрос выполняется «медленно» (4 секунды или более).

Это происходит как с Calico (исходным вариантом), так и с Weave (теперь развернутым вместо него) в качестве поставщика сети модулей Kubernetes.

Я дошел до бегаtcpdumpвнутри контейнера и установления наличия большого количества повторных передач TCP и обновлений размера окна в ходе HTTP-запроса.

Это выглядит (насколько мне известно) как проблема, связанная с MTU. Однако уменьшение MTU как на стороне IIS, так и внутри сети Weave не помогло.

Я жду дампов пакетов от клиента, запущенных как на стороне IIS, так и непосредственно на машине RHEL, чтобы я мог определить, где отбрасываются пакеты.

Между тем, любые идеи приветствуются.

1 ответ

Мы устранили проблему, хотя никогда не были на 100% уверены в ее первопричине.

Дампы пакетов показали, что большие кадры (намного больше 1500 байт), поступающие в блок K8s из IIS, а затем отклоняемые Linux с «необходимой фрагментацией», поскольку Weave MTU был стандартным 1376.

MTU на обоих концах канала составляло 1500, но мы думаем, что, возможно, имела место разгрузка сегментации TCP (клиент использует VMWare, и загадочные отклонения «требуется фрагментация» от виртуальной машины шлюза звучат несколько похоже)

В итоге мы установили очень высокий MTU в сети Weave — 65404 — исходя из того, что все это находится в пределах одной виртуальной машины, так почему бы и нет?

Это устранило фрагментацию пакетов, и HTTP-запросы изнутри контейнеров теперь выполняются так же быстро, как и снаружи на хосте K8s.

Другие вопросы по тегам