Container Service for Kubernetes:Troubleshoot network issues with ACK KubeSkoop

Instalar ACK KubeSkoop

1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, haga clic en Components and Add-ons .

3. En la página Add-ons, busque ACK KubeSkoop, localice el componente y haga clic en Install.

4. En el panel Install de ACK KubeSkoop, haga clic en Confirm.

Configurar KubeSkoop

• Para configurar el componente KubeSkoop, edite su ConfigMap mediante la ejecución del siguiente comando:

  kubectl edit cm kubeskoop-config -n ack-kubeskoop

• También puede configurar el componente desde la consola de ACK:

  1. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

  2. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, seleccione Configurations > ConfigMaps.

  3. En la página ConfigMaps, establezca Namespace en ack-kubeskoop, busque kubeskoop-config y haga clic en Edit en la columna Actions, a la derecha de kubeskoop-config.

  4. En el panel Edit, configure los parámetros y haga clic en OK. A continuación se describen las opciones de configuración compatibles con KubeSkoop.

     Parámetro	Descripción	Valor predeterminado
     debugmode	Indica si se habilita el modo de depuración. Valores válidos: false: el modo de depuración está deshabilitado. true: el modo de depuración está habilitado. Cuando se activa, esta opción proporciona registros de nivel DEBUG, interfaces de depuración y las herramientas de diagnóstico Go pprof y gops.	false
     port	El puerto del servicio de métricas, que proporciona un endpoint HTTP.	9102
     enableController	Indica si se habilita el componente controlador. El controlador interactúa con la API de Kubernetes para ejecutar tareas de monitoreo y gestión.	true
     controllerAddr	La dirección del componente controlador de KubeSkoop.	dns:kubeskoop-controller:10263
     metrics.probes	Una lista de los tipos de métricas de monitoreo que se van a recopilar. Cada sonda corresponde a una categoría de métrica.	metrics: probes: - name: conntrack - name: qdisc - name: netdev - name: io - name: sock - name: tcpsummary - name: tcp - name: tcpext - name: udp - name: rdma Para obtener más información, consulte Probes, Metrics, and Events.

     El componente ACK KubeSkoop recarga automáticamente los cambios de configuración del ConfigMap sin interrupciones, por lo que no es necesario reiniciarlo.

Configurar el panel de ARMS Prometheus

1. Inicie sesión en la consola de ARMS.

2. En el panel de navegación izquierdo, haga clic en Integration Management.

3. En la página Integration Management, haga clic en Add Integration. En el cuadro de búsqueda, escriba KubeSkoop y haga clic en ACK KubeSkoop Network Monitoring.

4. En el cuadro de diálogo ACK KubeSkoop Network Monitoring, seleccione el clúster de ACK que desea integrar, introduzca un Integration Name y haga clic en OK para habilitar el monitoreo de KubeSkoop.

5. Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

6. En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, seleccione Operations > Prometheus Monitoring.

7. Haga clic en la pestaña Others. En la lista de paneles encontrará los dashboards de monitoreo de KubeSkoop para nodos y Pods, llamados Ack KubeSkoop Network Monitor - Node y Ack KubeSkoop Network Monitor - Pod.

Consultar manualmente las métricas de monitoreo de KubeSkoop

KubeSkoop proporciona datos de monitoreo en formato Prometheus. Después de instalar KubeSkoop, acceda al puerto de servicio de cualquier instancia de Pod de KubeSkoop para recuperar todas las métricas.

1. Ejecute el siguiente comando para obtener todas las instancias de KubeSkoop.

    kubectl get pod -n ack-kubeskoop -o wide | grep kubeskoop-agent

   Resultado esperado:

   kubeskoop-agent-2chvw                   1/1     Running   0             43m   172.16.16.xxx   cn-hangzhou.172.16.16.xxx   <none>           <none>
   kubeskoop-agent-2qtbf                   1/1     Running   0             43m   172.16.16.xxx   cn-hangzhou.172.16.16.xxx   <none>           <none>
   kubeskoop-agent-72pgf                   1/1     Running   0             43m   172.16.16.xxx   cn-hangzhou.172.16.16.xxx   <none>           <none>

2. Ejecute el siguiente comando para obtener las métricas. Reemplace 172.16.16.xxx con la dirección IP de una instancia de KubeSkoop obtenida en el paso anterior.

   curl http://172.16.16.xxx:9102/metrics

KubeSkoop proporciona las métricas de monitoreo con el siguiente formato:

kubeskoop_netdev_rxbytes{k8s_namespace="",k8s_node="cn-hangzhou.172.16.16.xxx",k8s_pod=""} 2.970963745e+09

Problemas de tiempo de espera de DNS

En un entorno nativo de la nube, los tiempos de espera del servicio DNS pueden provocar errores de acceso a los servicios. Las causas más comunes incluyen:

• El servidor DNS responde lentamente y no logra completar la consulta antes de que la aplicación agote su tiempo de espera.

• El emisor no envía el paquete de consulta DNS a tiempo debido a un problema en el cliente.

• El servidor responde a tiempo, pero el emisor descarta paquetes por problemas como falta de memoria.

Utilice las siguientes métricas para diagnosticar los problemas de tiempo de espera de DNS intermitentes:

Dado que muchos servicios en un entorno nativo de la nube dependen de CoreDNS para la resolución de nombres de dominio, también debe revisar las métricas anteriores en los Pods relacionados con CoreDNS si el problema de DNS involucra a este componente.

Errores HTTP 499/502/503/504 en Nginx Ingress

En los entornos nativos de la nube, las puertas de enlace Ingress y otros servicios de proxy suelen presentar excepciones intermitentes. Para Nginx Ingress y otros servicios de proxy basados en Nginx, los errores más comunes son 499, 502, 503 y 504. Estos códigos indican lo siguiente:

• 499 Client Closed Request: el cliente cierra la conexión TCP antes de que Nginx responda. Las causas habituales incluyen:

  • El cliente establece una conexión, pero envía la solicitud tarde. Esto provoca que se alcance el tiempo de espera del lado del cliente mientras Nginx responde. Es común en frameworks de solicitudes asíncronas en clientes Android.

  • El servidor procesa la conexión lentamente después de establecerla. Este caso requiere una investigación más profunda.

  • El servidor tarda en procesar las solicitudes enviadas al backend ascendente.

• 502 Bad Gateway: suele indicar problemas de conexión entre Nginx y el backend ascendente, como un fallo de conexión o un cierre anómalo por parte del backend. Las causas frecuentes son:

  • Fallo en la resolución DNS del backend configurado, algo habitual cuando se usa un Service de Kubernetes como backend.

  • Imposibilidad de establecer una conexión con el servidor ascendente.

  • La solicitud o respuesta ascendente es demasiado grande, lo que genera fallos de asignación de memoria que interrumpen las interacciones normales del negocio.

• 503 Service Unavailable: en Nginx, este código de estado indica que todos los servidores ascendentes no están disponibles. En escenarios nativos de la nube tiene significados específicos. Las causas comunes incluyen:

  • No hay backends disponibles, aunque es poco frecuente.

  • El tráfico es demasiado alto y el límite de velocidad de Ingress lo está restringiendo.

• 504 Gateway Timeout: este error indica un problema de tiempo de espera en los paquetes de negocio entre Nginx y el servidor ascendente. La causa habitual es una respuesta tardía del servidor ascendente.

Cuando enfrente estos problemas, primero recopile información general para determinar el alcance del incidente y definir los siguientes pasos de diagnóstico:

• Revise la información del registro de acceso de Nginx, especialmente request_time, upstream_connect_time y upstream_response_time.

• Consulte la información de error_log de Nginx para detectar mensajes de error anómalos durante el incidente.

• Si configuró una verificación de estado liveness o readiness, compruebe su estado.

Con base en esta información, supervise las variaciones de las siguientes métricas en el momento en que pudo ocurrir el fallo de conexión:

Si nota que las respuestas de Nginx son lentas, por ejemplo, cuando ocurren tiempos de espera pero el valor request_time de Nginx es bajo, supervise las variaciones de las siguientes métricas:

Las variaciones de estas métricas durante el incidente le ayudarán a reducir el alcance de la investigación .

Problemas de restablecimiento TCP

Un paquete de restablecimiento TCP es una respuesta ante situaciones inesperadas en el protocolo TCP. Normalmente provoca los siguientes errores en los programas de usuario:

• Error connection reset by peer, común en aplicaciones que dependen de bibliotecas C, como Nginx.

• Error Broken pipe, frecuente en aplicaciones que usan contenedores de conexiones TCP, como Java o Python.

En un entorno de red nativo de la nube existen muchas razones habituales para los paquetes de restablecimiento. A continuación se presentan algunas de las más comunes:

• Excepciones en el servidor impiden el funcionamiento normal del servicio, como una configuración de memoria insuficiente para TCP. Esta situación suele desencadenar un restablecimiento proactivo.

• Al usar un Service o balanceo de carga, el tráfico se reenvía a un backend inesperado debido a anomalías en mecanismos con estado, como la selección de endpoints o conntrack.

• Liberación de la conexión por motivos de seguridad.

• En entornos NAT o escenarios de alta concurrencia, se produce Protection Against Wrapped Sequence Numbers (PAWS) o un desbordamiento de números de secuencia.

• Se utiliza TCP Keepalive para mantener las conexiones, pero no hay comunicación de negocio normal durante mucho tiempo.

Para diferenciar rápidamente estas causas raíz, recopile información básica y métricas:

1. Analice la topología de red entre el cliente y el servidor en el momento en que se generó el paquete de restablecimiento.

2. Supervise las variaciones de las siguientes métricas:

   Nombre de la métrica	Descripción
   kubeskoop_tcpext_tcpabortontimeout	Se incrementa cuando se envía un restablecimiento porque se superó el número máximo de llamadas keepalive, de sondeo de ventana o de retransmisión.
   kubeskoop_tcpext_tcpabortonlinger	Número de restablecimientos enviados para recuperar rápidamente conexiones en estado FIN_WAIT2 cuando la opción TCP Linger2 está habilitada.
   kubeskoop_tcpext_tcpabortonclose	Se incrementa cuando se envía un paquete de restablecimiento porque aún quedan datos sin leer al cerrar una conexión TCP por motivos ajenos a la máquina de estados.
   kubeskoop_tcpext_tcpabortonmemory	Número de restablecimientos enviados para finalizar una conexión por falta de memoria, detectada por tcp_check_oom al asignar recursos como tw_sock o tcp_sock.
   kubeskoop_tcpext_tcpabortondata	Número de restablecimientos enviados para recuperar conexiones rápidamente cuando la opción Linger o Linger2 está habilitada.
   kubeskoop_tcpext_tcpackskippedsynrecv	Número de veces que un socket en estado SYN_RECV no responde con un ACK.
   kubeskoop_tcpext_tcpackskippedpaws	Número de veces que no se envía un paquete ACK debido a la limitación de velocidad Out-of-Window (OOW), aunque el mecanismo PAWS haya activado una corrección.
   kubeskoop_tcp_estabresets	Número de veces que una conexión TCP se cierra de forma anómala en un solo Pod. Esta métrica solo contabiliza el resultado.
   kubeskoop_tcp_outrsts	Número de paquetes de restablecimiento enviados por TCP en un solo Pod.

Variaciones intermitentes de latencia de red

Las variaciones intermitentes de latencia de red son un problema común y difícil de diagnosticar en entornos nativos de la nube. Tienen múltiples causas y pueden derivar en los tres tipos de problemas mencionados anteriormente. En un escenario de red de contenedores, la latencia dentro de un nodo suele deberse a lo siguiente:

• Un proceso en tiempo real gestionado por el planificador RT se ejecuta durante demasiado tiempo. Esto provoca que los procesos de negocio o los hilos del kernel de red permanezcan en cola mucho tiempo o se procesen lentamente.

• El propio proceso experimenta llamadas externas largas de forma ocasional, como respuestas lentas de discos en la nube o aumentos intermitentes en el tiempo de ida y vuelta (RTT) de RDS, lo que ralentiza el procesamiento de solicitudes.

• Problemas de configuración del nodo generan una carga desigual entre distintas CPU o nodos NUMA, lo que retrasa al sistema sobrecargado.

• Latencia provocada por mecanismos con estado en el kernel, como la operación confirm de conntrack, o por una gran cantidad de sockets huérfanos que afectan las búsquedas normales de sockets.

Aunque estos problemas se manifiestan como fallos de red, su causa raíz suele estar relacionada con otros factores del sistema operativo. Supervise las siguientes métricas para reducir el alcance de la investigación:

Caso 1: Tiempo de espera de DNS intermitente

Problema

Un cliente experimentaba tiempos de espera intermitentes en la resolución DNS. Su aplicación se ejecutaba en PHP y el servicio DNS estaba configurado con CoreDNS.

Proceso de diagnóstico

1. Con base en la descripción del cliente, obtuvimos los datos de monitoreo relacionados con DNS.

2. El análisis de los datos durante el periodo de error reveló lo siguiente:

   • La métrica kubeskoop_udp_noports aumentó en 1 durante el periodo de error. El valor general de la métrica era bajo.

   • La métrica kubeskoop_packetloss_total aumentó en 1. La variación en la pérdida de paquetes fue mínima.

3. El cliente informó que la dirección DNS configurada pertenecía a un proveedor de servicios público. Esta información, combinada con los datos de monitoreo, indicó que una respuesta DNS lenta era la causa raíz. El paquete de respuesta DNS llegó después de que la aplicación del usuario ya hubiera agotado su tiempo de espera.

Caso 2: Fallos de conexión intermitentes en Java

Problema

Un cliente reportó que su instancia de Tomcat dejaba de estar disponible de forma intermitente, y cada interrupción duraba entre 5 y 10 segundos.

Proceso de diagnóstico

1. El análisis de registros confirmó que el entorno de ejecución de Java del cliente ejecutaba una operación de recolección de basura (GC) cuando ocurría el problema.

2. Después de desplegar el monitoreo de KubeSkoop, encontramos un aumento significativo en la métrica kubeskoop_tcpext_listendrops en el momento del problema.

3. Determinamos que, cuando el entorno de ejecución de Java del cliente realizaba la GC, la velocidad de procesamiento de solicitudes disminuía y retrasaba la liberación de conexiones. Sin embargo, las nuevas solicitudes de conexión no tenían límites, lo que generó una gran cantidad de conexiones. Esto llenó el backlog del socket de escucha y provocó un desbordamiento, causando el aumento de kubeskoop_tcpext_listendrops.

4. La acumulación de conexiones del cliente fue breve y la capacidad de procesamiento no representaba un problema. Recomendamos ajustar los parámetros correspondientes de Tomcat, lo cual resolvió la situación.

Caso 3: Variaciones intermitentes de latencia de red

Problema

Un cliente descubrió que las solicitudes entre su aplicación y Redis presentaban aumentos intermitentes de RTT, lo que provocaba tiempos de espera en el negocio. Sin embargo, no lograba reproducir el problema.

Proceso de diagnóstico

1. El análisis de registros mostró que el cliente experimentaba solicitudes intermitentes a Redis con un tiempo de respuesta total superior a 300 ms.

2. Tras desplegar KubeSkoop, los datos de monitoreo mostraron un aumento en la métrica kubeskoop_virtcmdlatency_latency cuando ocurrió el problema. Los valores de le (etiqueta de bucket del histograma de Prometheus) que aumentaron fueron 18 y 15. Esto indicó que se produjeron dos llamadas de virtualización de alta latencia. La llamada con le=15 causó un retraso de más de 36 ms, y la de le=18 provocó un retraso de más de 200 ms.

3. Dado que las llamadas de virtualización del kernel ocupan la CPU y no admiten expropiación, la latencia intermitente se debió a llamadas de virtualización prolongadas durante la creación y eliminación masiva de Pods.

Caso 4: Fallos en la verificación de estado de Ingress Nginx

Problema

La máquina de Ingress presentaba fallos intermitentes en la verificación de estado, acompañados de errores en las solicitudes de negocio.

Proceso de diagnóstico

1. Después de desplegar el monitoreo, encontramos que varias métricas mostraban variaciones anómalas en el momento del incidente:

   1. Tanto kubeskoop_tcpsummary_tcprxqueue como kubeskoop_tcpsummary_tcptxqueue aumentaron.

   2. kubeskoop_tcpext_tcptimeouts aumentó.

   3. kubeskoop_tcpsummary_tcptimewaitconn disminuyó y kubeskoop_tcpsummary_tcpestablishedconn aumentó.

2. El análisis confirmó que el kernel funcionaba correctamente y que las conexiones se establecían sin problemas. Sin embargo, la ejecución del proceso era anómala, incluido el procesamiento de paquetes del socket de recepción y el envío de paquetes. Sospechamos que existía un problema de planificación o de límite de recursos en el proceso de usuario.

3. La revisión del monitoreo de Cgroup reveló que el cliente experimentaba limitación de CPU en el momento del incidente. Esto demostró que las restricciones de Cgroup impedían intermitentemente la planificación del proceso de usuario.

4. Siguiendo la guía Enable the CPU Burst performance optimization policy, configuramos la función CPU Burst para Ingress, lo cual resolvió este tipo de problemas.