Soluciona problemas de redes de Google Distributed Cloud

En esta página, se muestra cómo resolver problemas de red con Google Distributed Cloud. Se proporciona información y orientación generales para solucionar problemas, junto con las herramientas sugeridas. También se incluye información para solucionar 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 herramientas de redes de GKE Enterprise dependen de tu infraestructura de red física. Por ejemplo, MetalLB depende de tus interruptores que respetan el ARP injustificado, el balanceo de cargas en paquetes con el 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 las siguientes tres categorías: el sujeto (desde dónde), el objetivo (a qué) y la capa de red.

El alcance del asunto puede ser uno de los siguientes:

  • Todos los nodos (o el Pod hostNetwork) en todo el clúster
  • Todos los Pods del clúster
  • Todos los Pods en un solo nodo o un conjunto de nodos
  • Todos los pods de la misma 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 de ClusterIP del mismo clúster
  • VIP del servicio de LoadBalancer del mismo clúster
  • LoadBalancer de la 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).
  • Son entidades de fuera del clúster.
  • Entidades en Internet

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

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

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

Problemas de entrada

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

El tráfico de entrada pasa del usuario a la infraestructura física, a través de un balanceador de cargas a anetd / kube-proxy y, luego, al backend.

Cuando haya un problema con este flujo de tráfico, usa el siguiente diagrama de flujo para solucionar el problema:

Para solucionar problemas de entrada de red, revisa cada paso que realiza un paquete mientras se mueve por tu entorno. Verifica si existen las acciones y la conectividad adecuadas en el camino.

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

  • ¿El paquete sale del cliente? De lo contrario, es probable que tengas un problema con la infraestructura de red.
  • ¿Estás usando MetalLB? Si es así, ¿el paquete llega al nodo de LB y se envía ARP correctamente? De lo contrario, es probable que tengas un problema con la infraestructura de red.
  • ¿Estás usando BIG-IP de F5? Si es así, ¿revisaste si hay problemas con F5?
  • ¿La traducción de direcciones de red (NAT) se realiza correctamente? De lo contrario, es probable que tengas un problema con kube-proxy o Dataplane V2.
  • ¿El paquete llega al nodo trabajador? De lo contrario, 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 correctamente o no.

¿El paquete sale del cliente?

Verifica si el paquete sale correctamente del cliente y pasa por el router configurado en la infraestructura de red física.

  1. Usa tcpdump para verificar el paquete a medida que sale del cliente hacia el servicio de destino:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Si no ves tráfico saliente, esta es la fuente del problema.

¿El paquete llega a un nodo de LoadBalancer?

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

  1. Consulta el registro metallb-controller para determinar qué nodo del balanceador de cargas ofrece 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. Para un nodo de MetalLB, usa tcpdump para revisar el tráfico:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    En el caso de 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 realiza NAT antes de reenviar el paquete a los nodos.

    Si no ves tráfico en ningún nodo, esta es la fuente del problema.

¿Hay un problema con BIG-IP de F5?

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

¿Se envía el ARP correctamente?

El nodo del balanceador de cargas de MetalLB depende de ARP para anunciar la VIP del servicio. Si la respuesta de ARP se envía correctamente, pero no llega tráfico, es un indicador de un problema en la infraestructura de red física. Una causa común de este problema es que algunas funciones avanzadas de aprendizaje de plano de datos ignoran la respuesta de 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 promociona el VIP con el que tienes problemas.

  2. En el caso de MetalLB, no envía ARP injustificado. La frecuencia con la que ves una respuesta depende de cuándo otro dispositivo, como un switch top of rack (ToR), envía una solicitud de ARP.

¿Se realiza la NAT?

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

  1. Usa tcpdump para verificar si el VIP del servicio se traduce correctamente:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. En el caso de Dataplane v2, también 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 o Cilium.

¿El paquete llega a un nodo trabajador?

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

  1. Verifica si el paquete llega a la interfaz externa, que suele denominarse eth0 o ens192, con tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT
En Google Distributed Cloud, el paquete se encapsula en un túnel. Cuando se decapsula el paquete, sale de una interfaz de red llamada cilium_geneve.

Dado que los backends de servicios normales contienen varios pods en diferentes nodos, es posible que sea difícil solucionar el problema de qué nodo es el culpable. Una solución 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 un indicador 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 de LoadBalancer y los nodos de trabajo. Estos son algunos problemas comunes:

  • Revisa los registros de tu red definida por software (SDN). A veces, la SDN puede descartar paquetes por varios motivos, como la segmentación, una suma de comprobación incorrecta o la prevención de falsificación de identidad.
  • Reglas de firewall que filtran paquetes de Geneve en el puerto UDP 6081.

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

Cada Pod tiene pares de interfaces Ethernet virtuales, que funcionan como canales. Un paquete que se envía a un extremo de la interfaz se recibe desde el otro extremo de la interfaz. Una de las interfaces se mueve al espacio de nombres de red del pod y se le cambia el nombre a eth0. La otra interfaz se mantiene en el espacio de nombres del host. Los diferentes CNI tienen esquemas diferentes. En Dataplane v2, la interfaz suele denominarse lxcxxxx. Los nombres tienen números de interfaz consecutivos, como lxc17 y lxc18. Puedes verificar si el paquete llega al pod con tcpdump, o bien puedes especificar la interfaz:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

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

ip route

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

Problemas de salida

Si el tráfico puede ingresar a un pod, es posible que tengas un problema con el tráfico a medida que sale del pod. En los siguientes diagramas, se muestra que, en un ejemplo funcional, el tráfico entrante pasa por la pila de izquierda a derecha:

El tráfico de salida pasa del Pod a través de la interfaz externa del host a la infraestructura física y, luego, al servicio externo.

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

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

    Usa tcpdump para verificar si la dirección IP de origen se traduce correctamente 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 se enmascaran correctamente, pero el servicio remoto no responde, verifica la conexión con el servicio externo en tu infraestructura.

  2. Si los paquetes salientes se enmascaran correctamente como la dirección IP del nodo, verifica la conectividad del host externo (capa 3) con tcpdump:

    tcpdump -ni EXTERNAL_INTERFACE host EXTERNAL_IP and icmp

    Al mismo tiempo que ejecutas tcpdump, realiza un ping desde uno de los pods:

    kubectl exec POD_NAME ping EXTERNAL_IP

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

Problemas en el clúster

En el caso de los problemas de conectividad de pod a pod, intenta limitar el problema a los nodos. A menudo, un grupo de nodos no puede comunicarse con otro grupo de nodos.

  1. En Dataplane v2, verifica la conectividad del nodo actual con todos los demás nodos del mismo clúster. Desde el Pod anetd, verifica el estado de funcionamiento:

    cilium status --all-health

Problemas de 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 como para ayudar a resolver el problema, que podría ser un error de aplicación, de enrutamiento o de DNS. Comprender en qué capa se produce el problema ayuda a corregir el componente correcto.

Muchas veces, los mensajes de error indican directamente en 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 la capa 7.
    • Los códigos HTTP 40x, 50x o los errores de protocolo de enlace TLS significan que todo funciona de forma normal en la capa 4.
  • Los errores “Un par restableció la conexión” indican que se trata de un problema de la capa 4.
    • Muchas veces, el socket remoto no puede coincidir con el estado actual de una conexión y, por lo tanto, envía un paquete RESET. Este comportamiento podría ser un error en el seguimiento de conexiones o en NAT.
  • Los errores "Sin ruta al host" y "Tiempo de espera de conexión" suelen ser problemas de la capa 3 o 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 problemas de conectividad. Sin embargo, la configuración incorrecta de los nodos, los interruptores de la parte superior del bastidor (ToR), los routers de médula o los firewalls también puede causar problemas. Puedes usar las siguientes herramientas para determinar el alcance o la capa del problema y determinar si se trata de un problema con tus nodos de GKE Enterprise o tu infraestructura física.

Ping

Ping funciona en la capa 3 (capa IP) y verifica la ruta entre una fuente 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 todas las direcciones IP pueden recibir ping. Por ejemplo, en algunos VIPs del balanceador de cargas no se puede hacer ping si se trata de un balanceador de cargas de capa 4 puro. El servicio ClusterIP es un ejemplo en el que es posible que el VIP no devuelva 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 admite ICMP. Puedes usar ping para verificar la conectividad con el VIP de F5.

Arping

El Arping es similar al ping, excepto que funciona en la capa 2. Los problemas de las capas 2 y 3 a menudo tienen mensajes de error similares de las aplicaciones. Arping y ping pueden ayudar a diferenciar el problema. Por ejemplo, si la fuente y el destino están en la misma subred, pero no puedes usar Arping para el destino, se trata de un problema de la capa 2.

Una arping <ip> correcta 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 ser un interruptor físico entre los nodos.

El Arping también puede detectar conflictos de direcciones IP. Un conflicto de direcciones 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 que son difíciles de solucionar. Si arping <ip> muestra más de una entrada de dirección MAC, significa 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 tiene un prefijo 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: Imprime la tabla de ruta.
  • ip n: Imprime la tabla de vecinos para la asignación de direcciones IP a direcciones MAC.
  • ip a: Imprime todas las interfaces de la máquina.

Si falta una ruta o una entrada en la tabla de vecinos, es posible que se produzcan problemas de conectividad del nodo. Anetd administra la tabla de rutas y la tabla de vecinos. Una configuración incorrecta en esas tablas puede causar problemas de conectividad.

CLI de Cilium o Hubble para Dataplane v2

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

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

iptables

Iptables se usa en muchos componentes y subsistemas de Kubernetes. kube-proxy usa iptables para implementar la resolución de servicios.

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

    iptables -L -v | grep DROP

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

Volcado TCP

Tcpdump es una potente herramienta de captura de paquetes que genera muchos datos de tráfico de red. Una práctica 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 en el medio descarta el paquete. Por lo general, este comportamiento 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 red de host que no usan servidores DNS en el clúster

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

Arquitectura del DNS del clúster

Un servicio de DNS del clúster resuelve las solicitudes de DNS para 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 que es responsable de escalar la cantidad de pods de DNS en función del 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 servicio o un Pod en el clúster.
    • CoreDNS supervisa el api-server de todos los servicios y pods del clúster, 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 nameservers ascendentes que se configuran en el nodo en el que se está ejecutando.

Para obtener más información, consulta la descripción general de 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 si hay 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 ninguna, esto indica un problema de resolución de DNS.

Pods regulares

El primer paso para depurar un problema de DNS es determinar si las solicitudes llegan a los Pods coredns o no. A menudo, un problema general de conectividad del clúster aparece como problemas de DNS, ya que 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 que hay 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 del 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 envió 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 coredns.

Puedes encontrar la dirección IP del servicio kube-dns con 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 con 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 otros no, verifica si hay patrones discernibles, como que la resolución de DNS funciona para los Pods en el mismo nodo que el Pod coredns, pero no en todos los nodos. Este comportamiento podría indicar un problema de conectividad dentro del clúster.

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

Pods o nodos de red del host

Los pods de 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 host-red, usa los pasos para solucionar problemas de las secciones anteriores para probar si el DNS funciona correctamente en tus servidores de nombres upstream.

Verifica que todos los nodos tengan configurado el mismo conjunto de servidores. Si tienes configurados diferentes servidores de nombres, es posible que veas inconsistencias en la resolución de DNS en diferentes nodos. Para verificar que cada servidor de nombres funcione de forma individual, 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 incoherentes.

Problemas comunes de red

En las siguientes secciones, se detallan algunos problemas comunes de redes que puedes encontrar. Para resolver el problema, sigue las instrucciones de solución de problemas 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. Se espera que esto suceda cuando hay una gran cantidad de solicitudes a un nodo. 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 eBPF. El estado incluye el servicio, el seguimiento de conexión, la identidad del Pod y las reglas de la política 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 servicios 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 64K, límpialo. 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 agregar el estado al mapa de eBFP, reinicia anetd.

El nodo no está listo debido a errores de NetworkPluginNotReady

Si el Pod de CNI no se ejecuta 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

Es posible que el nodo también esté en un estado 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 verifica kubelet es que el complemento de la interfaz de red de contenedor (CNI) esté instalado. El complemento de CNI debe instalarse con anetd mediante un contenedor de inicialización para instalar el objeto binario y la configuración de CNI en los directorios de host requeridos.

Para solucionar este problema, verifica por qué esos pods no se ejecutan 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 para solucionar el problema y determinar su causa:

    • Si el Pod está en un estado Crashlooping, revisa los registros para ver por qué no se puede ejecutar correctamente.
    • 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 volumen.
    • Si el Pod está en el 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.
    • Hay una opción de configuración en anetd llamada custom-cni-conf. Si este parámetro de configuración se configura como true, anetd no instalará su objeto binario de CNI.

El nodo NO ESTÁ LISTO debido a entradas ARP inactivas

A veces, las entradas de ARP inactivas en los nodos del plano de control del clúster de administrador pueden causar una discrepancia en las direcciones MAC. A su vez, esta discrepancia de direcciones puede provocar tiempos de espera de conexión a las VIP del plano de control de los clústeres de usuarios administrados. Los tiempos de espera de la conexión pueden provocar que el nodo con entradas de ARP inactivas se marque como NOT READY. Los nodos marcados como NOT READY pueden detener las instalaciones y las actualizaciones del clúster.

En esta situación, el registro de kubelet en el nodo con entradas de ARP inactivas contiene un error de tiempo de espera de protocolo de enlace TLS, como el siguiente:

failed to get API group resources: unable to retrieve the complete list of server APIs: v1: Get "https://128.160.252.101:443/api/v1": net/http: TLS handshake timeout

Sigue estos pasos para verificar y resolver el problema:

  1. Usa SSH para conectarte al nodo del plano de control del clúster de usuario.

  2. Verifica la dirección MAC de la interfaz a la que está vinculada la dirección VIP:

    ip a | grep DEVICE_NAME: -A 6

    Reemplaza DEVICE_NAME por el nombre del dispositivo de red del nodo del plano de control.

  3. Usa SSH para conectarte a un nodo del plano de control del clúster de administrador.

  4. Verifica la caché de ARP en el plano de control del clúster de administrador para la dirección VIP del plano de control del clúster de usuario:

    ip n | grep VIP_ADDRESS

    Reemplaza VIP_ADDRESS por la dirección IP de la VIP del plano de control del clúster de usuario (controlPlaneVIP).

    Si los dos comandos ip muestran una dirección MAC diferente, significa que este problema te afecta.

  5. Para resolver el problema, borra la caché de ARP en el nodo del plano de control del clúster de administrador:

    ip n flush all

El servicio de F5 no recibe tráfico

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

  1. Verifica que cada partición de 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, se producen interrupciones intermitentes de la conexión. Este comportamiento se debe a que dos clústeres intentan tomar el control de la misma partición y borrar servicios de otros clústeres.

  2. Verifica que los siguientes dos pods se estén ejecutando. Los Pods que no se ejecutan indican un error:

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

    El Load-balancer-f5 es propiedad de GKE Enterprise y crea ConfigMaps para cada servicio de tipo LoadBalancer. El controlador bigip consume el ConfigMap con el tiempo.

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

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

    El servicio kube-server debe 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 del ConfigMap debe tener la VIP y el puerto del 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 tu instancia de BIG-IP. Si el ConfigMap está configurado correctamente, pero la instancia de BIG-IP no respeta la configuración, podría ser un problema de F5. Si se producen problemas dentro de la instancia de BIG-IP, comunícate con el equipo de asistencia de F5 para diagnosticarlos y solucionarlos.

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 acerca a 32,767, comienzas a ver caídas de paquetes para las conexiones que necesitan NAT.

Para determinar si este problema te afecta, sigue estos pasos:

  1. Ejecuta el siguiente comando en el pod anetd en el 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 a este problema, redistribuye el tráfico a otros nodos.

¿Qué sigue?

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