У меня есть кластер Kubernetes с одним узлом, работающий на RHEL 7.
У меня также есть сервер Windows Server 2019.
Оба сервера Windows и RHEL представляют собой виртуальные машины на одном хосте.
Когда я сижу в командной строке RHEL и пытаюсь curlзагрузить документ размером 500 КБ с URL-адреса в IIS, запрос выполняется «быстро» (менее 1 секунды).
Когда я запускаю тот же запрос из контейнера, работающего в модуле Kubernetes, запрос выполняется «медленно» (4 секунды или больше).
Это происходит как с Calico (первоначально), так и с Weave (теперь развернутым вместо него) в качестве поставщика сети модулей Kubernetes.
Мне удалось запустить приложение tcpdumpвнутри контейнера и установить, что в ходе HTTP-запроса происходит большое количество повторных передач TCP и обновлений размера окна.
Это выглядит (насколько мне известно) как проблема, связанная с MTU. Однако уменьшение MTU как на стороне IIS, так и в сети Weave не помогло.
Я жду дампы пакетов от клиента, запущенные как на стороне IIS, так и непосредственно на машине RHEL, чтобы я мог определить, где пакеты теряются.
Между тем, любые идеи приветствуются.
решение1
Мы устранили проблему, хотя никогда не были на 100% уверены в ее первопричине.
Пакетные дампы показали, что большие кадры (гораздо больше 1500 байт) приходили на K8s из IIS, а затем отклонялись Linux с сообщением «необходима фрагментация», поскольку Weave MTU был стандартным 1376
MTU на обоих концах канала был равен 1500, но мы думаем, что, возможно, сработала разгрузка сегментации TCP (клиент использует VMWare иТаинственные отклонения «необходима фрагментация» от шлюзовой виртуальной машинызвучит несколько похоже)
В итоге мы установили очень высокий MTU в сети Weave — 65404 — исходя из того, что все это находится в пределах одной виртуальной машины, так почему бы и нет?
Это устранило фрагментацию пакетов, и HTTP-запросы изнутри контейнеров теперь выполняются так же быстро, как и извне на хосте K8s.