Solucionar problemas de redes de Google Distributed Cloud

En esta página se explica cómo resolver problemas de red con Google Distributed Cloud. Se proporciona información y orientación generales para solucionar problemas, así como herramientas sugeridas. También se incluye información para solucionar problemas de DNS y algunos problemas habituales de MetalLB.

Solución de problemas de conectividad de red

La red de GKE Enterprise se basa en tu infraestructura de red física. Por ejemplo, MetalLB depende de que tus conmutadores respeten el protocolo ARP gratuito, el balanceo de carga agrupado con el protocolo de puerta de enlace de frontera (BGP) depende de tus routers y todos los nodos deben poder comunicarse entre sí. Si 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, después, intenta identificar los componentes afectados. El ámbito de un problema puede pertenecer a una de estas tres categorías: el asunto (desde dónde), el objetivo (hacia dónde) y la capa de red.

El ámbito del asunto puede ser uno de los siguientes:

  • Todos los nodos (o el pod hostNetwork) de todo el clúster.
  • Todos los pods de todo el clúster.
  • Todos los pods de un solo nodo o de un conjunto de nodos.
  • Todos los pods de la misma implementación o DaemonSet.
  • Cliente de fuera del clúster.

El ámbito del objetivo puede ser uno o varios de los siguientes:

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

La capa de red puede ser una o varias de las siguientes:

  • Problemas de la capa de enlace de nivel 2, como el sistema vecino, ARP o NDP.
  • Problemas de enrutamiento de direcciones IP de capa 3.
  • Problemas con los endpoints TCP o UDP de la capa 4.
  • Problemas de HTTP o HTTPS de la capa 7.
  • Problemas de resolución de DNS.

Conocer el alcance de un problema ayuda a identificar los componentes implicados en él y en qué capa se produce. Recopilar información cuando se produce el problema es importante porque algunos problemas son temporales, por lo que las capturas de pantalla después de que el sistema se recupere no incluirán suficiente información para analizar la causa raíz.

Problemas de Ingress

Si el asunto es un cliente de fuera del clúster y no se ha podido conectar a un servicio de tipo LoadBalancer, se trata de un problema de conectividad norte-sur. En el siguiente diagrama se muestra que, en un ejemplo de funcionamiento, el tráfico entrante se desplaza por la pila de izquierda a derecha, y el tráfico de retorno se desplaza por 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 carga a anetd o kube-proxy y, a continuación, al backend.

Cuando haya un problema con este flujo de tráfico, utiliza el siguiente diagrama de flujo para identificar dónde se produce:

Solucionar problemas de entrada de red revisando cada paso que da un paquete a medida que se desplaza por tu entorno. Comprueba si se dan las acciones y la conectividad adecuadas durante el proceso.

En este diagrama de flujo, las siguientes indicaciones para solucionar problemas te ayudarán a determinar dónde se produce el problema:

  • ¿El paquete sale del cliente? Si no es así, es probable que tengas un problema con la infraestructura de red.
  • ¿Utilizas MetalLB? Si es así, ¿llega el paquete al nodo de balanceo de carga y se envía el ARP correctamente? Si no es así, es probable que tengas un problema con la infraestructura de red.
  • ¿Utiliza F5 BIG-IP? Si es así, ¿ha comprobado si hay problemas con F5?
  • ¿Se realiza correctamente la traducción de direcciones de red (NAT)? Si no es así, es probable que tengas un problema con kube-proxy o Dataplane V2.
  • ¿El paquete llega al nodo de trabajador? Si no es así, es probable que tengas un problema de Pod a Pod de Dataplane v2.
  • ¿El paquete llega al Pod? Si no es así, es probable que tengas un problema de reenvío local de Dataplane v2.

En las siguientes secciones se indican los pasos para solucionar problemas en cada fase y determinar si el tráfico fluye correctamente o no.

¿El paquete sale del cliente?

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

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

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Si no ves que sale tráfico, ese es el origen del problema.

¿El paquete llega a un nodo LoadBalancer?

Si usas MetalLB como balanceador de carga:

  1. Consulta el registro metallb-controller para determinar qué nodo del balanceador de carga sirve la IP virtual del servicio:

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

  2. Conéctate al nodo mediante SSH.

  3. En 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. En función de la configuración del balanceador de carga, 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 carga, ya que MetalLB no hace NAT antes de reenviar el paquete a los nodos.

    Si no ve tráfico en ningún nodo, ese es el origen del problema.

¿Hay algún problema con F5 BIG-IP?

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

¿Se envía correctamente el ARP?

El nodo del balanceador de carga de MetalLB se basa en ARP para anunciar la dirección IP virtual del servicio. Si la respuesta ARP se envía correctamente, pero no entra tráfico, significa que hay un problema en tu infraestructura de red física. Una causa habitual de este problema es que algunas funciones de aprendizaje de planos de datos avanzados ignoran la respuesta ARP en soluciones de redes definidas por software (SDN).

  1. Usa tcpdump para detectar respuestas ARP:

    tcpdump -ni any arp

    Intenta encontrar el mensaje que anuncia el VIP con el que tienes problemas.

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

¿Se realiza NAT?

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

  1. Usa tcpdump para comprobar si el VIP de servicio se ha traducido correctamente:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

  2. En Dataplane v2, también puedes conectarte a los pods anetd y usar las herramientas de depuración de Cilium integradas:

    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 de trabajador?

En los nodos de trabajo, el paquete llega a la interfaz externa y, a continuación, se entrega a los pods.

  1. Comprueba si el paquete llega a la interfaz externa, que suele llamarse 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 desencapsula el paquete, sale de una interfaz de red llamada cilium_geneve.

Como los back-ends de servicio normales contienen varios pods en diferentes nodos, puede ser difícil determinar qué nodo tiene un fallo. Una solución habitual es capturar el problema durante el tiempo suficiente para que llegue algún paquete o limitar el número de back-ends a uno.

Si el paquete nunca llega al nodo de trabajo, significa que hay un problema con la infraestructura de la red. Ponte en contacto con el equipo de infraestructura de redes para saber por qué se descarta el paquete entre los nodos de LoadBalancer y los nodos de trabajador. Estos son algunos de los problemas habituales:

  • Consulta 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 protección contra la suplantación de identidad.
  • Reglas de cortafuegos que filtran paquetes Geneve en el puerto UDP 6081.

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 redes de host, no es necesario realizar este paso porque el pod comparte el espacio de nombres de red con el nodo. De lo contrario, se requiere un reenvío de paquetes adicional.

Cada pod tiene pares de interfaces Ethernet virtuales, que funcionan como tuberías. Un paquete enviado 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 CNIs tienen esquemas diferentes. En Dataplane v2, la interfaz suele llamarse lxcxxxx. Los nombres tienen números de interfaz consecutivos, como lxc17 y lxc18. Puedes comprobar si el paquete llega al Pod con tcpdump o especificar la interfaz:

tcpdump -ni lcxxxx host BACKEND_POD_IP and port CONTAINER_PORT

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

ip route

Normalmente, cada pod debe tener una entrada de enrutamiento que enrute la dirección IP del pod a la interfaz lxc. Si falta la entrada, normalmente significa que la ruta de datos de CNI tiene un error. Para determinar la causa principal, consulta los registros de CNI DaemonSet.

Problemas de salida

Si el tráfico puede entrar en un pod, es posible que tengas un problema con el tráfico cuando salga del pod. En los siguientes diagramas se muestra que, en un ejemplo de funcionamiento, el tráfico entrante se desplaza 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, a continuación, al servicio externo.

  1. Para verificar que el paquete saliente se hace pasar correctamente por la dirección IP del nodo, comprueba 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 dirección de red de origen (NAT de origen o SNAT). En Dataplane v2, este proceso se lleva a cabo mediante ebpf, que se carga en una interfaz externa.

    Usa tcpdump para comprobar si la dirección IP de origen se ha traducido 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 han enmascarado correctamente, pero el servicio remoto no responde, comprueba la conexión al servicio externo en tu infraestructura.

  2. Si los paquetes salientes se enmascaran correctamente como la dirección IP del nodo, comprueba 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, comprueba la conexión al servicio externo en tu infraestructura.

Problemas en el clúster

Si tienes problemas de conectividad entre pods, intenta acotar el problema a los nodos. A menudo, un grupo de nodos no puede comunicarse con otro grupo de nodos.

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

    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 "Problema de conectividad de un origen a un destino" no proporciona información suficiente para resolver el problema, que podría ser un error de aplicación, un problema de enrutamiento o un problema de DNS. Saber en qué capa se produce el problema ayuda a corregir el componente adecuado.

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 HTTP indican que se trata de un problema de la capa 7.
    • Los códigos HTTP 40x y 50x, o los errores de handshake de TLS, significan que todo funciona correctamente en la capa 4.
  • Los errores "Connection reset by peer" indican que se trata de un problema de la capa 4.
    • Muchas veces, el socket remoto no puede estar de acuerdo con el estado actual de una conexión y, por lo tanto, envía un paquete RESET. Este comportamiento podría deberse a un error en el seguimiento de conexiones o en NAT.
  • Los errores "No hay ruta al host" y "Tiempo de espera de conexión agotado" suelen ser problemas 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, una configuración incorrecta de los nodos, los conmutadores de la parte superior del rack (ToR), los routers de la red troncal o los cortafuegos también puede provocar 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 con tu infraestructura física.

Ping

Ping funciona en la capa 3 (capa IP) y comprueba la ruta entre un origen y un destino. Si el ping no llega a un destino, suele significar que el problema se encuentra en la capa 3.

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

Los balanceadores de carga BGPLB y MetalLB de Google Distributed Cloud funcionan en la capa 3. Puedes usar ping para comprobar la conectividad. Aunque F5 es diferente, también admite ICMP. Puedes usar ping para comprobar la conectividad con el VIP de F5.

Arping

Arping es similar a ping, pero 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 ayudarte 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, se trata de un problema de la capa 2.

Si la acción se realiza correctamente, arping <ip> devuelve 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 nodos.

Arping también puede detectar conflictos de direcciones IP. Un conflicto de direcciones IP se produce 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 IP virtual. Los conflictos de direcciones IP pueden provocar problemas intermitentes difíciles de solucionar. Si arping <ip> devuelve más de una entrada de dirección MAC, significa que hay un conflicto de direcciones IP.

Una vez que hayas obtenido la dirección MAC con 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 está intentando usar la misma dirección IP. Por ejemplo, VMware es el propietario del bloque 00:50:56, por lo que la dirección MAC 00:50:56:xx:yy:zz es una máquina virtual de tu 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 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, puede haber problemas de conectividad desde el nodo. Anetd gestiona la tabla de rutas y la tabla de vecinos. Si esas tablas no están bien configuradas, pueden producirse problemas de conectividad.

CLI de Cilium o Hubble para Dataplane v2

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

  • cilium monitor --type=drop
    • Imprime el registro de cada paquete que se haya descartado por anetd o 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 de anetd comprueba el estado de todos los demás nodos del clúster y puede ayudar a determinar cualquier 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 eliminación y comprueba el número de paquetes y de bytes para ver si aumentan con el tiempo.

Tcpdump

Tcpdump es una potente herramienta de captura de paquetes que genera una gran cantidad de datos de tráfico de red. Una práctica habitual es ejecutar tcpdump tanto desde el origen como desde 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 lo elimina. Este comportamiento suele indicar que algo en tu infraestructura física deja caer el paquete por error.

Métricas

Google Distributed Cloud contiene varias métricas que te ayudan a monitorizar el comportamiento de tu red. Las siguientes métricas son un buen punto de partida:

Categoría Métrica Descripción
Paquetes perdidos cilium_drop_bytes_total Total de bytes descartados, etiquetados por el motivo del descarte y la dirección de entrada o salida. Esta métrica es un buen punto de partida para investigar las pérdidas a nivel de bytes.
cilium_drop_count_total Total de paquetes descartados, etiquetados por el motivo del descarte y la dirección de entrada o salida. direction.
container_network_receive_packets_dropped_total Recuento acumulativo de paquetes descartados durante la recepción. Se muestrea cada 60 segundos.
container_network_transmit_packets_dropped_total Recuento acumulativo de paquetes descartados durante la transmisión. Se muestrea cada 60 segundos.
Paquetes reenviados cilium_forward_bytes_total Total de bytes reenviados, etiquetados por dirección de entrada o salida. Se muestrea cada 60 segundos. Esta métrica te proporciona información de reenvío a nivel de byte.
cilium_forward_count_total Total de paquetes reenviados, etiquetados por dirección de entrada o salida. Se muestrea cada 60 segundos. Esta métrica indica el número de paquetes del tráfico reenviado.
cilium_policy_l7_forwarded_total Total de solicitudes reenviadas de nivel 7.
Paquetes recibidos cilium_policy_l7_received_total Número total de solicitudes o respuestas de nivel 7 recibidas. Se muestrea cada 60 segundos.
container_network_receive_bytes_total Recuento acumulativo de bytes recibidos. Se muestrea cada 60 segundos.
container_network_receive_packets_total Recuento acumulativo de paquetes recibidos. Se muestrea cada 60 segundos.
container_network_receive_errors_total Recuento acumulado de errores detectados al recibir. Se muestrea cada 60 segundos.
cilium_kubernetes_events_received_total Número de eventos de Kubernetes recibidos etiquetados por ámbito, acción, datos válidos e igualdad. Se muestrea cada 60 segundos.
BPF cilium_bpf_maps_virtual_memory_max_bytes Tamaño máximo de uso de memoria del kernel de los mapas BPF en bytes.
cilium_bpf_progs_virtual_memory_max_bytes Tamaño máximo de uso de memoria del kernel de los programas BPF en bytes.
Conntrack node_nf_conntrack_entries Número de entradas de flujo asignadas actualmente para el seguimiento de conexiones. Se muestrea cada 60 segundos.
node_nf_conntrack_entries_limit Tamaño máximo de la tabla de seguimiento de conexiones. Se muestrea cada 60 segundos.
Conectividad cilium_node_connectivity_latency_seconds La última latencia observada entre el agente de Cilium actual y otros nodos de Cilium en segundos. Se muestrea cada 60 segundos.
cilium_node_connectivity_status El último estado observado de la conectividad ICMP y HTTP entre el agente de Cilium actual y otros nodos de Cilium. Se muestrea cada 60 segundos.
Operadores de Cilium cilium_operator_process_cpu_seconds_total Tiempo total de CPU de usuario y del sistema empleado en segundos. Se muestrea cada 60 segundos.
cilium_operator_process_max_fds Número máximo de descriptores de archivo abiertos. Se muestrea cada 60 segundos.
cilium_operator_process_open_fds Número de descriptores de archivo abiertos. Se muestrea cada 60 segundos.
cilium_operator_process_resident_memory_bytes Tamaño de la memoria residente en bytes. Se muestrea cada 60 segundos.
cilium_operator_process_start_time_seconds Hora de inicio del proceso desde el inicio de la época Unix, en segundos. Se muestrea cada 60 segundos.
cilium_operator_process_virtual_memory_bytes Tamaño de la memoria virtual en bytes. Se muestrea cada 60 segundos.
cilium_operator_process_virtual_memory_max_bytes Cantidad máxima de memoria virtual disponible en bytes. Se muestrea cada 60 segundos.
cilium_operator_identity_gc_entries El número de identidades activas y eliminadas al final de una ejecución del recolector de elementos no utilizados. Se muestrea cada 60 segundos.
cilium_operator_identity_gc_runs Número de veces que se ha ejecutado el recolector de elementos no utilizados de identidades. Se muestrea cada 60 segundos.

Para recibir notificaciones cuando alguna de estas métricas supere o esté por debajo de un umbral determinado, crea políticas de alertas. Para obtener más información, consulta Crear políticas de alertas.

Para obtener más información sobre estas métricas y ver la lista completa, consulta el artículo Métricas de Google Distributed Cloud.

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 del clúster.
  • Pods o nodos de red de host que no usan servidores DNS del clúster

En las siguientes secciones se proporciona información sobre la arquitectura DNS de los clústeres y algunos consejos útiles antes de empezar a solucionar problemas de una de estas categorías.

Arquitectura de DNS de clúster

Un servicio de 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 que se encarga de escalar el número de pods de DNS en función del tamaño del clúster. También hay un servicio llamado kube-dns que balancea la carga de las solicitudes entre todos los pods de backend coredns.

La mayoría de los pods tienen su DNS upstream configurado en la dirección IP del servicio kube-dns y los pods envían solicitudes 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, se trata de un nombre de DNS del clúster que hace referencia a un servicio o a un pod del clúster.
    • CoreDNS monitoriza 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 upstream. 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 el DNS en Kubernetes.

Consejos 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 comprobar 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 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 petición de DNS que con 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, significa que hay un problema con la resolución de DNS.

Pódcasts habituales

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 de clúster se manifiesta como un problema 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 existe 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 que el servidor no ha podido resolver el nombre de dominio:

  • Los errores NXDOMAIN indican que el servidor DNS informa de 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 ha enviado una respuesta, pero no ha podido resolver el dominio o validar que no existe. Para obtener más información, consulta los registros de los coredns pods.

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 no funcione el DNS, intenta enviar una solicitud DNS a esta dirección IP con dig o nslookup, tal como se explica en una sección anterior:

  • Si estas solicitudes no funcionan, prueba a enviar solicitudes a la dirección IP de cada Pod de coredns.
  • Si algunos pods funcionan, pero otros no, comprueba si hay algún patrón discernible, como que la resolución de DNS funcione en los pods del mismo nodo que el pod coredns, pero no en otros nodos. Este comportamiento podría indicar un problema de conectividad en el clúster.

Si CoreDNS no puede resolver nombres de dominio externos, consulta la siguiente sección para solucionar problemas con los pods de red de 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 de host

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

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

Verifica que todos los nodos tengan el mismo conjunto de servidores configurado. Si tienes configurados servidores de nombres diferentes, es posible que veas incoherencias en la resolución de DNS en diferentes nodos. Verifica que cada servidor de nombres funciona por separado enviando una solicitud a cada uno de ellos mediante dig o nslookup. Si algunos servidores de nombres funcionan, pero otros no, se producirán errores de resolución de DNS incoherentes.

Problemas de red habituales

En las siguientes secciones se detallan algunos problemas de red habituales que pueden surgir. Para solucionar el problema, sigue las instrucciones correspondientes. Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

Dataplane v2 / Cilium

Error habitual: [PUT /endpoint/{id}][429] putEndpointIdTooManyRequests

Este error significa que el agente de Cilium ha rechazado el evento de creación de pods debido a un límite de frecuencia. En cada nodo, Cilium tiene un límite de cuatro solicitudes simultáneas al endpoint PUT. Este comportamiento es normal cuando hay un pico 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 los nodos más potentes.

Error habitual: Ebpf map size is full

Dataplane v2 almacena el estado en un mapa eBPF. El estado incluye el servicio, el seguimiento de la 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 consultar las entradas del mapa eBFP y su tamaño actual, usa bpftool. En el siguiente ejemplo se comprueban los mapas del balanceador de carga:

    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 000, límpialo. En el siguiente ejemplo se limpian las asignaciones del balanceador de carga:

    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 rellenar el estado en el mapa eBFP, reinicia anetd.

El nodo no está listo debido a errores de 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 en un estado no preparado, con un error similar al del siguiente ejemplo:

  "Network plugin not installed"

Cuando se inicializa un nodo, kubelet espera a que se produzcan varios eventos antes de marcar el nodo como Ready. Uno de los eventos que comprueba kubelet es que el complemento Container Network Interface (CNI) esté instalado. anetd debe instalar el complemento CNI mediante un contenedor init para instalar el archivo binario CNI y la configuración CNI en los directorios host necesarios.

Para solucionar este problema, comprueba por qué no se están ejecutando esos pods 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 ninguna dependencia de red.

  1. Comprueba el estado del anetd Pod. Sigue estos pasos para determinar la causa del problema:

    • Si el pod está en estado Crashlooping, consulta los registros para ver por qué no se puede ejecutar correctamente.
    • Si el pod está en estado Pending, usa kubectl describe y consulta los eventos del pod. Por ejemplo, puede que al pod le falte un recurso, como un volumen.
    • Si el pod está en estado Running, comprueba los registros y la configuración. Algunas implementaciones de CNI ofrecen 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 ajuste se configura como true, anetd no instalará su archivo binario CNI.

El nodo NO ESTÁ PREPARADO debido a entradas ARP obsoletas

A veces, las entradas ARP obsoletas en los nodos del plano de control del clúster de administrador pueden provocar un desajuste en las direcciones MAC. Esta falta de coincidencia de direcciones puede provocar que se agote el tiempo de espera de la conexión a las IPs virtuales del plano de control de los clústeres de usuarios gestionados. Los tiempos de espera de la conexión pueden provocar que el nodo con entradas ARP obsoletas se marque como NOT READY. Los nodos marcados como NOT READY pueden detener las instalaciones y las actualizaciones de clústeres.

En esta situación, el registro de kubelet del nodo con entradas ARP obsoletas contiene un error de tiempo de espera de handshake de TLS similar al 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 solucionar el problema:

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

  2. Verifica la dirección MAC de la interfaz a la que está enlazada la dirección IP virtual:

    ip a | grep DEVICE_NAME: -A 6

    Sustituye 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. Comprueba la caché ARP en el plano de control del clúster de administración para la dirección VIP del plano de control del clúster de usuarios:

    ip n | grep VIP_ADDRESS

    Sustituye VIP_ADDRESS por la dirección IP de la IP virtual del plano de control del clúster de usuarios (controlPlaneVIP).

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

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

    ip n flush all

El servicio F5 no recibe tráfico

Si no se envía tráfico al servicio F5, sigue estos pasos para solucionar el problema:

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

  2. Comprueba que los dos pods siguientes se están ejecutando. Si hay algún pod que no se esté ejecutando, significa que hay un error:

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

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

  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 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 de ConfigMap debe incluir el VIP y el puerto del frontend, tal 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. Comprueba 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 tratarse de un problema de F5. Si tienes problemas con la instancia de BIG-IP, ponte en contacto con el equipo de Asistencia de F5 para diagnosticar y solucionar los problemas.

Error de NAT con demasiadas conexiones paralelas

En un nodo determinado de 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 acceden a un nodo de balanceo de carga configurado para usar el balanceo de carga agrupado (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 se reenvíen a un pod de backend.

El intervalo de puertos de NAT que usa Google Distributed Cloud es 32768-65535. Este intervalo limita el número 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 obsoletas, pero la limpieza no es inmediata.

Cuando el número de conexiones de tu nodo se acerca a 32.767, empiezan a perderse paquetes de las conexiones que necesitan NAT.

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

  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 errores con el siguiente formato:

    No mapping for NAT masquerade DROPPED

Para solucionar este problema, redistribuye el tráfico a otros nodos.

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud. También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

  • Requisitos para abrir un caso de asistencia.
  • Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
  • Componentes admitidos.