Uso de Advanced Container Networking Services para diagnosticar y resolver problemas de red

Esta guía le ayuda a navegar por Servicios avanzados de redes de contenedores (ACNS) como solución principal para abordar casos de uso de redes reales en Azure Kubernetes Service (AKS). Ya sea para solucionar problemas de resolución de DNS, optimizar el tráfico de entrada y salida o garantizar el cumplimiento de las directivas de red, este manual muestra cómo aprovechar los paneles de observabilidad de ACNS, registros de red de contenedor, métricas de red de contenedor y herramientas de visualización para diagnosticar y resolver problemas de forma eficaz.

Servicios avanzados de redes de contenedores es la plataforma de seguridad y observabilidad de red integral de nivel empresarial de Microsoft que proporciona las características más avanzadas para supervisar, analizar y solucionar problemas del tráfico de red en los clústeres de AKS. Incluye paneles de Grafana pregenerados, métricas en tiempo real, registros detallados e información con tecnología de inteligencia artificial que le ayudan a obtener una visibilidad profunda del rendimiento de la red, identificar rápidamente los problemas y optimizar el entorno de red de contenedores con soporte técnico completo de Microsoft.

Descripción general de los paneles de Servicios de Redes Avanzadas para Contenedores

Hemos creado paneles de ejemplo para Advanced Container Networking Services para ayudarle a visualizar y analizar el tráfico de red, las solicitudes DNS y las caídas de paquetes en los clústeres de Kubernetes. Estos paneles están diseñados para proporcionar información sobre el rendimiento de la red, identificar posibles problemas y ayudar a solucionar problemas. Para obtener información sobre cómo configurar estos paneles, consulte Configuración de la observabilidad de la red de contenedores para Azure Kubernetes Service (AKS): Prometheus y Grafana administrados por Azure.

El conjunto de paneles incluye:

• Registros de flujo: muestra los flujos de tráfico de red entre pods, espacios de nombres y puntos de conexión externos.
• Registros de flujo (tráfico externo): muestra los flujos de tráfico de red entre pods y puntos de conexión externos.
• Clústeres: muestra las métricas de nivel de nodo para los clústeres.
• DNS (clúster): muestra las métricas de DNS en un clúster o selección de nodos.
• DNS (carga de trabajo):muestra las métricas de DNS para la carga de trabajo especificada (por ejemplo, pods de un DaemonSet o una implementación como CoreDNS).
• Caídas (Carga de trabajo): muestra las caídas hacia o desde la carga de trabajo especificada (por ejemplo, pods de una implementación o DaemonSet).
• Flujos de pod (espacio de nombres): muestra los flujos de paquetes L4/L7 hacia o desde el espacio de nombres especificado (es decir, pods en el espacio de nombres).
• Flujos de pod (carga de trabajo): muestra los flujos de paquetes L4/L7 hacia o desde la carga de trabajo especificada (por ejemplo, pods de una implementación o DaemonSet).
• Flujos L7 (espacio de nombres): muestra flujos de paquetes HTTP, Kafka y gRPC hacia o desde el espacio de nombres especificado (es decir, pods en el espacio de nombres) cuando se aplica una directiva basada en la capa 7. Solo está disponible para clústeres con plano de datos de Cilium.
• Flujos L7 (carga de trabajo): muestra flujos HTTP, Kafka y gRPC hacia o desde la carga de trabajo especificada (por ejemplo, pods de una implementación o daemonSet) cuando se aplica una directiva basada en la capa 7. Solo está disponible para clústeres con plano de datos de Cilium.

Caso de uso 1: Interpretación de problemas del servidor de nombres de dominio (DNS) para el análisis de causa principal (RCA)

Los problemas de DNS en el nivel de pod pueden provocar errores en la detección de servicios, respuestas lentas de la aplicación o errores de comunicación entre pods. Estos problemas suelen surgir de directivas DNS mal configuradas, capacidad de consulta limitada o latencia en la resolución de dominios externos. Por ejemplo, si el servicio CoreDNS está sobrecargado o un servidor DNS ascendente deja de responder, podría provocar errores en pods dependientes. La resolución de estos problemas no solo requiere identificación, sino visibilidad profunda del comportamiento de DNS dentro del clúster.

Supongamos que ha configurado una aplicación web en un clúster de AKS y ahora que la aplicación web no es accesible. Recibe errores de DNS, como DNS_PROBE_FINISHED_NXDOMAIN o SERVFAIL, mientras que el servidor DNS resuelve la dirección de la aplicación web.

Paso 1: Investigar las métricas de DNS en los paneles de Grafana

Ya hemos creado dos paneles DNS para investigar métricas, solicitudes y respuestas de DNS: DNS (clúster), que muestra las métricas DNS en un clúster o selección de nodos, y DNS (carga de trabajo), que muestra las métricas DNS para una carga de trabajo específica (por ejemplo, pods de un DaemonSet o implementación como CoreDNS).

1. Compruebe el panel del clúster de DNS para obtener una instantánea de todas las actividades de DNS. Este panel proporciona información general de alto nivel sobre las solicitudes y respuestas DNS, como los tipos de consultas que carecen de respuestas, la consulta más común y la respuesta más común. También resalta los principales errores de DNS y los nodos que generan la mayoría de esos errores.

   

2. Desplácese hacia abajo para averiguar los pods con la mayoría de las solicitudes y errores de DNS en todos los espacios de nombres.

   

   Una vez que identifique los pods que causan la mayoría de los problemas de DNS, puede profundizar más en el panel Carga de trabajo de DNS para obtener una vista más detallada. Al correlacionar datos entre varios paneles dentro del panel, puede restringir sistemáticamente las causas principales de los problemas.

3. Las secciones Solicitudes de DNS y Respuestas de DNS le permiten identificar tendencias, como una caída repentina en las tasas de respuesta o un aumento de las respuestas que faltan. Un alto número de solicitudes sin respuesta % indica posibles problemas con el servidor DNS aguas arriba o sobrecarga de consultas. En la captura de pantalla siguiente del panel de ejemplo, puede ver que hay un aumento repentino de las solicitudes y respuestas en torno a la 15.22.

   

4. Compruebe si hay errores de DNS por tipo y compruebe si hay picos en tipos de error específicos (por ejemplo, NXDOMAIN para dominios inexistentes). En este ejemplo, hay un aumento significativo en los errores rechazados de consulta, lo que sugiere una falta de coincidencia en las configuraciones dns o las consultas no admitidas.

   

5. Use secciones como IP de respuesta DNS devueltas para asegurarse de que se procesan las respuestas esperadas. Este gráfico muestra la tasa de consultas DNS correctas procesadas por segundo. Esta información es útil para comprender con qué frecuencia se resuelven correctamente las consultas DNS para la carga de trabajo especificada.

   • Una tasa mayor podría indicar un aumento del tráfico o un posible ataque DNS (por ejemplo, Denegación de servicio distribuido (DDoS)).
   • Una tasa reducida podría indicar problemas que llegan al servidor DNS externo, un problema de configuración de CoreDNS o una carga de trabajo inaccesible de CoreDNS.

   

6. Examinar las consultas DNS más frecuentes puede ayudar a identificar patrones en el tráfico de red. Esta información es útil para comprender la distribución de cargas de trabajo y detectar comportamientos de consulta inusuales o inesperados que puedan requerir atención.

   

7. La tabla de respuesta DE DNS le ayuda con el análisis de la causa principal del problema dns resaltando tipos de consulta, respuestas y códigos de error como SERVFAIL (error del servidor). Identifica consultas problemáticas, patrones de errores o configuraciones incorrectas. Al observar tendencias en códigos de retorno y tasas de respuesta, puede identificar nodos, cargas de trabajo o consultas específicos que provocan interrupciones o anomalías de DNS.

   En el ejemplo siguiente, puede ver que para los registros AAAA (IPV6), no hay ningún error, pero hay un error en el servidor con un registro A (IPV4). A veces, es posible que el servidor DNS esté configurado para priorizar IPv6 a través de IPv4. Esto puede provocar situaciones en las que las direcciones IPv6 se devuelven correctamente, pero las direcciones IPv4 enfrentan problemas.

   

8. Cuando se confirma que hay un problema de DNS, el gráfico siguiente identifica los diez puntos de conexión principales que provocan errores de DNS en una carga de trabajo o espacio de nombres específico. Puede usarlo para priorizar la solución de problemas de puntos de conexión específicos, detectar configuraciones incorrectas o investigar problemas de red.

   

Paso 2: Analizar problemas de resolución de DNS con registros de la red de contenedores

1. Los registros de red de contenedor proporcionan información detallada sobre las consultas DNS y sus respuestas en los modos almacenados y a petición. Con los registros de red de contenedor, puede analizar el tráfico relacionado con DNS para pods específicos, mostrando detalles como consultas DNS, respuestas, códigos de error y latencia. Para ver los flujos DNS en el área de trabajo de Log Analytics, use la siguiente consulta KQL:

   RetinaNetworkFlowLogs
   | where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
   | where Layer4.UDP.destination_port == 53
   | where Layer7.type == "REQUEST" 
   | where Reply == false or isnull(Reply)
   | project TimeGenerated, SourcePodName, DestinationPodName, Layer7.dns.query, Layer7.dns.qtypes, Verdict, TrafficDirection, AdditionalFlowData.Summary, NodeName, SourceNamespace, DestinationNamespace
   | order by TimeGenerated desc
   

   Reemplace <start-time> y <end-time> por el intervalo de tiempo deseado en el formato 2025-08-12T00:00:00Z.

   Los registros de red de contenedor proporcionan información completa sobre las consultas DNS y sus respuestas, lo que puede ayudar a diagnosticar y solucionar problemas relacionados con DNS. Cada entrada de registro incluye información como el tipo de consulta (por ejemplo, A o AAAA), el nombre de dominio consultado, el código de respuesta de DNS (por ejemplo, Consulta rechazada, Dominio inexistente o Error de servidor) y el origen y el destino de la solicitud de DNS.

2. Identificar el estado de la consulta: examine el campo Veredicto para las respuestas como DROPPED o FORWARDED, que indica problemas con la conectividad de red o la aplicación de directivas.

3. Compruebe el origen y el destino: asegúrese de que los nombres de pod enumerados en los campos SourcePodName y DestinationPodName son correctos y la ruta de comunicación es la esperada.

4. Seguimiento de patrones de tráfico: Mire el campo Veredicto para comprender si las solicitudes se reenviaron o descartaron. Las interrupciones en el reenvío pueden indicar problemas de red o configuración.

5. Analizar marcas de tiempo: use el campo TimeGenerated para correlacionar problemas de DNS específicos con otros eventos del sistema para obtener un diagnóstico completo.

6. Filtrar por pods y espacios de nombres: use campos como SourcePodName, DestinationPodName y SourceNamespace para centrarse en cargas de trabajo específicas que experimentan problemas.

Paso 3: Visualización del tráfico DNS con paneles de registros de red de contenedores

Los registros de red de contenedor proporcionan funcionalidades de visualización enriquecidas a través de paneles de Azure Portal y Azure Managed Grafana. El gráfico de dependencias de servicio y la visualización de registros de flujo complementan el análisis detallado del registro al proporcionar información visual sobre el tráfico y las dependencias relacionados con DNS:

• Gráficos de dependencias de servicio: visualización de los pods o servicios que envían grandes volúmenes de consultas DNS y sus relaciones
• Paneles de registros de flujo: supervisar patrones de solicitud DNS, tasas de errores y tiempos de respuesta en tiempo real
• Análisis de flujo de tráfico: identificación de paquetes DNS eliminados y rutas de acceso de comunicación a CoreDNS o servicios DNS externos

Puede acceder a estas visualizaciones a través de:

• Azure Portal: vaya al clúster de AKS → Insights → Redes → Registros de flujo
• Azure Managed Grafana: use los paneles "Registros de flujo" y "Registros de flujo (tráfico externo)" preconfigurados.

Con las funcionalidades combinadas de los paneles de Grafana, el modo almacenado de registros de red de contenedor para el análisis histórico y los registros a petición para la solución de problemas en tiempo real, puede identificar problemas de DNS y realizar análisis de la causa principal de forma eficaz.

Caso de uso 2: Identificación de caídas de paquetes en el nivel de clúster y pod debido a problemas de conectividad de red o directivas de red mal configuradas

Los problemas de cumplimiento de directivas de red y conectividad a menudo se derivan de directivas de red de Kubernetes mal configuradas, complementos de interfaz de red de contenedor (CNI) incompatibles, intervalos IP superpuestos o degradación de la conectividad de red. Estos problemas pueden interrumpir la funcionalidad de la aplicación, lo que da lugar a interrupciones del servicio y a experiencias de usuario degradadas.

Cuando se produce una eliminación de paquetes, los programas eBPF capturan el evento y generan metadatos sobre el paquete, incluido el motivo de la eliminación y su ubicación. Este dato se procesa mediante un programa de espacio de usuario, que analiza la información y la convierte en métricas de Prometheus. Estas métricas ofrecen información crítica sobre las causas principales de caídas de paquetes, lo que permite a los administradores identificar y resolver problemas como la configuración incorrecta de directivas de red de forma eficaz.

Además de los problemas de cumplimiento de directivas, los problemas de conectividad de red pueden provocar caídas de paquetes debido a factores como errores TCP o retransmisiones. Los administradores pueden depurar estos problemas mediante el análisis de tablas de retransmisión TCP y registros de errores, lo que ayuda a identificar vínculos de red degradados o cuellos de botella. Mediante el uso de estas métricas detalladas y las herramientas de depuración, los equipos pueden garantizar operaciones de red fluidas, reducir el tiempo de inactividad y mantener un rendimiento óptimo de las aplicaciones.

Supongamos que tiene una aplicación basada en microservicios en la que el pod de front-end no puede comunicarse con un pod back-end debido a una directiva de red excesivamente restrictiva que bloquea el tráfico de entrada.

Paso 1: Investigar las métricas de `caída` en los paneles de Grafana

1. Si hay caídas de paquetes, inicie su investigación con el panel Flujos de pod (espacio de nombres). Este panel tiene secciones que ayudan a identificar los espacios de nombres con las caídas más altas y, a continuación, los pods dentro de esos espacios de nombres que tienen las caídas más altas. Por ejemplo, vamos a revisar el mapa térmico de caídas salientes para los pods de origen principales o los pods de destino principales para identificar qué pods se ven más afectados. Los colores más brillantes indican tasas más altas de caídas. Compare a través del tiempo para detectar patrones o picos en instancias específicas.

   

2. Una vez que se identifiquen los pods principales con las mayores caídas, vaya al panel de control Caídas (Carga de trabajo). Puede usar este panel para diagnosticar problemas de conectividad de red mediante la identificación de patrones en las disminuciones de tráfico saliente de ciertos pods específicos. Las visualizaciones resaltan qué pods están experimentando más caídas, la tasa de esas caídas y las razones detrás de ellas, como las denegaciones de políticas. Al correlacionar picos en tasas de caída con pods o períodos de tiempo específicos, puede identificar errores de configuración, servicios sobrecargados o problemas de cumplimiento de directivas que podrían interrumpir la conectividad.

   

3. Revisa la sección Instantánea de carga de trabajo para identificar pods con caídas de paquetes salientes. Céntrese en las métricas Caídas Salientes Máximas y Caídas Salientes Mínimas para comprender la gravedad del problema (en este ejemplo se muestran 1,93 paquetes por segundo). Priorice la investigación de pods con tasas de caída de paquetes constantemente altas.

   

4. Utiliza el gráfico Tráfico entrante/saliente caído por motivo para identificar la causa principal de las caídas. En este ejemplo, se deniega la directiva, lo que indica que las directivas de red mal configuradas bloquean el tráfico saliente. Compruebe si algún intervalo de tiempo específico muestra un aumento en las caídas para determinar cuándo comenzó el problema.

   

5. Use el mapa térmico de caídas entrantes para los pods de origen o destino principales para identificar qué pods se ven más afectados. Los colores más brillantes indican tasas más altas de caídas. Compare a través del tiempo para detectar patrones o picos en instancias específicas.

   

6. Utilice el gráfico Caídas salientes/entrantes apiladas (totales) según el Pod de origen para comparar las tasas de caída entre los pods afectados. Identifique si los pods específicos muestran constantemente caídas más altas (por ejemplo, kapinger-bad-6659b89fd8-zjb9k en 26,8 p/s). Aquí, p/s hace referencia a paquete caído por segundo. Haga referencia cruzada a estos pods con sus cargas de trabajo, etiquetas y directivas de red para diagnosticar posibles errores de configuración.

   

Paso 2: Analizar las caídas de paquetes con registros de red de contenedores

Los registros de red de contenedor proporcionan información completa sobre las caídas de paquetes causadas por directivas de red mal configuradas con datos detallados, en tiempo real e históricos. Puede analizar los paquetes descartados mediante el examen de motivos específicos de eliminación, patrones y cargas de trabajo afectadas.

Use la siguiente consulta de KQL en el área de trabajo de Log Analytics para identificar las caídas de paquetes:

RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED" 
| summarize DropCount = count() by SourcePodName, DestinationPodName, SourceNamespace, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

Para el análisis en tiempo real de paquetes descartados, también puede filtrar por pods o namespaces específicos.

RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED" 
| where SourceNamespace == "<namespace-name>"
| project TimeGenerated, SourcePodName, DestinationPodName, SourceNamespace, DestinationNamespace, Verdict, TrafficDirection
| order by TimeGenerated desc

Reemplace <start-time> y <end-time> por el intervalo de tiempo deseado en el formato 2025-08-12T00:00:00Z.

Los registros de red de contenedor proporcionan información detallada sobre los paquetes descartados, lo que le ayuda a identificar directivas de red mal configuradas y validar correcciones. Los registros incluyen información detallada sobre los motivos de eliminación, los pods afectados y los patrones de tráfico que pueden guiar los esfuerzos de solución de problemas.

Paso 3: Visualización de las caídas de paquetes con paneles de registros de red de contenedor

Los registros de la red de contenedores proporcionan una representación visual de los flujos de tráfico y de los paquetes descartados a través de los paneles del Azure Portal y de Azure Managed Grafana. Los paneles registros de flujo muestran interacciones entre pods dentro del mismo espacio de nombres, pods de otros espacios de nombres y tráfico desde fuera del clúster.

Entre las características clave de visualización se incluyen:

• Análisis de eliminación por causas: identifique por qué se eliminan los paquetes (política denegada, seguimiento de conexiones, etc.)
• Mapas de flujo de tráfico: representación visual de los flujos de tráfico permitidos y denegados
• Información detallada sobre el espacio de nombres y el nivel de pod: vistas detalladas de las relaciones de origen y destino
• Análisis de series temporales: tendencias históricas de caídas de paquetes y sus causas

Estos datos son fundamentales para revisar las directivas de red aplicadas en el clúster, lo que permite a los administradores identificar y solucionar rápidamente las directivas mal configuradas o problemáticas a través de un análisis completo de registros y representaciones visuales.

Caso de uso 3: Detección de desbalances de tráfico en cargas de trabajo y espacios de nombres

Los desequilibrios de tráfico se producen cuando determinados pods o servicios dentro de una carga de trabajo o un espacio de nombres controlan un volumen desproporcionadamente alto de tráfico de red en comparación con otros. Esto puede provocar la competencia por los recursos, un rendimiento degradado en los pods sobrecargados y la infrautilización de otros. Estos desequilibrios suelen surgir debido a servicios mal configurados, distribución desigual del tráfico por parte de equilibradores de carga o patrones de uso imprevistos. Sin observabilidad, es difícil identificar qué pods o espacios de nombres están sobrecargados o infrautilizados. Advanced Container Networking Services puede ayudar mediante la supervisión de patrones de tráfico en tiempo real en el nivel de pod, lo que proporciona métricas sobre el uso del ancho de banda, las tasas de solicitud y la latencia, lo que facilita la identificación de desequilibrios.

Supongamos que tiene una plataforma comercial en línea que se ejecuta en un clúster de AKS. La plataforma consta de varios microservicios, incluido un servicio de búsqueda de productos, un servicio de autenticación de usuario y un servicio de procesamiento de pedidos que se comunica a través de Kafka. Durante una venta estacional, el servicio de búsqueda de productos experimenta un aumento del tráfico, mientras que los demás servicios permanecen inactivos. El equilibrador de carga dirige accidentalmente más solicitudes a un subconjunto de pods dentro de la implementación de búsqueda de productos, lo que conduce a la congestión y a una mayor latencia para las consultas de búsqueda. Mientras tanto, se infrautilizan otros pods de la misma implementación.

Paso 1. Investigación del tráfico de pods mediante el panel de Grafana

1. Vea el panel Flujos del pod (Carga de trabajo). La instantánea de carga de trabajo muestra varias estadísticas, como el tráfico saliente y entrante, y las caídas salientes y entrantes.

   

2. Examine las fluctuaciones del tráfico para cada tipo de seguimiento. Las variaciones significativas en las líneas azules y verdes indican cambios en el volumen de tráfico para aplicaciones y servicios, lo que podría contribuir a la congestión. Al identificar períodos con tráfico elevado, puede identificar los tiempos de congestión e investigar más. Además, compare los patrones de tráfico salientes y entrantes. Si hay un desequilibrio significativo entre el tráfico saliente y entrante, podría indicar congestión de red o cuellos de botella.

3. Los mapas térmicos representan métricas de flujo de tráfico en el nivel de pod dentro de un clúster de Kubernetes. El mapa térmico del tráfico saliente para los pods de origen principales muestra el tráfico saliente de los 10 pods de origen principales, mientras que el mapa térmico del tráfico entrante para los pods de destino principales muestra el tráfico entrante a los 10 pods de destino principales. La intensidad del color indica el volumen de tráfico, con sombras más oscuras que representan un mayor tráfico. Los patrones coherentes resaltan los pods que generan o reciben tráfico significativo, como default/tcp-client-0, que puede actuar como un nodo central.

   El siguiente mapa térmico indica que el tráfico más alto está recibiendo y saliendo del único pod. Si el mismo pod (por ejemplo, default/tcp-client-0) aparece en ambos mapas térmicos con alta intensidad de tráfico, podría sugerir que envía y recibe un gran volumen de tráfico, lo que podría actuar como un nodo central en la carga de trabajo. Las variaciones de intensidad entre los pods pueden indicar una distribución desigual del tráfico, con algunos pods manejando de forma desproporcionada más tráfico que otros.

   

4. La supervisión del tráfico de restablecimiento de TCP es fundamental para comprender el comportamiento de la red, solucionar problemas, aplicar la seguridad y optimizar el rendimiento de las aplicaciones. Proporciona información valiosa sobre cómo se administran y finalizan las conexiones, lo que permite a los administradores de red y del sistema mantener un entorno correcto, eficaz y seguro. Estas métricas revelan cuántas pods participan activamente en el envío o recepción de paquetes TCP RST, lo que puede indicar conexiones inestables o pods mal configurados que causan congestión de red. Las altas tasas de restablecimiento indican que los pods podrían estar abrumados por los intentos de conexión o bien experimentando una contención de recursos.

   

5. El mapa térmico del TCP RST saliente por los pods de origen principales muestra qué pods de origen generan los paquetes del TCP RST y cuándo aumenta la actividad. En el siguiente mapa térmico de ejemplo, si pets/rabbitmq-0 muestra constantemente restablecimientos de salida elevados durante las horas de tráfico máximo, podría indicar que la aplicación o sus recursos subyacentes (CPU, memoria) están sobrecargados. La solución podría ser optimizar la configuración del pod, escalar los recursos o distribuir el tráfico uniformemente entre réplicas.

   

6. El mapa de calor del TCP RST entrante según los pods de destino principales identifica los pods de destino que reciben la mayoría de los paquetes del TCP RST, apuntando a posibles cuellos de botella o problemas de conexión en estos pods. Si pets/mongodb-0 suele recibir paquetes RST, puede ser un indicador de conexiones de base de datos sobrecargadas o configuraciones de red defectuosas. La solución podría ser aumentar la capacidad de la base de datos, implementar la limitación de velocidad o investigar las cargas de trabajo ascendentes que causan conexiones excesivas.

   

7. El gráfico del TCP RST saliente apilado (total) por pod de origen proporciona una vista agregada de los restablecimientos salientes a lo largo del tiempo, resaltando tendencias o anomalías.

   

8. El gráfico TCP RST entrante apilado (total) por pod de destino agrega los restablecimientos entrantes, mostrando cómo la congestión de la red afecta a los pods de destino. Por ejemplo, un aumento sostenido en los restablecimientos para pets/rabbitmq-0 podría indicar que este servicio no puede controlar el tráfico entrante de forma eficaz, lo que conduce a tiempos de espera.

   

Análisis de desequilibrios de tráfico con registros de red de contenedores

Además de usar paneles de Grafana, puede usar registros de red de contenedor para analizar patrones de tráfico e identificar desequilibrios a través de consultas KQL:

// Identify pods with high traffic volume (potential imbalances)
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend TCP = parse_json(Layer4).TCP
| extend SourcePort = TCP.source_port, DestinationPort = TCP.destination_port
| summarize TotalConnections = count() by SourcePodName, SourceNamespace
| top 10 by TotalConnections desc

// Analyze TCP reset patterns to identify connection issues
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend TCP = parse_json(Layer4).TCP
| extend Flags = TCP.flags
| where Flags contains "RST"
| summarize ResetCount = count() by SourcePodName, DestinationPodName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, ResetCount desc

Reemplace <start-time> y <end-time> por el intervalo de tiempo deseado en el formato 2025-08-12T00:00:00Z.

Estas consultas ayudan a identificar los desequilibrios de tráfico y los problemas de conexión que podrían no estar visibles inmediatamente en las visualizaciones del panel.

Caso de uso 4: Supervisión en tiempo real del estado y el rendimiento de la red del clúster

Presentar las métricas de estado de red de un clúster a un nivel alto es esencial para garantizar la estabilidad general y el rendimiento del sistema. Las métricas de alto nivel proporcionan una vista rápida y completa del rendimiento de red del clúster, lo que permite a los administradores identificar fácilmente posibles cuellos de botella, errores o ineficiencias sin profundizar en detalles detallados. Estas métricas, como la latencia, el rendimiento, la pérdida de paquetes y las tasas de error, ofrecen una instantánea del estado del clúster, lo que permite la supervisión proactiva y la solución de problemas rápidas.

Tenemos un panel de ejemplo que representa el estado general del clúster: Kubernetes/ Networking/Clusters. Vamos a profundizar más en el panel de control general.

1. Identificar cuellos de botella de red: al analizar los gráficos de Bytes reenviados y Paquetes reenviados, para identificar si hay caídas o picos repentinos que indiquen posibles cuellos de botella o congestión en la red.

   

2. Detectar pérdida de paquetes: las secciones Paquetes descartados y bytes descartados ayudan a identificar si se produce una pérdida significativa de paquetes en clústeres específicos, lo que podría indicar problemas como hardware defectuoso o configuración de red mal configurada.

   

3. Supervisar patrones de tráfico: puede supervisar los patrones de tráfico a lo largo del tiempo para comprender el comportamiento normal frente a anómalo, lo que ayuda a solucionar problemas proactivos. Al comparar bytes y paquetes de entrada y salida máximos y mínimos, puede analizar las tendencias de rendimiento y determinar si ciertas horas del día o cargas de trabajo específicas están causando una degradación del rendimiento.

   

4. Diagnosticar motivos de eliminación: las secciones Bytes descartados por motivo y paquetes descartados por motivo ayudan a comprender las razones específicas de las caídas de paquetes, como denegaciones de directiva o protocolos desconocidos.

   

5. Análisis específico del nodo: los bytes descartados por el nodo y los paquetes descartados por los gráficos de nodos proporcionan información sobre qué nodos experimentan la mayor cantidad de caídas de paquetes. Esto ayuda a identificar nodos problemáticos y a tomar medidas correctivas para mejorar el rendimiento de la red.

   

6. Distribución de conexiones TCP: el gráfico aquí indica la distribución de conexiones TCP entre distintos estados. Por ejemplo, si el gráfico muestra un número inusualmente alto de conexiones en el SYN_SENT estado, podría indicar que los nodos del clúster tienen problemas para establecer conexiones debido a la latencia de red o a una configuración incorrecta. Por otro lado, un número considerable de conexiones en el TIME_WAIT estado podría sugerir que las conexiones no se liberan correctamente, lo que podría provocar el agotamiento de recursos.

   

Caso de uso 5: Diagnóstico de problemas de red de nivel de aplicación

La observabilidad del tráfico L7 aborda los problemas críticos de red de la capa de aplicación al proporcionar una visibilidad profunda del tráfico HTTP, gRPC y Kafka. Estas conclusiones ayudan a detectar problemas como altas tasas de error (por ejemplo, errores del lado cliente 4xx o 5xx del lado servidor), caídas inesperadas del tráfico, picos de latencia, distribución desigual del tráfico entre pods y directivas de red mal configuradas. Estos problemas suelen surgir en arquitecturas complejas de microservicios en las que las dependencias entre servicios son complejas y la asignación de recursos es dinámica. Por ejemplo, los aumentos repentinos en los mensajes Kafka descartados o las llamadas gRPC retrasadas podrían indicar cuellos de botella en el procesamiento de mensajes o la congestión de la red.

Supongamos que tiene una plataforma de comercio electrónico implementada en un clúster de Kubernetes, donde el servicio front-end se basa en varios microservicios de back-end, incluida una puerta de enlace de pago (gRPC), un catálogo de productos (HTTP) y un servicio de procesamiento de pedidos que se comunica a través de Kafka. Recientemente, los usuarios han notificado un aumento de los errores de finalización de la compra y los tiempos de carga de página lentos. Vamos a profundizar en cómo realizar RCA de este problema mediante nuestros paneles preconfigurados para el tráfico L7: Kubernetes/Networking/L7 (espacios de nombres) y Kubernetes/Networking/L7 (carga de trabajo).

1. Identifique patrones de solicitudes HTTP descartadas y reenviadas. En el siguiente gráfico, el tráfico HTTP saliente se segmenta según el veredicto, indicando si las solicitudes son "reenvíadas" o "descartadas." Para la plataforma de comercio electrónico, este gráfico puede ayudar a identificar posibles cuellos de botella o fallos en el proceso de pago. Si hay un aumento notable en los flujos HTTP descartados, puede indicar problemas como directivas de red mal configuradas, restricciones de recursos o problemas de conectividad entre los servicios front-end y back-end. Al correlacionar este gráfico con períodos de tiempo específicos de quejas de usuario, los administradores pueden identificar si estas caídas se alinean con el error de finalización de la compra.

   

2. En el gráfico de líneas siguiente se muestra la tasa de solicitudes HTTP salientes a lo largo del tiempo, clasificadas por sus códigos de estado (por ejemplo, 200, 403). Puede usar este gráfico para identificar picos en las tasas de error (por ejemplo, 403 Forbidden ), lo que podría indicar problemas con la autenticación o el control de acceso. Al correlacionar estos picos con intervalos de tiempo específicos, puede investigar y resolver los problemas subyacentes, como directivas de seguridad mal configuradas o problemas del lado servidor.

   

3. El siguiente mapa térmico indica qué pods tienen solicitudes HTTP salientes que provocaron errores de tipo 4xx. Puede usar este mapa térmico para identificar rápidamente los pods problemáticos e investigar los motivos de los errores. Al abordar estos problemas a nivel de pod, se puede mejorar la confiabilidad y el rendimiento general del tráfico L7.

   

4. Utilice los gráficos siguientes para comprobar qué pods reciben más tráfico. Esto ayuda a identificar pods sobrecargados.

   • Las solicitudes HTTP salientes para los 10 pods de origen principales de forma predeterminada muestran un número estable de solicitudes HTTP salientes a lo largo del tiempo para los diez pods de origen principales. La línea permanece casi plana, lo que indica un tráfico coherente sin picos o caídas significativos.
   • El mapa térmico de solicitudes HTTP salientes descartadas para los 10 pods de origen principales de forma predeterminada usa codificación de colores para representar el número de solicitudes descartadas. Los colores más oscuros indican un mayor número de solicitudes eliminadas, mientras que los colores más claros indican menos o ninguna solicitud eliminada. Las bandas oscuras y claras alternantes sugieren patrones periódicos en disminuciones de solicitudes.

   Estos gráficos proporcionan información valiosa sobre el tráfico de red y el rendimiento. El primer gráfico le ayuda a comprender la coherencia y el volumen de su tráfico HTTP saliente, que es fundamental para supervisar y mantener un rendimiento de red óptimo. El segundo gráfico permite identificar patrones o períodos cuando hay problemas con solicitudes eliminadas, lo que puede ser fundamental para solucionar problemas de red o optimizar el rendimiento.

   

Factores clave en los que centrarse durante el análisis de la causa principal del tráfico L7

1. Patrones de tráfico y volumen: analice las tendencias de tráfico para identificar picos, caídas o desequilibrios en la distribución del tráfico. Los nodos o servicios sobrecargados pueden provocar cuellos de botella o solicitudes perdidas.

   

2. Tasas de error: realice un seguimiento de las tendencias en errores 4xx (solicitudes no válidas) y 5xx (errores de back-end). Los errores persistentes indican errores de configuración de cliente o restricciones de recursos del lado servidor.

3. Solicitudes caídas: Investigue las caídas en pods o nodos específicos. Las caídas suelen indicar problemas de conectividad o denegaciones relacionadas con directivas.

4. Aplicación y configuración de directivas: evalúe las directivas de red, los mecanismos de detección de servicios y las configuraciones de equilibrio de carga para desajustes.

5. Mapas de calor y métricas de flujo: use visualizaciones como mapas de calor para identificar rápidamente pods con muchos errores o anomalías de tráfico.

Análisis del tráfico L7 con registros de red de contenedor

Los registros de red de contenedor proporcionan funcionalidades completas de análisis de tráfico L7 a través de registros almacenados y paneles visuales. Use las siguientes consultas de KQL para analizar HTTP, gRPC y otro tráfico de capa de aplicación:

// Analyze HTTP response codes and error rates
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_HTTP"
| extend HTTP = parse_json(Layer4).HTTP
| extend StatusCode = HTTP.status_code
| summarize RequestCount = count() by StatusCode, SourcePodName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

// Identify pods with high HTTP 4xx or 5xx error rates
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_HTTP"
| extend HTTP = parse_json(Layer4).HTTP
| extend StatusCode = tostring(HTTP.status_code)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorCount = count(), UniqueErrors = dcount(StatusCode) by SourcePodName, DestinationPodName
| top 10 by ErrorCount desc

// Monitor gRPC traffic and response times
RetinaNetworkFlowLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7_GRPC"
| extend GRPC = parse_json(Layer4).GRPC
| extend Method = GRPC.method
| summarize RequestCount = count() by SourcePodName, DestinationPodName, Method
| order by RequestCount desc

Reemplace <start-time> y <end-time> por el intervalo de tiempo deseado en el formato 2025-08-12T00:00:00Z.

Estas consultas complementan los paneles visuales al proporcionar información detallada sobre el rendimiento de la capa de aplicación, los patrones de error y la distribución del tráfico en la arquitectura de microservicios.

Observabilidad de red incluida con Azure Monitoring

Al habilitar el servicio administrado de Azure Monitor para Prometheus en un clúster de AKS, las métricas básicas de supervisión de red de nodos se recopilan de forma predeterminada a través del destino networkobservabilityRetina. Esto proporciona:

• Métricas básicas de red de nivel de nodo: visibilidad esencial del tráfico de red en el nivel de nodo
• Destinos predeterminados de Prometheus: las métricas de observabilidad de red se extraen automáticamente mediante Azure Monitor
• Integración de Azure Monitor: integración sin problemas con Azure Monitor; las métricas se recopilan automáticamente y se pueden visualizar en Grafana
• No se requiere ninguna configuración adicional: se habilita automáticamente cuando se configura Prometheus administrado por Azure Monitor
• Soporte técnico de Microsoft: compatible como parte de Azure Monitor y AKS

Nota: Esto requiere que el servicio administrado de Azure Monitor para Prometheus esté habilitado en el clúster de AKS, lo que puede tener costos asociados.

Introducción: Habilite el servicio administrado de Azure Monitor para Prometheus en el clúster de AKS mediante Azure Portal o la CLI. Las métricas de observabilidad de red se recopilarán y estarán disponibles automáticamente para su visualización en Azure Managed Grafana.

Observabilidad de red con el Software de código abierto Retina

Aunque Servicios avanzados de redes de contenedores (ACNS) es una oferta de pago que proporciona funcionalidades completas de observabilidad de red, Microsoft también admite observabilidad de red con el software de código abierto Retina, una plataforma de observabilidad de red de código abierto que proporciona funcionalidades esenciales de supervisión de red.

El software de código abierto Retina es la plataforma de observabilidad de código abierto disponible en retina.sh y GitHub. Ofrece:

• Observabilidad de red basada en eBPF: usa tecnologías eBPF para recopilar información con una sobrecarga mínima
• Análisis profundo del tráfico con el contexto de Kubernetes: captura y análisis completos de flujos de tráfico de red con integración completa de Kubernetes
• Recopilación de métricas avanzadas: métricas de nivel 4, métricas de DNS y funcionalidades de captura de paquetes distribuidos
• Extensibilidad basada en complementos: personalización y ampliación de la funcionalidad a través de una arquitectura de complemento
• Métricas compatibles con Prometheus: exportación de métricas de red completas en formato Prometheus con modos de métrica configurables
• Captura de paquetes distribuidos: capturas de paquetes a petición en varios nodos para una solución de problemas profunda
• Independiente de la plataforma y CNI: funciona con cualquier clúster de Kubernetes (AKS, habilitado para Arc, local), cualquier sistema operativo (Linux/Windows) y cualquier CNI
• Soporte técnico de la comunidad: código abierto con soporte técnico y contribuciones controlados por la comunidad
• Autoadministrado: control completo sobre la implementación y la configuración
• Integración de Intune: se integra con la Interfaz de Cilium para obtener información de red adicional

Introducción: Implementación del sistema operativo Retina mediante gráficos de Helm o manifiestos de Kubernetes desde el repositorio oficial de Retina. Configure Prometheus y Grafana para visualizar métricas, configurar el análisis profundo del tráfico con el contexto de Kubernetes, habilitar la captura de paquetes distribuida para la solución de problemas avanzada y personalizar la funcionalidad mediante la arquitectura basada en complementos para casos de uso específicos.

Comparación de ofertas de observabilidad de red

Offering	Support	Cost	Administración	Despliegue	Casos de uso
Advanced Container Networking Services (ACNS)	Soporte técnico empresarial de Microsoft	Servicio de Azure de pago	Totalmente administrado por Microsoft	Integración de Azure con un solo clic	Observabilidad empresarial administrada: flujos de red de nivel de pod, métricas de nivel de pod, métricas de DNS, registros almacenados persistentes, análisis de tráfico de nivel 7, cumplimiento de directivas de seguridad de red, informes de cumplimiento, paneles avanzados de Grafana, información con tecnología de IA
Observabilidad de red (Azure Monitor)	Soporte técnico de Microsoft como parte de Azure Monitor	Se incluye con Prometheus administrado de Azure Monitor (se aplican los costos de Azure Monitor)	Totalmente administrado por Microsoft	Automático cuando está habilitado Prometheus administrado por Azure Monitor	Supervisión de red de nodos: métricas de red de nivel de clúster y no de nivel de nodo, sin visibilidad de nivel de pod, sin registros almacenados, sin análisis de DNS, adecuado para la supervisión básica de la infraestructura y los usuarios que desean una observabilidad de red mínima sin configuración adicional
Software de código abierto Retina	Apoyo comunitario	Código abierto y gratuito	Autoadministrado	Configuración manual mediante Helm/manifests en cualquier clúster de Kubernetes	Observabilidad avanzada no administrada: capturas de paquetes en tiempo real, recopilación de métricas personalizadas, análisis de red profundo basado en eBPF, integración de Azure, implementaciones multinube, canalizaciones de observabilidad personalizadas, depuración avanzada con integración tcpdump/Wireshark y entornos de desarrollo y pruebas

Más información

Para empezar a trabajar con la observabilidad de red en AKS:

Servicios avanzados de redes de contenedores (ACNS)

• Configuración de registros de red de contenedor: aprenda a configurar registros de red de contenedor para una observabilidad de red completa
• Exploración de Advanced Container Networking Services: para más información sobre la plataforma completa, consulte ¿Qué es Advanced Container Networking Services para Azure Kubernetes Service (AKS)?
• Configuración de la supervisión: configuración de la integración de Azure Managed Grafana para visualizaciones avanzadas
• Más información sobre la seguridad de red: Exploración de las características de seguridad de red de contenedores para la aplicación de directivas y la detección de amenazas

Observabilidad de red (Azure Monitor)

• Integración de Azure Monitor: configuración de Azure Monitor para contenedores para ver las métricas de red básicas

Software de código abierto Retina

• Documentación oficial: Visite retina.sh para obtener documentación y guías completas
• Repositorio de GitHub: acceso al repositorio de GitHub de Microsoft Retina para obtener guías de instalación, ejemplos y soporte técnico de la comunidad
• Asistencia de la comunidad: únase a los debates de la comunidad de Retina para obtener ayuda y procedimientos recomendados