¿Qué es container Network Insights Agent para AKS? (Vista previa pública)

Container Network Insights Agent es un asistente de diagnóstico con tecnología de inteligencia artificial que le ayuda a identificar y resolver problemas de red en los clústeres de Azure Kubernetes Service (AKS). Describir un problema en lenguaje natural, como errores de DNS, caídas de paquetes, servicios inaccesibles o tráfico bloqueado. El agente recopila evidencias del clúster y devuelve un informe estructurado con instrucciones de análisis y corrección de la causa principal.

A diferencia de las herramientas que funcionan solo en la capa de Kubernetes, container Network Insights Agent también puede recopilar estadísticas de red de nivel de host a través de su complemento de redes de Linux. El agente puede inspeccionar los búferes en anillo de tarjetas NIC, los indicadores de paquetes de kernel, la distribución de SoftIRQ y el uso de búfer del socket en los nodos del clúster. Esto expone problemas de bajo nivel, como pérdidas de paquetes, cuellos de botella de red y saturación a nivel de hardware que, de lo contrario, son difíciles de diagnosticar en un entorno de Kubernetes.

El agente se ejecuta como una aplicación web en clúster implementada como una extensión de clúster de AKS. Accede a él a través del explorador. Proporciona información, análisis y acciones recomendadas. Revise los resultados y aplique los cambios sugeridos usted mismo.

¿Qué puede hacer con el agente de información de red para contenedores?

Container Network Insights Agent le ayuda a solucionar los problemas más comunes y más lentos de las redes de AKS:

Cada diagnóstico genera un informe estructurado que incluye lo que se ha comprobado, qué es correcto, qué ha fallado, la causa principal identificada y los comandos exactos para corregir y comprobar el problema.

Cuándo usar el agente de información de red de contenedores

Uso el agente de Container Network Insights cuando necesite

• Describir el problema en términos sencillos: no es necesario construir comandos de la CLI ni saber qué herramienta controla cada capa de red. El agente determina automáticamente los pasos de diagnóstico correctos.
• Seguimiento de problemas en Kubernetes y redes de host en una conversación: puede afectar a directivas de red y programación de pods hasta búferes en anillo de NIC e indicadores de kernel sin cambiar de herramienta o ni acceder a nodos mediante SSH.
• Detectar problemas activos, no solo contadores obsoletos: las medidas basadas en Delta distinguen los problemas que se producen en este momento del ruido histórico.
• Obtenga análisis automatizados de la causa raíz con correcciones listas para usar: el agente correlaciona la evidencia de varios orígenes de datos de clúster y entrega un informe estructurado con comandos de corrección que puede copiar y ejecutar.
• Solución de problemas en cualquier clúster de AKS sin configuración adicional: los diagnósticos de red de DNS, eliminación de paquetes y Kubernetes funcionan de forma predeterminada. Habilite Advanced Container Networking Services (ACNS) para la política de Cilium y el análisis de flujo de Hubble.

El agente de Container Network Insights no está diseñado para

• Depuración de código de aplicación o asistencia para el desarrollo de software
• Solución de problemas de almacenamiento, PersistentVolume o disco
• Configuración de RBAC, administración de secretos o auditoría de seguridad (excepto directivas de red)
• Programación de cargas de trabajo, optimización de recursos o administración de costos
• Entornos de nube no Azure (AWS, GCP)
• Realizar cambios en el clúster (el agente solo proporciona recomendaciones; las aplica)

Cómo funciona

Al describir un problema de red, container Network Insights Agent sigue un flujo de trabajo de diagnóstico estructurado:

You describe the issue → Agent classifies it → Collects evidence from the cluster → Analyzes findings → Reports results

Diagrama de arquitectura que muestra el agente de Container Network Insights dentro de un clúster de AKS, sus conexiones a orígenes de datos de clúster y su integración con Azure OpenAI Service.

Container Network Insights Agent se ejecuta como un pod dentro del clúster de AKS. Interactúa con él a través de un explorador web a través de HTTPS. Dentro del clúster, el agente ejecuta comandos de diagnóstico a través del servidor MCP de AKS y se conecta a cinco orígenes de datos a través de complementos especializados:

• Servidor de API de Kubernetes: consulta pods, servicios, nodos, directivas de red y otros recursos de clúster a través kubectl del servidor MCP de AKS.
• CoreDNS: recopila el estado de mantenimiento de DNS y las métricas a través del complemento DNS.
• Agente de Cilium: inspecciona las directivas de red de Cilium y el estado del punto de conexión a través del servidor MCP de AKS a través del complemento de redes de Kubernetes.
• Hubble: observa los flujos de red en directo e identifica el tráfico descartado a través del servidor MCP de AKS mediante el complemento de redes de Kubernetes.
• Pila de red de nodos: recopila estadísticas de red a nivel de host (búferes RX/TX, estado del búfer de anillo, contadores de softnet) a través del complemento de red de Linux.

El agente se comunica bidireccionalmente con Azure OpenAI Service: envía la consulta de lenguaje natural y recopila evidencia de diagnóstico para el razonamiento y recibe información de diagnóstico estructurada a cambio.

El flujo de trabajo de diagnóstico sigue cuatro pasos:

1. Clasificación: el agente determina la categoría de problema (DNS, conectividad, directiva de red, enrutamiento de servicio o caídas de paquetes) en función de la descripción.
2. Recopilar evidencia: el agente ejecuta comandos de diagnóstico en el clúster a través del servidor MCP de AKS, mediante kubectl, ciliumy hubble. Cada categoría de diagnóstico usa un flujo de trabajo de recopilación de evidencias dedicado para recopilar automáticamente los datos correctos.
3. Analizar: el agente examina la evidencia recopilada para separar las señales correctas de las anomalías. El agente basa todas las conclusiones sobre la salida real del comando, nunca sobre la especulación.
4. Informe: recibe un informe estructurado que incluye:

• Resumen del problema y su estado
• Tabla de evidencia que muestra cada comprobación, su resultado y si se pasó o no
• Análisis de lo que funciona y lo que está roto
• Identificación de la causa principal con citas de evidencia específicas
• Comandos exactos para corregir el problema y comprobar la corrección

Integrations

Container Network Insights Agent funciona con las herramientas de red de AKS que ya usa:

Modelo de seguridad y limitaciones

Cómo interactúa el agente con el clúster

El agente de Container Network Insights recopila datos de diagnóstico del clúster para generar información, informes y acciones recomendadas. Ejecuta operaciones de clúster a través del servidor MCP de AKS y usa una cuenta de servicio de Kubernetes dedicada (container-networking-agent-reader) con permisos mínimos en el ámbito de los datos que necesita para los diagnósticos.

Container Network Insights Agent no realiza cambios en el clúster. Proporciona comandos de remediación y recomendaciones, pero usted mismo los revisa y aplica.

Restricciones de ámbito

El agente solo responde a las preguntas relacionadas con las redes y Kubernetes y no responde a las solicitudes fuera del tema. El sistema también incluye medidas de defensa frente de inyecciones de instrucciones para evitar un uso indebido.

Límites de sesión y conversación

Concurrency

Container Network Insights Agent admite usuarios simultáneos de 1 a 7 en condiciones típicas. Los diagnósticos de eliminación de paquetes en clústeres más grandes (más de 25 nodos) pueden requerir limitar los usuarios simultáneos para evitar la carga del servidor de API. Para obtener más información, consulte Guía de escalado.

Escenarios de ejemplo y avisos de ejemplo

Solución de problemas de DNS

Los errores de resolución de DNS son uno de los problemas de red más comunes en Kubernetes. Cuando los pods no pueden resolver nombres de servicio, dominios externos o ambos, el agente de Container Network Insights ejecuta un diagnóstico completo de DNS que comprueba el estado, la configuración, la resolución DNS desde varias rutas de acceso y las directivas de red que podrían bloquear el tráfico DNS.

Situaciones comunes:

• Errores de registro de pods Name or service not known o NXDOMAIN
• Se agota el tiempo de espera de las aplicaciones para conectarse a los servicios por nombre
• DNS funciona para algunos pods, pero no para otros
• Se produce un error en la resolución de dominios externos mientras funciona la resolución interna (o viceversa)

Indicaciones de ejemplo:

Lo que comprueba el agente:

El diagnóstico de DNS comprueba el estado del pod de CoreDNS, los puntos de conexión del servicio y la configuración de CoreDNS, incluidos los ConfigMaps personalizados. También prueba la resolución de DNS en múltiples rutas: mismo espacio de nombres, espacio de nombres cruzado, FQDN y externo. El agente evalúa las métricas de CoreDNS Prometheus y las reglas de directiva de red, incluidas las directivas de salida de Cilium toFQDN que podrían restringir silenciosamente la resolución de dominios externos.

Ejemplos de causas raíz que el agente identifica:

• Pods de CoreDNS que no se ejecutan o no están listos
• ConfigMap de CoreDNS personalizado con reglas de reescritura o reenvío mal configuradas
• Directiva de red que bloquea el puerto UDP/TCP 53 (tráfico DNS)
• La política Cilium toFQDNs carece de un dominio requerido en su lista de permitidos.
• DaemonSet de NodeLocal DNS implementado sin una directiva LocalRedirectPolicy de Cilium
• Aplicación configurada con el nombre DNS de servicio incorrecto

Solución de problemas de pérdida de paquetes o paquetes en estado de recepción

Las caídas de paquetes son difíciles de diagnosticar porque pueden producirse en varias capas: hardware de NIC, pila de redes de kernel o búferes de socket de aplicación. Container Network Insights Agent implementa un pod de diagnóstico ligero en cada nodo para recopilar estadísticas de red a nivel de host. A continuación, usa medidas delta para identificar dónde se pierden los paquetes.

Situaciones comunes:

• Las aplicaciones notifican restablecimientos de conexión intermitentes o tiempos de espera
• Herramientas como iperf muestran la pérdida de paquetes entre los nodos
• Los picos de latencia de red aparecen en nodos específicos
• Uso elevado de CPU correlacionado con el procesamiento de red
• ethtool -S refleja el incremento de los indicaciones de pérdida de paquetes en estado de recepción

Indicaciones de ejemplo:

Lo que comprueba el agente:

El diagnóstico de pérdida de paquetes permite examinar el uso del búfer en anillo de NIC (ethtool), las estadísticas de cola de procesamiento (softnet) de kernel (/proc/net/softnet_stat), la distribución de SoftIRQ por CPU y la saturación de búfer del socket. También revisa las estadísticas de la interfaz de red (/proc/net/dev), los ajustes de los búferes del núcleo (tcp_rmem, rmem_max, netdev_max_backlog), la configuración de RPS/XPS/RFS y el análisis de la interfaz específica de CNI. El agente usa indicadores delta (instantáneas de antes y después) para detectar pérdidas activas al cotejarlos con datos históricos.

Ejemplos de causas raíz que el agente identifica:

• Agotamiento del búfer en anillo de NIC: incremento de indicadores de rx_dropped activos
• Pérdida de paquetes del kernel: valores distintos de cero en la columna /proc/net/softnet_stat sobre pérdidas
• Saturación de búfer del socket: la cola de recepción del socket sobrepasa los límites del búfer
• Cuello de botella de CPU por procesamiento de interrupciones de software (SoftIRQ): alto valor de %soft en un solo núcleo de CPU debido a una distribución desigual
• Todas las comprobaciones se validan: el agente informa de que se "No se ha detectado ningún problema" en base a hechos y no conjeturas

Solución de problemas de redes de Kubernetes

Cuando los pods no se pueden comunicar con los servicios, las directivas de red bloquean el tráfico previsto o los servicios no tienen ningún punto de conexión, el agente de información de red para contendores investiga la ruta de red entera. El agente comprueba la programación y preparación del pod, el registro del punto de conexón de servicio, la evaluación de las directivas de red y la observación de flujos de Hubble.

Situaciones comunes:

• Falla la comunicación de pod a pod o de pod a servicio
• Los servicios no son accesibles desde determinados espacios de nombres
• Las directivas de red bloquean inesperadamente el tráfico
• Existen puntos de conexión de servicio, se sigue agotando el tiempo de espera en las conexiones
• Hubble indica que los paquetes se han denegado con el veredicto DROPPED en las comunicaciones entre pods

Indicaciones de ejemplo:

Lo que comprueba el agente:

El diagnóstico de red de Kubernetes examina el estado y la programación de los pods, la configuración del servicio y el registro de puntos de conexión, así como las políticas de red (NetworkPolicy de Kubernetes y CiliumNetworkPolicy). También analiza los flujos de Hubble, como el tráfico denegado y la asignación de puertos del servicio a pods. Una configuración incorrecta común que detecta el agente es un servicio targetPort que no coincide con el pod containerPort. Esta falta de coincidencia provoca tiempos de espera de conexión aunque los puntos de conexión aparezcan en buen estado.

Ejemplos de causas raíz que el agente identifica:

• Directiva de red (o CiliumNetworkPolicy) que bloquea el tráfico de entrada o salida
• El servicio targetPort no coincide con el containerPort del pod
• Las etiquetas del selector de servicio no coinciden con ninguna etiqueta de pod (puntos de conexión vacíos)
• Pod se queda en estado Pendiente debido a solicitudes de recursos no programadas
• Se produce un error en el sondeo de preparación, lo que hace que se excluyan los pods de los puntos de conexión de servicio
• Los pods del agente de Cilium no están en estado operativo

Problemas conocidos y limitaciones del producto

Guía de escalado

La primera consulta de un nuevo usuario puede tardar más si todos los agentes del grupo preconfigurado (con un valor predeterminado de tres agentes) están en uso. Las consultas posteriores de la misma sesión usan el agente ya inicializado.

Problemas conocidos

Disponibilidad de extensiones

La extensión microsoft.containernetworkingagent AKS está disponible en todas las regiones públicas Azure en las que se admite AKS. No está disponible en Azure Government, Microsoft Azure operados por 21Vianet u otras nubes soberanas.

Precios

El agente de información de red para contenedores se ejecuta como un pod en el clúster de AKS. Los costos directos incluyen:

• Uso de Azure OpenAI: El consumo de tokens depende de la longitud de la conversación y la complejidad del diagnóstico. Consulte precios de Azure OpenAI para ver las tarifas actuales.
• Procesamiento de nodos de AKS: el pod del agente de información de red para contenedores y (para diagnósticos de pérdida de paquetes) el DaemonSet de depuración consumen recursos de procesamiento del clúster.

El propio agente de Container Network Insights no tiene ninguna tarifa de licencia independiente durante la versión preliminar pública.

Acceso y uso del agente de Container Network Insights

Container Network Insights Agent es un bot de chat basado en explorador que se ejecuta dentro del clúster de AKS. Después de la implementación, abra la dirección URL de la aplicación en cualquier explorador moderno para iniciar una conversación. No necesita una herramienta de línea de comandos (CLI) en la estación de trabajo ni un módulo en el portal para operar. Es una interfaz de chat independiente diseñada para diagnósticos de red.

Registrarse

Cuando abra por primera vez la dirección URL del agente de Container Network Insights, la aplicación le pedirá que inicie sesión. En función de cómo el administrador configuró la implementación, inicie sesión con un nombre de usuario simple (entornos de desarrollo) o con las credenciales de Microsoft Entra ID (entornos de producción).

Concesión de permisos

Después de iniciar sesión, es posible que la aplicación le pida que conceda permisos. Revise los permisos solicitados y seleccione Aceptar para continuar.

Interfaz de chat

Después de autenticarse, llegará a la interfaz de chat. El servidor mantiene la sesión, por lo que puede cerrar y volver a abrir la pestaña del explorador dentro de la ventana de tiempo de espera de la sesión sin perder la conversación.

La interfaz de chat es el lugar donde puedes:

• Formular preguntas en lenguaje natural: escriba mensajes como "¿Por qué no puede resolver el DNS de mi pod?" o "Comprobar las caídas de paquetes en el nodo aks-nodepool1-vmss000000" . No se requiere ninguna sintaxis especial.
• Recibir informes de diagnóstico estructurados: las respuestas incluyen tablas de evidencia, análisis de causa principal y comandos de corrección que puede copiar y ejecutar.
• Iniciar nuevas conversaciones: cada conversación mantiene su propio contexto. Cambie los temas iniciando una nueva conversación.
• Enviar comentarios: Después de cada respuesta de diagnóstico, use los controles de comentarios integrados (pulgar arriba y pulgar abajo) para evaluar la calidad del diagnóstico. Sus comentarios ayudan a mejorar la precisión futura del diagnóstico.

Notificar problemas

Si se produce un problema con container Network Insights Agent:

1. Anote el identificador de sesión y la marca de tiempo del problema (visible en la interfaz de chat).
2. Compruebe los puntos de comprobación de estado de salud: /health, /ready, /live
3. Revise los registros de pod: kubectl logs -l app=container-networking-agent -n kube-system
4. Enviar un problema a través del canal de soporte de Azure estándar

Pasos siguientes

• Inicio rápido: Implementación del agente de Container Network Insights
• Solución de problemas del agente de información de red para contenedores en AKS
• Introducción a Advanced Container Networking Services
• Azure CNI impulsado por Cilium