Eu tenho um cluster Kubernetes de nó único em execução no RHEL 7.
Eu também tenho um servidor Windows Server 2019.
Os servidores Windows e RHEL são máquinas virtuais no mesmo host.
Quando estou em um prompt de comando no RHEL e executo curlpara buscar um documento de 500kb de uma URL no IIS, a solicitação é "rápida" (menos de 1 segundo).
Quando executo a mesma solicitação de dentro de um contêiner em execução em um pod do Kubernetes, a solicitação fica "lenta" (4 segundos ou mais).
Isso acontece com o Calico (original) e o Weave (agora implantado) como provedor de rede de pod do Kubernetes.
Cheguei ao ponto de executar tcpdumpdentro de um contêiner e estabelecer que há um grande número de retransmissões TCP e atualizações de tamanho de janela durante o curso da solicitação HTTP.
Isso parece (até onde sei) um problema relacionado ao MTU. No entanto, a redução do MTU tanto na extremidade do IIS quanto na rede Weave não ajudou.
Estou aguardando que os despejos de pacotes do cliente sejam executados no final do IIS e diretamente na máquina RHEL, para que eu possa estabelecer onde os pacotes estão sendo descartados.
Enquanto isso, qualquer ideia é muito bem-vinda.
Responder1
Curámos o problema, embora nunca tenhamos tido 100% de certeza da causa raiz.
Os despejos de pacotes mostraram jumbo frames (muito maiores que 1500 bytes) chegando à caixa K8s do IIS e depois sendo rejeitados com "fragmentação necessária" pelo Linux, já que o Weave MTU era um padrão 1376
O MTU em ambas as extremidades do link era 1.500, mas achamos que talvez o descarregamento da segmentação TCP estivesse em jogo (o cliente usa VMWare eRejeições misteriosas de “fragmentação necessária” da VM do gatewayparece um pouco relacionado)
Acabamos definindo um MTU muito alto na rede Weave - 65404 - com base no fato de que tudo está dentro de uma única VM, então por que não?
Isso curou a fragmentação de pacotes e as solicitações HTTP de dentro dos contêineres agora são tão rápidas quanto de fora do host K8s.