Fragmentación de paquetes desde contenedores de Kubernetes

Fragmentación de paquetes desde contenedores de Kubernetes

Tengo un clúster de Kubernetes de un solo nodo ejecutándose en RHEL 7.

También tengo un servidor Windows Server 2019.

Tanto el servidor Windows como el RHEL son máquinas virtuales en el mismo host.

Cuando me siento en un símbolo del sistema en RHEL y lo ejecuto curlpara buscar un documento de 500 kb desde una URL en IIS, la solicitud es "rápida" (menos de 1 segundo).

Cuando ejecuto la misma solicitud desde dentro de un contenedor que se ejecuta en un pod de Kubernetes, la solicitud es "lenta" (4 segundos o más).

Esto sucede tanto con Calico (original) como con Weave (ahora implementado en su lugar) como proveedor de red de pods de Kubernetes.

Llegué tan lejos como para ejecutar tcpdumpdentro de un contenedor y establecer que hay una gran cantidad de retransmisiones TCP y actualizaciones del tamaño de la ventana durante el transcurso de la solicitud HTTP.

Esto parece (hasta donde tengo conocimiento limitado) un problema relacionado con MTU. Sin embargo, reducir la MTU tanto en el extremo IIS como dentro de la red Weave no ha ayudado.

Estoy esperando que los volcados de paquetes del cliente se ejecuten tanto en el extremo IIS como directamente en la máquina RHEL, para poder establecer dónde se descartan los paquetes.

Mientras tanto, cualquier idea es bienvenida.

Respuesta1

Hemos solucionado el problema, aunque nunca estuvimos 100% seguros de la causa raíz.

Los volcados de paquetes mostraron tramas gigantes (mucho más grandes que 1500 bytes) que llegaban a la caja K8 desde IIS y luego eran rechazadas con "fragmentación necesaria" por Linux, ya que la MTU Weave era un estándar 1376.

La MTU en ambos extremos del enlace era 1500, pero creemos que tal vez estaba en juego la descarga de segmentación TCP (el cliente usa VMWare yMisteriosos rechazos de "fragmentación requerida" de la puerta de enlace VMsuena algo relacionado)

Terminamos estableciendo una MTU muy alta en la red Weave (65404) basándose en que todo está dentro de una única máquina virtual, así que ¿por qué no?

Esto solucionó la fragmentación de paquetes y las solicitudes HTTP desde el interior de los contenedores ahora son tan rápidas como desde fuera en el host K8.

información relacionada