Soluciona problemas de redes de Google Distributed Cloud

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

Solución de problemas de conectividad de red

Las redes de GKE Enterprise dependen de tu infraestructura de red física. Por ejemplo, Seesaw o MetalLB dependen de tus conmutadores 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 redes 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 pertenecer a una de las tres categorías siguientes: el sujeto (desde dónde), el objetivo (hacia dónde) y la capa de red.

El alcance del tema puede ser uno de los siguientes:

  • Todos los nodos (o el Pod de hostNetwork) en 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
  • 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 de Pods del mismo clúster
  • Todas las demás direcciones IP de Pod del mismo nodo
  • VIP del servicio ClusterIP del mismo clúster.
  • VIP del servicio LoadBalancer del mismo clúster
  • LoadBalancer de capa 7 de Ingress (Istio)
  • Otros nodos del mismo clúster
  • Nombre de DNS interno (como *.svc.cluster.local).
  • Nombre de DNS externo (como google.com)
  • Son entidades externas al clúster.
  • Son 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 vecino, ARP o NDP
  • Problemas de enrutamiento de direcciones IP de capa 3.
  • Problemas con los extremos 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 en el problema y en qué capa se produce. Recopilar información cuando ocurre el problema es importante porque algunos problemas son temporales, por lo que las instantáneas después de que se recupera el sistema no incluirán suficiente información para el análisis de la causa raíz.

Problemas de entrada

Si el sujeto es un cliente externo al clúster y no se pudo conectar a un Service 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 viaja a través de la pila de izquierda a derecha, y el tráfico de retorno viaja de vuelta 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 vuelve 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 o kube-proxy, y, luego, al backend. Con Seesaw, el tráfico de salida omite el balanceador de cargas.

Cuando hay 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:

Solucionar problemas de ingreso de red revisando cada paso que da un paquete a medida que 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 para solucionar problemas te 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.
  • ¿Usas el balanceador de cargas de Seesaw? Si es así, ¿el paquete llega al nodo de Seesaw y, luego, se envía el ARP correctamente? De lo contrario, es probable que tengas un problema con la infraestructura de red.
  • ¿Usas MetalLB? Si es así, ¿el paquete llega al nodo del LB y, luego, se envía el ARP correctamente? De lo contrario, es probable que tengas un problema de infraestructura de red.
  • ¿Usas BIG-IP de F5? Si es así, ¿verificaste 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 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 los 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 tu infraestructura de red física.

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

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    Si no ves tráfico saliente, este es el origen del problema.

¿El paquete llega a un nodo de Seesaw?

Si usas Seesaw, consulta la documentación de la versión 1.16, busca el nodo principal y, luego, conéctate al nodo con 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 tráfico entrante, este es el origen del problema.

¿El paquete llega a un nodo de LoadBalancer?

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

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

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

  2. Conéctate al nodo con SSH.

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

    tcpdump -ni any host SERVICE_VIP and port SERVICE_PORT

    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 y Seesaw no realizan NAT antes de reenviar el paquete a los nodos.

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

¿Hay un problema con BIG-IP de F5?

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 el ARP correctamente?

El nodo del balanceador de cargas de MetalLB o Seesaw se basa en ARP para anunciar la VIP del servicio. Si la respuesta del ARP se envía correctamente, pero no llega tráfico, es una señal de un problema en tu infraestructura de redes físicas. 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 redes definidas por software (SDN).

  1. Usa tcpdump para detectar respuestas ARP:

    tcpdump -ni any arp

    Intenta encontrar el mensaje en el que se promociona el VIP con el que tienes problemas.

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

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

¿Se realiza la 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 a una dirección IP de Pod de backend. Si sabes qué nodo es el backend del balanceador de cargas, conéctate a él con SSH.

  1. Usa tcpdump para verificar si la 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 de 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 / 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, que suele llamarse eth0 o ens192, con tcpdump:

    tcpdump -ni any host BACKEND_POD_IP and port CONTAINER_PORT

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

Si el paquete nunca llega al nodo de trabajo, es un indicio de un problema de infraestructura de red. Consulta al equipo de infraestructura de redes para saber por qué se descarta el paquete entre los nodos de LoadBalancer y los nodos trabajadores. 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 segmentación, suma de comprobación incorrecta o anti-suplantación.
  • Reglas de firewall que filtran paquetes cuyo destino es la dirección IP y el puerto del Pod de 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 redes de host, este paso no es necesario 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 cambia su nombre a eth0. La otra interfaz se mantiene en el espacio de nombres del host. Los diferentes CNI tienen esquemas diferentes. En el caso de Dataplane v2, la interfaz suele llamarse lxcxxxx. Los nombres tienen números de interfaz consecutivos, como lxc17 y lxc18. Puedes verificar si el paquete llega al Pod con 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

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 la CNI tiene un error. Para determinar la causa raíz, verifica 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 cuando sale del Pod. En los siguientes diagramas, se muestra que, en un ejemplo de trabajo, 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 enmascare 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 con 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 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 al 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, haz una prueba de ping desde uno de los Pods:

    kubectl exec POD_NAME ping EXTERNAL_IP

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

Problemas en el clúster

En el caso de problemas de conectividad de pod a pod, intenta delimitar 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:

    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 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 "Hay 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, un problema de enrutamiento o un problema de DNS. Comprender 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 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 deberse a un error en el seguimiento de conexiones o en la 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 con 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 se encuentra en la capa 3.

Sin embargo, no todas las direcciones IP pueden hacer 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 devuelve una respuesta de ping cuando especificas un número de puerto, como VIP:port.

Los balanceadores de cargas de BGPLB, MetalLB y Seesaw 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 la VIP de F5.

Arping

El Arping es similar al ping, excepto que funciona en la capa 2. Los problemas de capa 2 y capa 3 suelen tener mensajes de error similares de las aplicaciones. Arping y ping pueden ayudar a diferenciar el problema. Por ejemplo, si 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.

Un arping <ip> exitoso devuelve la dirección MAC del destino. En la capa 2, esta dirección suele indicar un problema de infraestructura física. Este problema se debe a una configuración incorrecta del conmutador virtual.

El Arping también puede detectar conflictos de direcciones IP. Se produce un conflicto de direcciones IP 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 generar problemas intermitentes que son difíciles de solucionar. Si arping <ip> devuelve más de una entrada de dirección MAC, es un indicio de que hay un conflicto de direcciones IP.

Después de obtener la dirección MAC de arping, puedes usar https://maclookup.app/ para buscar el fabricante de la dirección MAC. Cada fabricante posee un prefijo 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 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 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.

La falta de una ruta o de una entrada en la tabla de vecinos puede causar problemas de conectividad desde el nodo. Anetd y Calico administran 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 de anetd tiene varias herramientas de depuración útiles para problemas de conectividad:

  • cilium monitor --type=drop
    • Imprime el registro de cada paquete que descartan 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 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. 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 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 una gran cantidad de 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.

Métricas

Google Distributed Cloud contiene varias métricas para ayudarte a hacer un seguimiento del comportamiento de tu red. Las siguientes métricas proporcionan un buen punto de partida:

Categoría Métrica Descripción
Paquetes descartados cilium_drop_bytes_total Cantidad total de bytes descartados, etiquetados según el motivo de descarte y la dirección de entrada o salida. Esta métrica es un buen punto de partida para investigar las disminuciones a nivel de bytes.
cilium_drop_count_total Cantidad total de paquetes descartados, etiquetados por motivo de descarte y dirección de entrada o salida.
container_network_receive_packets_dropped_total Recuento acumulativo de paquetes descartados durante la recepción. Se toman muestras cada 60 segundos.
container_network_transmit_packets_dropped_total Recuento acumulativo de paquetes descartados durante la transmisión. Se toman muestras cada 60 segundos.
Paquetes reenviados cilium_forward_bytes_total Total de bytes reenviados, etiquetados según la dirección de entrada o salida. Se tomaron muestras cada 60 segundos. Esta métrica te proporciona información de reenvío a nivel de bytes.
cilium_forward_count_total Cantidad total de paquetes reenviados, etiquetados por dirección de entrada o salida. Se tomaron muestras cada 60 segundos. Esta métrica te proporciona el recuento de paquetes para el tráfico reenviado.
cilium_policy_l7_forwarded_total Es la cantidad total de solicitudes reenviadas de L7.
Paquetes recibidos cilium_policy_l7_received_total Cantidad total de solicitudes o respuestas de L7 recibidas. Se toman muestras cada 60 segundos.
container_network_receive_bytes_total Recuento acumulativo de bytes recibidos. Se hace un muestreo cada 60 segundos.
container_network_receive_packets_total Recuento acumulativo de paquetes recibidos. Se hace un muestreo cada 60 segundos.
container_network_receive_errors_total Recuento acumulativo de errores encontrados durante la recepción. Se toman muestras cada 60 segundos.
cilium_kubernetes_events_received_total Cantidad de eventos de Kubernetes recibidos, etiquetados por alcance, acción, datos válidos y equivalencia. Se hace un muestreo cada 60 segundos.
BPF cilium_bpf_maps_virtual_memory_max_bytes Son mapas de BPF que registran el tamaño máximo de uso de memoria del kernel 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 Es la cantidad de entradas de flujo asignadas actualmente para el seguimiento de conexiones. Se hace un muestreo cada 60 segundos.
node_nf_conntrack_entries_limit Es el tamaño máximo de la tabla de seguimiento de conexiones. Se hace un muestreo cada 60 segundos.
Conectividad cilium_node_connectivity_latency_seconds Es la última latencia observada entre el agente de Cilium actual y otros nodos de Cilium en segundos. Se hace un muestreo cada 60 segundos.
cilium_node_connectivity_status Es el último estado observado de la conectividad ICMP y HTTP entre el agente de Cilium actual y otros nodos de Cilium. Se hace un muestreo cada 60 segundos.
Operadores de Cilium cilium_operator_process_cpu_seconds_total Tiempo total de CPU del sistema y usuario de uso en segundos. Se toman muestras cada 60 segundos.
cilium_operator_process_max_fds Cantidad máxima de descriptores de archivos abiertos. Se hace un muestreo cada 60 segundos.
cilium_operator_process_open_fds Cantidad de descriptores de archivos abiertos. Se hace un muestreo cada 60 segundos.
cilium_operator_process_resident_memory_bytes Tamaño de la memoria residente en bytes. Se hace un muestreo cada 60 segundos.
cilium_operator_process_start_time_seconds Hora de inicio del proceso desde el ciclo de entrenamiento de Unix en segundos. Se toman muestras cada 60 segundos.
cilium_operator_process_virtual_memory_bytes Tamaño de la memoria virtual en bytes. Se hace un muestreo cada 60 segundos.
cilium_operator_process_virtual_memory_max_bytes Es la cantidad máxima de memoria virtual disponible en bytes. Se toman muestras cada 60 segundos.
cilium_operator_identity_gc_entries Cantidad de identidades activas y borradas al final de una ejecución del recolector de elementos no utilizados. Se hace un muestreo cada 60 segundos.
cilium_operator_identity_gc_runs Cantidad de veces que se ejecutó el recolector de elementos no utilizados de identidad. Se toman muestras cada 60 segundos.

Para recibir notificaciones cuando alguna de estas métricas supere o no alcance un umbral determinado, crea políticas de alertas. Para obtener más información, consulta Crea políticas de alertas de límite de métrica en la documentación de Cloud Monitoring.

Para obtener más información sobre estas métricas y ver la lista completa, consulta 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 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 que comiences 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 las versiones 1.9.0 y posteriores de Google Distributed Cloud.

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

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 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 de 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 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 de coredns o no. A menudo, un problema general de conectividad del clúster aparece 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 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 que 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 de 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 no funciona el DNS, 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 funcione para los Pods en el mismo nodo que el Pod coredns, pero no entre 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 host-network. 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 del clúster. Según el SO, este servidor de nombres se configura en /etc/resolv.conf o /run/systemd/resolve/resolv.conf. Esta configuración significa que no pueden resolver los nombres de dominio cluster.local.

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

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 correspondientes. 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. Verifica que se permita la conectividad de BGP entre los dos peers en tu entorno.

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

Dataplane v2 o Cilium

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

Este error significa que el agente de Cilium rechazó el evento de creación del Pod debido a un límite de frecuencia. Para cada nodo, Cilium tiene un límite de cuatro solicitudes simultáneas al extremo PUT. Cuando hay una ráfaga de solicitudes a un nodo, se espera este comportamiento. 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 velocidad puede converger en una cantidad más razonable, con límites de velocidad más altos para los 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 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 genera una discrepancia entre el plano de control y el plano de datos. Por ejemplo, el mapa de Service tiene un límite de 64,000 entradas.

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

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

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

  2. Si el mapa está cerca del límite de 64 k, límpialo. En el siguiente ejemplo, se limpian las asignaciones 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 llenar 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 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 podría estar 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 sucedan varios eventos antes de marcar el nodo 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 o Calico a través de 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 la red.

  1. Verifica el estado del Pod anetd o calico-node. Revisa los siguientes pasos para solucionar el problema y determinar su causa:

    • 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 revisa los eventos del Pod. Por ejemplo, es posible que al Pod le falte un recurso, como un volumen.
    • 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 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 ARP obsoletas en los nodos del plano de control del clúster de administrador pueden provocar una discrepancia en las direcciones MAC. Esta discrepancia de direcciones puede, a su vez, provocar tiempos de espera de conexión a las VIP del plano de control de los clústeres de usuario administrados. Los tiempos de espera de 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 actualizaciones del clúster.

En esta situación, el registro de kubelet en el nodo con entradas ARP obsoletas contiene un error de tiempo de espera del 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 devuelven una dirección MAC diferente, significa que tienes este problema.

  5. Para resolver el problema, vacía 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 se pasa tráfico al servicio de F5, revisa los siguientes pasos para solucionar problemas:

  1. Verifica que cada partición en F5 BIG-IP esté configurada en un clúster, ya sea de administrador o de usuario. Si varios clústeres diferentes comparten una misma partición, experimentarás 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 los 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 Service de tipo LoadBalancer. El controlador de bigip consume el ConfigMap con el tiempo.

  3. Asegúrate de que exista el ConfigMap 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 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 tratarse de 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 diagnosticar y solucionar los problemas.

¿Qué sigue?

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

También puedes consultar Cómo obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes: