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 general para la solución de problemas, junto con herramientas sugeridas. También se incluye información sobre la solución de problemas de DNS y algunos problemas habituales de Calico, Seesaw y 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 la infraestructura de red física. Por ejemplo, Seesaw o MetalLB se basan en tus conmutadores en función del 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 se encuentra 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 de tres categorías: el asunto (de dónde), el objetivo (a cuál) y la capa de red.

El alcance del sujeto puede ser uno de los siguientes:

  • Todos los nodos (o Pod hostNetwork) de todo el clúster
  • Todos los Pods en todo el clúster
  • Todos los Pods en un solo nodo o en un conjunto de nodos.
  • Todos los Pods de la misma Deployment o DaemonSet.
  • Un cliente 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 Service ClusterIP del mismo clúster.
  • VIP del Service de tipo LoadBalancer del mismo clúster.
  • LoadBalancer de la capa 7 de Ingress (Istio).
  • Otros nodos del mismo clúster.
  • Es el nombre de DNS interno (como *.svc.cluster.local).
  • Es el nombre de DNS externo (como google.com).
  • Entidades externas al clúster.
  • Entidades en Internet.

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

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

Comprender el alcance de un problema ayuda a identificar los componentes involucrados y en qué capa se produce. Recopilar información cuando ocurre el problema es importante, ya que algunos problemas son temporales, por lo que las instantáneas después de que el sistema se recupere 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 se pudo conectar a un Service LoadBalancer, es 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 regresa a través de la pila de derecha a izquierda. Seesaw es diferente, ya que el tráfico de retorno omite el balanceador de cargas y regresa directamente al cliente:

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. Con Seesaw, el tráfico de salida omite el balanceador de cargas.

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

Para solucionar problemas de entrada de red, revisa cada paso que realiza un paquete a medida que se mueve por tu entorno. Comprueba si se cuentan con las acciones y la conectividad adecuadas.

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

  • ¿El paquete sale del cliente? Si no es así, es probable que tengas un problema de infraestructura de red.
  • ¿Estás usando el balanceador de cargas de Seesaw? Si es así, ¿el paquete llega al nodo de Seesaw y, luego, se envía el ARP de forma correcta? 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 se envía el ARP 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? Si es así, ¿comprobaste si hay problemas de F5?
  • ¿La traducción de direcciones de red (NAT) se realiza correctamente? Si no es así, es probable que tengas un problema de kube-proxy / Dataplane V2.
  • ¿El paquete llega al nodo trabajador? Si no es así, es probable que tengas un problema de Pod a Pod de Calico o Dataplane v2.
  • ¿El paquete llega al Pod? De lo contrario, es probable que tengas un problema de reenvío local de Calico o Dataplane v2.

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

¿El paquete sale del cliente?

Verifica si el paquete abandona el cliente de forma correcta 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 que se reduzca el tráfico, esa es la causa del problema.

¿El paquete llega a un nodo de Seesaw?

Si usas Seesaw como el balanceador de cargas, busca el nodo principal y, luego, conéctate a él mediante SSH.

  1. Usa tcpdump para verificar si los paquetes esperados llegaron al nodo de Seesaw:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

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

¿El paquete llega a un nodo LoadBalancer?

Si usas MetalLB como balanceador de cargas, ten en cuenta lo siguiente:

  1. Observa 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. Para un nodo de MetalLB, usa tcpdump a fin de revisar el tráfico:

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Para ManualLB, el tráfico puede 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 y Seesaw no aplican NAT antes de reenviar el paquete a los nodos.

    Si no ves tráfico que entra a ningún nodo, esa es la fuente del problema.

¿Hay un problema con la BIG-IP de 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.

¿Se envía el ARP de forma correcta?

El nodo del balanceador de cargas para MetalLB o Seesaw se basa en ARP para anunciar la VIP del servicio. Si la respuesta ARP se envía correctamente, pero el tráfico no entra, 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 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 a la persona VIP con la que tienes problemas.

    • En el caso de Seesaw, se envían ARP injustificados para todos los VIP. Deberías ver los mensajes ARP para cada VIP cada 10 segundos.

    • 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) o un interruptor virtual, envía una solicitud ARP.

¿Se realiza 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 al nodo 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. 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 los 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, por lo general, llamada eth0 o ens192, mediante tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

Debido a que los backends de Service normales contienen varios Pods en diferentes nodos, puede ser difícil solucionar qué nodo falla. 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 en la infraestructura de red. Verifica con el equipo de infraestructura de red para ver por qué el paquete se descarta entre los nodos LoadBalancer y los nodos trabajadores. Estos son algunos problemas comunes:

  • Verifica los registros de tu 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 falsificación de identidad.
  • Reglas de firewall que filtran paquetes cuyo destino son el puerto y la dirección IP del Pod del backend.

Si el paquete llega a la interfaz externa o a la interfaz de túnel del nodo, 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 requiere reenvío de paquetes adicional.

Cada Pod tiene pares de interfaces Ethernet virtuales, que funcionan como canalizaciones. Un paquete enviado a un extremo de la interfaz se recibe desde el otro extremo. 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 guarda en el espacio de nombres del host. Las diferentes CNI tienen un esquema diferente. En Dataplane v2, la interfaz se llama normalmente 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 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, normalmente significa que la ruta de datos de la 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 ingresar a un Pod, es posible que tengas un problema con el tráfico cuando sale del Pod. En los siguientes diagramas, se muestra que, en un ejemplo funcional, el tráfico entrante viaja a través de 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 enmascara correctamente como 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 de origen o SNAT). En Dataplane v2, este proceso se logra mediante ebpf que se carga en una interfaz externa. Calico usa reglas de iptables.

    Usa tcpdump para verificar si la dirección IP de origen se tradujo 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 se enmascararon de forma correcta, pero el servicio remoto no responde, verifica la conexión al servicio externo en tu infraestructura.

  2. Si los paquetes salientes se enmascaran de forma correcta 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, 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

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

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

    cilium status --all-health

    Google Distributed Cloud usa el modo de enrutamiento directo. Deberías ver una entrada de ruta por nodo en el clúster, como se muestra en el siguiente ejemplo:

    # <pod-cidr> via <node-ip> dev <external-interface>
192.168.1.0/24 via 21.0.208.188 dev ens192
192.168.2.0/24 via 21.0.208.133 dev ens192

    Si falta una ruta esperada para un nodo, se pierde la conexión con ese nodo.

Problemas con 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 resolver el problema, ya que podría ser un error de la 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 implican que todo funciona normalmente en la capa 4.
  • Los errores de "Restablecimiento de la conexión por pares" indican que se trata de un problema de la capa 4.
    • Muchas veces, el socket remoto no puede aceptar el estado actual de una conexión, por lo que envía un paquete RESET. Este comportamiento podría ser un error en el seguimiento de conexiones o NAT.
  • Los errores “No hay 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 tus nodos, los interruptores de la parte superior del bastidor (ToR), los routers de columna 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 los nodos de GKE Enterprise o la infraestructura física.

Ping

El 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, suele significar 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, MetalLB y Seesaw en Google Distributed Cloud funcionan en la capa 3. Puedes hacer ping para comprobar la conectividad. Aunque F5 es diferente, también admite 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 las capas 2 y 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 hacer un arping al destino, es un problema de capa 2.

Si arping <ip> funciona correctamente, se mostrará la dirección MAC del destino. En la capa 2, esta dirección a menudo indica un problema de infraestructura física. Este problema es una configuración incorrecta del interruptor virtual.

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 otra máquina física usa una VIP. Los conflictos de direcciones IP pueden crear problemas intermitentes difíciles de solucionar. Si arping <ip> muestra más de una entrada de dirección MAC, es una indicación de que hay un conflicto de dirección IP.

Después de obtener la dirección MAC del 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 el entorno de vSphere.

iproute2

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

  • ip r: Imprime la tabla de rutas.
  • ip n: Imprime la tabla de vecino para la asignación de dirección IP a dirección MAC.
  • ip a: Imprime todas las interfaces en la máquina.

Una ruta faltante o una entrada faltante en la tabla de vecinos podría causar problemas de conectividad del nodo. Anetd y Calico administran la tabla de rutas y la de vecinos. 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 de cada paquete que descarta anetd / Cilium.
  • hubble observe
    • Imprime todos los paquetes que pasan por la pila ebpf de anetd.
  • cilium status --all-health
    • Imprime el estado de Cilium, incluido el estado de conectividad de nodo a nodo. Cada Pod adecuado 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

Las iptables se usan en muchos componentes y subsistemas de Kubernetes. kube-proxy usa iptables para implementar la resolución del servicio. Calico usa iptables para implementar la política de red

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

    iptables -L -v | grep DROP

    Revisa las reglas de la opción de descartar 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. 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. 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 regulares, 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 problemas de una de estas categorías.

Arquitectura del DNS del clúster

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

Cada clúster tiene dos o más Pods de coredns y un escalador automático que es 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 de backend coredns.

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 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 pod en el clúster.
    • CoreDNS supervisa api-server en 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 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 de cómo funciona y se configura un DNS en Kubernetes.

Sugerencias para solucionar problemas de DNS

Para solucionar problemas de DNS, puedes usar las herramientas de 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 comprobar si hay problemas de resolución de DNS.

  • Usa dig o nslookup a fin de enviar una solicitud para 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 ninguna respuesta, 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, 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. 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 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 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 buscar 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 de coredns.
  • Si algunos Pods funcionan, pero no otros, verifica si hay patrones perceptibles, por ejemplo, si la resolución de DNS funciona para los Pods en el mismo nodo que el Pod coredns, pero no entre nodos. Este comportamiento podría indicar algún problema de conectividad en el clúster.

Si CoreDNS no puede resolver los nombres de dominio externo, consulta la siguiente sección para solucionar problemas de los Pods de la red del host. CoreDNS se comporta como un Pod de red 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 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 la red de host, sigue los pasos para solucionar problemas de las secciones anteriores a fin de probar si el DNS funciona correctamente en tus servidores de nombres ascendentes.

Problemas comunes de red

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

Calico

Error común: calico/node is not ready: BIRD is not ready: BGP not established

Por lo general, este error de estado "no listo" en Kubernetes significa que no se puede acceder a un par en particular en el clúster. Comprueba que la conectividad BGP entre los dos pares esté permitida en tu entorno.

Este error también puede ocurrir si se configuran recursos de nodo inactivos para la malla de nodo a nodo. Para solucionar este problema, retira los nodos inactivos.

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. Por cada nodo, Cilium tiene un límite de cuatro solicitudes simultáneas al extremo PUT. Este comportamiento es el esperado cuando hay un aumento de actividad de solicitudes a un nodo. El agente de Cilium debería ponerse al día con las solicitudes retrasadas.

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 en 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 las reglas de Service, Connect, Identity, Pod y Policy Policy. 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 servicio tiene un límite de 64,000 entradas.

  1. Para verificar las entradas de mapa de eBFP y su tamaño actual, utiliza 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 ct, limpia los mapas. 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 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 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 kubelet verifica es que el complemento Container Network Interface (CNI) esté instalado. Anetd o Calico deben instalar el complemento CNI con un contenedor init para instalar el objeto binario de 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 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 o calico-node. Revisa los siguientes pasos de solución de problemas para determinar la causa del problema:

    • Si el Pod está en 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.
    • Hay una opción de configuración en anetd llamada custom-cni-conf. Si esta configuración está configurada 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, experimentas interrupciones de conexión intermitentes. Este comportamiento se debe a que dos clústeres intentan tomar el control de la misma partición y borrar los Services de otros clústeres.

  2. Verifica que los dos Pods siguientes estén en ejecución. Cualquier pod que no se esté ejecutando indica un error:

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

    El Load-balancer-f5 que pertenece a GKE Enterprise y crea ConfigMaps para cada Service de tipo LoadBalancer. El controlador bigip consume el ConfigMap.

  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 el 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 tu instancia 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. En el caso de los problemas que ocurren dentro de la instancia de BIG-IP, comunícate con el equipo de asistencia de F5 para diagnosticarlos y solucionarlos.

¿Qué sigue?

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