Soluciona problemas de red de Google Distributed Cloud

En esta página, se muestra cómo resolver problemas de red con Google Distributed Cloud. Se proporciona información general para la solución de problemas y orientación, junto con herramientas sugeridas. También se incluye información de solución de problemas de DNS y algunos problemas comunes de MetalLB.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Solución de problemas de conectividad de red

Las redes de GKE Enterprise dependen de tu infraestructura de red física. Por ejemplo, MetalLB se basa en tus interruptores que respetan el ARP injustificado, el balanceo de cargas en paquetes con protocolo de puerta de enlace de frontera (BGP) depende de tus routers y todos los nodos deben poder comunicarse entre sí. Cuando tienes un problema de red en tus clústeres de GKE, debes identificar si el problema está en los componentes de GKE Enterprise o en tu propia infraestructura.

Primero, determina el alcance del problema y, luego, intenta identificar los componentes afectados. El alcance de un problema puede ser una de tres categorías: el sujeto (desde el lugar), el destino (al cual) y la capa de red.

El alcance del tema puede ser uno de los siguientes:

• Todos los nodos (o Pod hostNetwork) en todo el clúster.
• Todos los Pods en todo el clúster.
• Todos los Pods en un solo nodo o un conjunto de nodos.
• Todos los Pods del mismo Deployment o DaemonSet.
• Cliente desde fuera del clúster.

El alcance del objetivo puede ser uno o más de los siguientes:

• Todas las demás direcciones IP del Pod del mismo clúster.
• Todas las demás direcciones IP del Pod del mismo nodo.
• VIP del servicio ClusterIP del mismo clúster.
• LoadBalancer del Service VIP desde el mismo clúster.
• LoadBalancer de capa 7 de Ingress (Istio)
• Otros nodos del mismo clúster.
• Nombre de DNS interno (como *.svc.cluster.local).
• Nombre de DNS externo (como google.com).
• Entidades desde fuera del clúster.
• Entidades en Internet

La capa de red puede ser una o más de las siguientes opciones:

• Problemas de capa 2 en la capa de vínculo, como el sistema vecino, ARP o NDP.
• Problemas de enrutamiento de direcciones IP de capa 3.
• Problemas con los extremos de TCP o UDP de capa 4.
• Problemas con HTTP o HTTPS de capa 7.
• Problemas de resolución de DNS.

Comprender el alcance de un problema ayuda a identificar los componentes involucrados en él y en qué capa ocurre. Recopilar información cuando ocurre un problema es importante, ya que algunos problemas son temporales, por lo que las instantáneas después de la recuperación del sistema no incluirán suficiente información para el análisis de la causa raíz.

Problemas de entrada

Si el sujeto es un cliente que está fuera del clúster y no se pudo conectar a un servicio LoadBalancer, se trata de un problema de conectividad norte-sur. En el siguiente diagrama, se muestra que, en un ejemplo funcional, el tráfico entrante viaja a través de la pila de izquierda a derecha, y el tráfico de retorno viaja a través de la pila de derecha a izquierda.

Cuando haya un problema con este flujo de tráfico, usa el siguiente diagrama de flujo para solucionar problemas a fin de identificar dónde se encuentra el problema:

En este diagrama de flujo, la siguiente guía para solucionar problemas ayuda a determinar dónde se encuentra el problema:

• ¿El paquete sale del cliente? Si no es así, es probable que tengas un problema de infraestructura de red.
• ¿Estás usando MetalLB? Si es así, ¿el paquete llega al nodo LB y, entonces, ARP se envía de forma correcta? Si no es así, es probable que tengas un problema con la infraestructura de red.
• ¿Estás usando BIG-IP de F5 y, de ser así, revisaste si hay problemas con F5?
• ¿Se realizó correctamente la traducción de direcciones de red (NAT)? De lo contrario, es probable que tengas un problema con kube-proxy o Dataplane V2.
• ¿El paquete llega al nodo trabajador? Si no es así, es probable que tengas un problema de Pod a Pod de Dataplane v2.
• ¿El paquete llega al Pod? De lo contrario, es probable que tengas un problema de reenvío local de Dataplane v2.

En las siguientes secciones, se proporcionan pasos para solucionar problemas en cada etapa y determinar si el tráfico fluye de forma correcta o no.

¿El paquete sale del cliente?

Verifica si el paquete sale de forma correcta del cliente y pasa por el router que está configurado en la infraestructura de red física.

1. Usa tcpdump para verificar el paquete cuando sale del cliente para el servicio de destino:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Si no ves que el tráfico salga, esa es la causa del problema.

¿El paquete llega a un nodo LoadBalancer?

Si usas MetalLB como el balanceador de cargas, haz lo siguiente:

1. Mira el registro metallb-controller para determinar qué nodo del balanceador de cargas entrega la VIP del servicio:

   kubectl -n kube-system logs -l app=metallb --all-containers=true | grep SERVICE_VIP
   

2. Conéctate al nodo con SSH.

3. En el caso de un nodo de MetalLB, usa tcpdump para revisar el tráfico:

   tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT
   

   Para ManualLB, el tráfico podría llegar a cualquier nodo. Según la configuración del balanceador de cargas, puedes elegir uno o varios nodos. Usa tcpdump para revisar el tráfico:

   tcpdump -ni any host NODE_IP and port NODE_PORT
   

   El comando es diferente entre los tipos de balanceador de cargas, ya que MetalLB no aplica NAT antes de reenviar el paquete a los nodos.

   Si no ves que el tráfico ingrese a ningún nodo, esa es la causa del problema.

¿Hay un problema de BIG-IP en F5?

Para solucionar los problemas de BIG-IP de F5, consulta una de las siguientes secciones sobre El servicio de F5 no recibe tráfico.

¿El ARP se envió correctamente?

El nodo del balanceador de cargas de MetalLB se basa en ARP para anunciar la VIP del servicio. Si la respuesta ARP se envía de forma correcta, pero el tráfico no entra, es una señal de un problema en tu infraestructura de red física. Una causa común de este problema es que algunas funciones avanzadas de aprendizaje del plano de datos ignoran la respuesta ARP en las soluciones de red definida por software (SDN).

1. Usa tcpdump para detectar respuestas ARP:

   tcpdump -ni any arp
   

   Intenta encontrar el mensaje que anuncie la VIP con la que tienes problemas.

2. Para MetalLB, no envía ARP injustificado. La frecuencia con la que ves una respuesta depende del momento en que otro dispositivo, como un interruptor de la parte superior de bastidor (ToR), envía una solicitud ARP.

¿Se ejecuta NAT?

Dataplane v2 / kube-proxy realiza la traducción de direcciones de red de destino (NAT de destino o DNAT) para traducir la VIP de destino en una dirección IP del Pod de backend. Si sabes qué nodo es el backend del balanceador de cargas, conéctate a él mediante SSH.

1. Usa tcpdump para verificar si la VIP del servicio se tradujo de forma correcta:

   tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
   

2. Además, para Dataplane v2, puedes conectarte a los Pods anetd y usar las herramientas de depuración de Cilium incorporadas:

   cilium monitor --type=drop
   

Para obtener más información, consulta una de las siguientes secciones sobre problemas de Dataplane v2 y Cilium.

¿El paquete llega a un nodo trabajador?

En los nodos trabajadores, el paquete llega a la interfaz externa y, luego, se entrega a los Pods.

1. Verifica si el paquete llega a la interfaz externa, generalmente llamada eth0 o ens192, mediante tcpdump:

   tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
   

En el caso de Google Distributed Cloud, el paquete se encapsula en un túnel. Cuando se desencapsula el paquete, sale de una interfaz de red llamada cilium_geneve.

Debido a que los backends de Service normales contienen varios Pods en diferentes nodos, puede ser difícil solucionar qué nodo tiene la falla. Una solución alternativa común es capturar el problema el tiempo suficiente para que llegue algún paquete o limitar la cantidad de backends a uno.

Si el paquete nunca llega al nodo de trabajo, es una indicación de un problema de infraestructura de red. Consulta con el equipo de infraestructura de red para ver por qué se descarta el paquete entre los nodos LoadBalancer y los nodos trabajadores. Estos son algunos problemas comunes:

• Verifica los registros de la red definida por software (SDN). A veces, la SDN podría descartar paquetes por varias razones, como segmentación, suma de verificación incorrecta o antifalsificación de identidad.
• Reglas de firewall que filtran paquetes geneve al puerto UDP 6081.

Si el paquete llega a la interfaz externa del nodo o a la interfaz del túnel, debe reenviarse al Pod de destino. Si el Pod es un Pod de red de host, este paso no es necesario porque el Pod comparte el espacio de nombres de la red con el nodo. De lo contrario, se requerirá reenvío de paquetes adicional.

Cada Pod tiene pares de interfaces de Ethernet virtuales, que funcionan como canalizaciones. Un paquete que se envía a un extremo de la interfaz se recibe del otro extremo de la interfaz. Una de las interfaces se traslada al espacio de nombres de red del Pod y se cambia su nombre a eth0. La otra interfaz se mantiene en el espacio de nombres del host. Los diferentes CNI tienen un esquema diferente. En Dataplane v2, la interfaz suele llamarse lxcxxxx. Los nombres tienen números de interfaz consecutivos, como lxc17 y lxc18. Puedes verificar si el paquete llega al Pod mediante tcpdump o también puedes especificar la interfaz:

  tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

Si el paquete llega al nodo, pero no llega al Pod, verifica la tabla de enrutamiento de la siguiente manera:

  ip route

Por lo general, cada Pod debe tener una ruta de entrada de enrutamiento que dirija la dirección IP del Pod hacia la interfaz lxc. Si falta la entrada, normalmente significa que la ruta de datos de CNI tiene un error. Para determinar la causa raíz, verifica los registros de DaemonSet de CNI.

Problemas de salida

Si el tráfico puede entrar a un Pod, es posible que tengas un problema con el tráfico, ya que sale del Pod. En el siguiente diagrama, se muestra que, en un ejemplo funcional, el tráfico entrante viaja a través de la pila de izquierda a derecha:

1. Para verificar que el paquete saliente se haga pasar por la dirección IP del nodo, verifica el servicio externo (capa 4).

   La dirección IP de origen del paquete debe asignarse desde la dirección IP del Pod a la dirección IP del nodo con la traducción de direcciones de red de origen (NAT o SNAT de origen). En Dataplane v2, este proceso se realiza con un ebpf que se carga en una interfaz externa.

   Usa tcpdump para verificar si la dirección IP de origen se traduce de forma correcta de la dirección IP del Pod a la dirección IP del nodo:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and port EXTERNAL_PORT
   

   Si tcpdump muestra que los paquetes están enmascarados de forma correcta, pero el servicio remoto no responde, verifica la conexión al servicio externo en tu infraestructura.

2. Si los paquetes salientes están enmascarados de manera correcta como la dirección IP del nodo, verifica la conectividad del host externo (capa 3) mediante tcpdump:

   tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp
   

   Al mismo tiempo que ejecutas tcpdump, haz ping desde uno de los Pods:

   kubectl exec POD_NAME ping EXTERNAL_IP
   

   Si no ves respuestas de ping, verifica la conexión al servicio externo en tu infraestructura.

Problemas en el clúster

En el caso de los problemas de conectividad de Pod a Pod, intenta determinar el alcance del problema en los nodos. A menudo, un grupo de nodos no puede comunicarse con otro.

1. En Dataplane v2, verifica la conectividad del nodo actual a todos los demás nodos del mismo clúster. Desde dentro del pod anetd, verifica el estado:

   cilium status --all-health
   

Problemas en la capa de red

Identificar en qué capa de red se produce el problema de conectividad es un paso importante. Un mensaje de error como “Un problema de conectividad de una fuente a un destino” no es lo suficientemente informativo para ayudar a resolver el problema, que podría ser un error de aplicación, de enrutamiento o de DNS. Comprender en qué capa ocurre el problema ayuda a solucionar el componente correcto.

Muchas veces, los mensajes de error indican directamente con qué capa se produce el problema. Los siguientes ejemplos pueden ayudarte a solucionar problemas relacionados con la capa de red:

• Los errores de HTTP indican que se trata de un problema de capa 7.
  • Los códigos HTTP 40x, 50x o los errores de protocolo de enlace TLS significan que todo funciona normalmente en la capa 4.
• Los errores "Connection Reset bypeer" indican que se trata de un problema de capa 4.
  • Muchas veces, el socket remoto no puede aceptar el estado actual de una conexión y, por lo tanto, envía un paquete RESET. Este comportamiento puede ser un error en el seguimiento de conexiones, o NAT.
• Los errores "Sin ruta al host" y "Tiempo de espera de la conexión" suelen ser un problema de capa 3 o capa 2.
  • Estos errores indican que el paquete no se puede enrutar correctamente al destino.

Herramientas útiles para solucionar problemas

Los DaemonSets relacionados con la red se ejecutan en tus nodos y podrían ser la causa de los problemas de conectividad. Sin embargo, la configuración incorrecta de los nodos, los interruptores de la parte superior del bastidor (ToR), los routers de columna vertebral o los firewalls también pueden causar problemas. Puedes usar las siguientes herramientas para determinar el alcance o la capa del problema y si es un problema con tus nodos de GKE Enterprise o tu infraestructura física.

Ping

Ping funciona en la capa 3 (capa de IP) y verifica la ruta entre un origen y un destino. Si el ping no llega a un destino, a menudo significa que el problema está en la capa 3.

Sin embargo, no se puede hacer ping en todas las direcciones IP. Por ejemplo, no se puede hacer ping a algunas VIP del balanceador de cargas si se trata de un balanceador de cargas de capa 4 puro. El servicio ClusterIP es un ejemplo en el que la VIP podría no mostrar una respuesta de ping. En la capa 4, este servicio solo muestra una respuesta de ping cuando especificas un número de puerto, como VIP:port.

Los balanceadores de cargas BGPLB y MetalLB en Google Distributed Cloud funcionan en la capa 3. Puedes usar ping para verificar la conectividad. Aunque F5 es diferente, también es compatible con ICMP. Puedes usar ping para verificar la conectividad a la VIP de F5.

Arping

Arping es similar a ping, excepto que funciona en la capa 2. Los problemas de capa 2 y capa 3 suelen tener mensajes de error similares de las aplicaciones. Arping y ping pueden ayudar a diferenciar el problema. Por ejemplo, si el origen y el destino están en la misma subred, pero no puedes ejecutar el destino, se trata de un problema de capa 2.

Un arping <ip> exitoso muestra la dirección MAC del destino. En la capa 2, esta dirección suele indicar un problema de infraestructura física. Este problema suele deberse a un cambio físico entre nodos.

Arping también puede detectar conflictos de direcciones IP. Un conflicto de dirección IP ocurre cuando dos máquinas están configuradas para usar la misma dirección IP en la misma subred o cuando otra máquina física usa una VIP. Los conflictos de direcciones IP pueden crear problemas intermitentes. Si arping <ip> muestra más de una entrada de dirección MAC, es una indicación de que hay un conflicto de direcciones IP.

Después de obtener la dirección MAC de arping, puedes usar https://maclookup.app/ para buscar el fabricante de la dirección MAC. Cada fabricante posee un prefijo de MAC, por lo que puedes usar esta información para determinar qué dispositivo intenta usar la misma dirección IP. Por ejemplo, VMware es propietario del bloque 00:50:56, por lo que una dirección MAC 00:50:56:xx:yy:zz es una VM en tu entorno de vSphere.

iproute2

La CLI de ip para iproute2 tiene muchos subcomandos útiles, como los siguientes:

• ip r: Muestra la tabla de ruta.
• ip n: Muestra la tabla vecina para la asignación de dirección IP a MAC.
• ip a: Muestra todas las interfaces de la máquina.

Una ruta o una entrada faltantes en la tabla vecina puede causar problemas de conectividad desde el nodo. Anetd administra la tabla de ruta y la tabla vecina. Una configuración incorrecta en esas tablas puede causar problemas de conectividad.

CLI de Cilium / Hubble para Dataplane v2

Cada Pod de anetd tiene varias herramientas de depuración útiles para los problemas de conectividad:

• cilium monitor --type=drop
  • Imprime el registro por cada paquete que descarta anetd / Cilium.
• hubble observe
  • Imprime todos los paquetes que pasan por la pila ebpf de anetd.
• cilium status --all-health
  • Muestra el estado de Cilium, incluido el estado de conectividad de nodo a nodo. Cada Pod agregado verifica el estado de todos los demás nodos del clúster y puede ayudar a determinar cualquier problema de conectividad de nodo a nodo.

iptables

Los iptables se usan en muchos componentes y subsistemas de Kubernetes. kube-proxy usa iptables para implementar la resolución del servicio.

1. Para solucionar problemas de red a nivel de iptables, usa el siguiente comando:

   iptables -L -v | grep DROP
   

   Revisa las reglas de eliminación y verifica los recuentos de paquetes y bytes para ver si aumentan con el tiempo.

Tcpdump

Tcpdump es una potente herramienta de captura de paquetes que genera muchos datos de tráfico de red. Lo más común es ejecutar tcpdump desde la fuente y el destino. Si se captura un paquete cuando sale del nodo de origen, pero nunca se captura en el nodo de destino, significa que algo intermedio descarta el paquete. Este comportamiento generalmente indica que algo en tu infraestructura física descarta el paquete por error.

Solución de problemas de DNS

Los problemas de resolución de DNS se dividen en dos categorías principales:

• Pods normales, que usan los servidores DNS en el clúster.
• Pods o nodos de la red del host, que no usan servidores DNS en el clúster

En las siguientes secciones, se proporciona información sobre la arquitectura de DNS del clúster y sugerencias útiles antes de comenzar a solucionar los problemas de una de estas categorías.

Arquitectura de DNS del clúster

Un servicio DNS de clúster resuelve las solicitudes de DNS de los Pods del clúster. CoreDNS proporciona este servicio para todas las versiones de Google Distributed Cloud.

Cada clúster tiene dos o más Pods coredns y un escalador automático responsable de escalar la cantidad de Pods de DNS en relación con el tamaño del clúster. También hay un servicio llamado kube-dns que balancea las cargas de las solicitudes entre todos los Pods coredns de backend.

La mayoría de los Pods tienen su DNS ascendente configurado en la dirección IP del servicio kube-dns, y los Pods envían solicitudes de DNS a uno de los Pods coredns. Las solicitudes de DNS se pueden agrupar en uno de los siguientes destinos:

• Si la solicitud es para un dominio cluster.local, es un nombre de DNS en el clúster que hace referencia a un Service o un Pod en el clúster.
  • CoreDNS detecta todos los servicios y Pods del clúster api-server, y responde a las solicitudes de dominios cluster.local válidos.
• Si la solicitud no es para un dominio cluster.local, es para un dominio externo.
  • CoreDNS reenvía la solicitud a los servidores de nombres ascendentes. De forma predeterminada, CoreDNS usa los servidores de nombres ascendentes que están configurados en el nodo en el que se ejecuta.

Para obtener más información, consulta la descripción general sobre cómo funciona y se configura el DNS en Kubernetes.

Sugerencias para solucionar problemas de DNS

Para solucionar problemas de DNS, puedes usar las herramientas dig y nslookup. Estas herramientas te permiten enviar solicitudes de DNS para probar si la resolución de DNS funciona correctamente. En los siguientes ejemplos, se muestra cómo usar dig y nslookup para verificar problemas de resolución de DNS.

• Usa dig o nslookup para enviar una solicitud de google.com:

  dig google.com
  nslookup google.com
  

• Usa dig para enviar una solicitud de kubernetes.default.svc.cluster.local al servidor 192.168.0.10:

  dig @192.168.0.10 kubernetes.default.svc.cluster.local
  

• También puedes usar nslookup para realizar la misma búsqueda de DNS que el comando dig anterior:

  nslookup kubernetes.default.svc.cluster.local 192.168.0.10
  

  Revisa el resultado de los comandos dig o nslookup. Si recibes una respuesta incorrecta o no recibes una respuesta, esto indica un problema con la resolución de DNS.

Pods regulares

El primer paso para depurar un problema de DNS es determinar si las solicitudes llegan o no a los Pods coredns. A menudo, un problema de conectividad general del clúster aparece como problemas de DNS porque una solicitud de DNS es el primer tipo de tráfico que envía una carga de trabajo.

Revisa los mensajes de error de tus aplicaciones. Los errores como io timeout o similares indican que no hay respuesta y un problema general de conectividad de red.

Los mensajes de error que incluyen un código de error de DNS, como NXDOMAIN o SERVFAIL, indican que hay conectividad con el servidor DNS en el clúster, pero el servidor no pudo resolver el nombre de dominio:

• Los errores NXDOMAIN indican que el servidor DNS informa que el dominio no existe. Verifica que el nombre de dominio que solicita tu aplicación sea válido.
• Los errores SERVFAIL o REFUSED indican que el servidor DNS devolvió una respuesta, pero no pudo resolver el dominio ni validar que no existe. Para obtener más información, consulta los registros de los Pods de coredns.

Para encontrar la dirección IP del servicio de kube-dns, usa el siguiente comando:

kubectl -n kube-system get svc kube-dns

Desde un Pod en el que el DNS no funciona, intenta enviar una solicitud de DNS a esta dirección IP mediante dig o nslookup, como se detalla en una sección anterior:

• Si estas solicitudes no funcionan, intenta enviar solicitudes a la dirección IP de cada Pod coredns.
• Si algunos Pods funcionan, pero no otros, verifica si hay patrones que se puedan distinguir, como la resolución de DNS, que funciona para Pods en el mismo nodo que el Pod coredns, pero no entre nodos. Este comportamiento puede indicar algún problema de conectividad en el clúster.

Si CoreDNS no puede resolver los nombres de dominio externos, consulta la siguiente sección para solucionar los problemas de los Pods de la red host. CoreDNS se comporta como un pod de red de host y usa los servidores DNS ascendentes del nodo para la resolución de nombres.

Pods o nodos de la red del host

Los Pods de la red del host y los nodos usan los servidores de nombres configurados en el nodo para la resolución de DNS, no el servicio de DNS en el clúster. Según el SO, este servidor de nombres se configura en /etc/resolv.conf o /run/systemd/resolve/resolv.conf. Esta configuración significa que no pueden resolver los nombres de dominio cluster.local.

Si tienes problemas con la resolución de nombres de red host, sigue los pasos de solución de problemas de las secciones anteriores para probar si el DNS funciona correctamente para tus servidores de nombres ascendentes.

Verifica que todos los nodos tengan configurado el mismo conjunto de servidores. Si tienes diferentes servidores de nombres configurados, es posible que veas inconsistencias en la resolución de DNS en diferentes nodos. Verifica que cada servidor de nombres funcione de forma individual. Para ello, envía una solicitud a cada uno con dig o nslookup. Si algunos servidores de nombres funcionan, pero otros no, verás este tipo de fallas de resolución de DNS inconsistentes.

Problemas comunes de la red

En las siguientes secciones, se detallan algunos problemas comunes de red que puedes encontrar. Para ayudarte a resolver el problema, sigue las instrucciones adecuadas. Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Dataplane v2 / Cilium

Error común: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Este error significa que el agente de Cilium rechazó el evento de creación del Pod debido a un límite de frecuencia. Para cada nodo, Cilium tiene un límite de cuatro solicitudes simultáneas al extremo PUT. Cuando hay un aumento de solicitudes a un nodo, se espera este comportamiento. El agente de Cilium debería ponerse al día con las solicitudes demoradas.

En GKE Enterprise 1.14 y versiones posteriores, el límite de frecuencia se ajusta automáticamente a la capacidad del nodo. El limitador de frecuencia puede converger a un número más razonable, con límites de frecuencia más altos para nodos más potentes.

Error común: Ebpf map size is full

Dataplane v2 almacena el estado en un mapa de eBFP. El estado incluye el Service, el seguimiento de conexiones, la identidad del Pod y las reglas de políticas de red. Si un mapa está lleno, el agente no puede insertar entradas, lo que crea una discrepancia entre el plano de control y el plano de datos. Por ejemplo, el mapa de Service tiene un límite de 64,000 entradas.

1. Para verificar las entradas del mapa de eBFP y su tamaño actual, usa bpftool. En el siguiente ejemplo, se verifican los mapas del balanceador de cargas:

   bpftool map dump pinned \
   /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | tail -n -1
   
   bpftool map dump pinned \ /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | tail -n -1
   

2. Si el mapa está cerca del límite de 64 k, realiza una limpieza. En el siguiente ejemplo, se limpian los mapas del balanceador de cargas:

   bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 | \
       awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5, "0x"$6, "0x"$7, "0x"$8, "0x"$9, "0x"$10, "0x"$11, "0x"$12, "0x"$13}' | \
       head -n -1 | \
       xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_services_v2 key
   
   bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 | \
       awk '{ print "0x"$2, "0x"$3, "0x"$4, "0x"$5 }' | \
       head -n -1 | \
       xargs -L 1 bpftool map delete pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends_v2 key
   

3. Para volver a completar el estado en el mapa de eBFP, reinicia anetd.

El nodo no está listo debido a errores NetworkPluginNotReady

Si el Pod de CNI no se está ejecutando en el nodo, es posible que veas un error similar al siguiente:

  "Container runtime network not ready" networkReady="NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized

El nodo también puede estar no listo, con un error similar al siguiente ejemplo:

  "Network plugin not installed"

Cuando se inicializa un nodo, kubelet espera a que ocurran varios eventos antes de marcarlo como Ready. Uno de los eventos que kubelet verifica es que esté instalado el complemento de la interfaz de red del contenedor (CNI). Anetd debe instalar el complemento de CNI mediante un contenedor init para instalar el binario de la CNI y la configuración de la CNI en los directorios de host requeridos.

Para solucionar este problema, verifica por qué esos Pods no se están ejecutando en el nodo. Por lo general, el error no se debe a problemas de red. Esos Pods se ejecutan en la red del host, por lo que no hay dependencia de red.

1. Verifica el estado del Pod anetd. Revisa los siguientes pasos de solución de problemas para determinar la causa del problema:

   • Si el Pod está en un estado Crashlooping, verifica los registros para ver por qué el Pod no se puede ejecutar de forma correcta.
   • Si el Pod está en un estado Pending, usa kubectl describe y revisa los eventos del Pod. Por ejemplo, es posible que al Pod le falte un recurso, como un Volume.
   • Si el Pod está en estado Running, verifica los registros y la configuración. Algunas implementaciones de CNI proporcionan opciones para inhabilitar la instalación de CNI, como en Cilium.
   • En anetd, hay una opción de configuración llamada custom-cni-conf. Si esta configuración se configura como true, anetd no instalará su objeto binario de CNI.

F5 El servicio no recibe tráfico

Si no pasa tráfico al servicio de F5, revisa los siguientes pasos para solucionar problemas:

1. Comprueba que cada partición en BIG-IP de F5 esté configurada en un clúster, ya sea de administrador o de usuario. Si varios clústeres diferentes comparten una partición, experimentarás interrupciones intermitentes en la conexión. Este comportamiento se debe a que dos clústeres intentan tomar el control de la misma partición y borrar los servicios de otros clústeres.

2. Verifica que los dos Pods siguientes se estén ejecutando. Cualquier Pod que no se esté ejecutando indicará un error:

   Load-balancer-f5
   K8s-bigip-ctlr-deployment-577d57985d-vk9wj
   

   El Load-balancer-f5 que es propiedad de GKE Enterprise y crea ConfigMaps para cada servicio de tipo LoadBalancer. El controlador bigip consume el ConfigMap en algún momento.

3. Asegúrate de que el ConfigMap exista para cada puerto de cada Service. Por ejemplo, con los siguientes puertos:

   Kube-server-443-tcp     2   31h
   Kube-server-8132-tcp        2   31h
   

   El servicio kube-server debería ser similar al siguiente ejemplo:

   Kube-server LoadBalancer  10.96.232.96  21.1.7.16   443:30095/TCP,8132:32424/TCP  31h
   

   La sección de datos en ConfigMap debe tener la VIP y el puerto de frontend, como se muestra en el siguiente ejemplo:

   data: '{"virtualServer":{"backend":{"serviceName":"kube-apiserver","servicePort":443,"healthMonitors":[{"protocol":"tcp","interval":5,"timeout":16}]},"frontend":{"virtualAddress":{"bindAddr":"21.1.7.16","port":443},"partition":"herc-b5bead08c95b-admin","balance":"ratio-member","mode":"tcp"}}}'
     schema: f5schemadb://bigip-virtual-server_v0.1.7.json
   

4. Verifica los registros y las métricas de las instancias de BIG-IP. Si el ConfigMap está configurado de forma correcta, pero la instancia de BIG-IP no respeta la configuración, podría ser un problema de F5. Para los problemas que ocurren dentro de la instancia de BIG-IP, comunícate con el equipo de asistencia de F5 para diagnosticar y solucionar los problemas.

Falla de NAT con demasiadas conexiones paralelas

Para un nodo determinado en tu clúster, la dirección IP del nodo proporciona traducción de direcciones de red (NAT) para los paquetes enrutados a una dirección fuera del clúster. Del mismo modo, cuando los paquetes entrantes ingresan a un nodo de balanceo de cargas configurado para usar el balanceo de cargas en paquetes (spec.loadBalancer.mode: bundled), la traducción de direcciones de red de origen (SNAT) enruta los paquetes a la dirección IP del nodo antes de que sucedan se reenvían a un Pod de backend.

El rango de puertos para NAT que usa Google Distributed Cloud es 32768-65535. Este rango limita la cantidad de conexiones paralelas a 32,767 por protocolo en ese nodo. Cada conexión necesita una entrada en la tabla conntrack. Si tienes demasiadas conexiones de corta duración, la tabla conntrack se queda sin puertos para NAT. Un recolector de elementos no utilizados limpia las entradas inactivas, pero la limpieza no es inmediata.

Cuando la cantidad de conexiones en tu nodo se acerque a 32,767, comenzarás a ver caídas de paquetes para conexiones que necesitan NAT.

Para determinar si te afecta este problema, haz lo siguiente:

1. Ejecuta el siguiente comando en el Pod anetd del nodo problemático:

   kubectl -n kube-system anetd-XXX -- hubble observe \
       --from-ip $IP --to-ip $IP -f
   

   Deberías ver los siguientes errores:

   No mapping for NAT masquerade DROPPED
   

Como solución alternativa para este problema, redistribuye el tráfico a otros nodos.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.