Фрагментация пакетов внутри контейнеров 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.