¿Por qué se produce el "Dead loop on virtual device gw_11cbf51a, fix it urgently" cuando inicio sesión en una máquina virtual usando VNC?
Síntoma
En un clúster que utiliza el modelo de red de VPC, se muestra el mensaje "Dead loop on virtual device gw_11cbf51a, fix it urgently" después de iniciar sesión en la máquina virtual.
Causa
El modelo de red VPC utiliza el módulo IPvlan de Linux de código abierto para las redes de contenedores. En el modo L2E de IPvlan, se realiza preferentemente el reenvío de capa 2, y luego el reenvío de capa 3.
Reproducción de escenas
Supongamos que hay un pod A de servicio, que proporciona servicios externamente y al que accede constantemente el nodo en el que inicia sesión a través del puerto de gateway de contenedor a través del servicio Kubernetes host. Otro escenario puede ser que los pods en este nodo accedan directamente entre sí. Cuando el pod A sale debido a una actualización, escalado u otras razones, y se reclaman los recursos de red correspondientes, si el nodo todavía intenta enviar paquetes a la dirección IP del pod A, El módulo IPvlan en el núcleo primero intenta reenviar estos paquetes en la Capa 2 basándose en la dirección IP de destino. Sin embargo, como la NIC a la que pertenece la dirección IP de pod A ya no se puede encontrar, el módulo IPvlan determina que el paquete puede ser un paquete externo. Por lo tanto, el módulo intenta reenviar el paquete en la Capa 3 y hace coincidir el puerto de gateway basándose en la regla de encaminamiento. Después de que el puerto de gateway recibe el paquete de nuevo, reenvía el paquete a través del módulo IPvlan, y este proceso se repite. La función dev_queue_xmit en el núcleo detecta que el paquete se envía repetidamente 10 veces. Como resultado, se descarta el paquete y se generó este log.
Después de perder un paquete, el iniciador de acceso realiza generalmente reintentos de retroceso varias veces. Por lo tanto, se imprimen varios registros hasta que el ARP en el contenedor del iniciador de acceso envejezca o el servicio termine el acceso.
Para la comunicación entre contenedores en diferentes nodos, las direcciones IP de destino y origen no pertenecen a la misma subred dedicada a nivel de nodo (tenga en cuenta que esta subred es diferente de la subred de VPC). Por lo tanto, los paquetes no se enviarán repetidamente, y este problema no se producirá.
Se puede acceder a los pods de diferentes nodos del mismo clúster con un servicio de NodePort. Sin embargo, la dirección IP del servicio NodePort se traduce en la dirección IP de la interfaz de gateway del contenedor accedido por SNAT, que puede generar los registros que ve anteriormente.
Impacto
El funcionamiento normal del recipiente al que se accede no se ve afectado. Cuando se destruye un contenedor, hay un ligero impacto de que los paquetes se envían repetidamente 10 veces y luego se descartan. Este proceso es rápido en el kernel y tiene poco impacto en el rendimiento.
Si el ARP envejece, el servicio no vuelve a intentarlo o se inicia un nuevo contenedor, los paquetes de servicio de contenedor se redirigen al nuevo servicio con kube-proxy.
Manejo en la comunidad de código abierto
Actualmente, este problema todavía existe en la comunidad cuando se utiliza el modo L2E IPvlan. El problema ha sido reportado a la comunidad para una mejor solución.
Solución
El problema del bucle muerto no necesita ser resuelto.
Sin embargo, se recomienda que el pod de servicio salga correctamente. Antes de que finalice el servicio, configure el pod en el estado de eliminación. Después de completar el procesamiento del servicio, el pod sale.
