Solución de problemas del agente de información de red para contenedores en AKS

En este artículo se tratan los problemas comunes que pueden surgir al implementar, configurar o usar el agente de Container Network Insights en AKS. Cada sección sigue un formato Síntoma → Causa → Resolución.

Para obtener instrucciones de implementación, consulte Implementación y uso del agente de Container Network Insights en AKS.

Error en la instalación de la extensión

Síntoma: El az k8s-extension create comando produce un error o el estado de aprovisionamiento de la extensión muestra Failed.

Cause: región de nube soberana (la extensión solo se admite en regiones públicas de Azure), faltan características del clúster o permisos insuficientes.

Resolución:

1. Compruebe el estado de aprovisionamiento de extensiones para obtener más información:

   az k8s-extension show \
       --cluster-name $CLUSTER_NAME \
       --resource-group $RESOURCE_GROUP \
       --cluster-type managedClusters \
       --name containernetworkingagent \
       --query "{state:provisioningState, statuses:statuses}" -o json
   

2. Compruebe que el clúster está en una región pública de Azure. La extensión está disponible en todas las Azure regiones públicas en las que se admite AKS, pero no está disponible en Azure Government, Microsoft Azure operado por 21Vianet u otras nubes soberanas.

3. Compruebe que el clúster tiene habilitada la identidad de carga de trabajo y el emisor de OIDC :

   az aks show \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --query "{oidcEnabled:oidcIssuerProfile.enabled, workloadIdentityEnabled:securityProfile.workloadIdentity.enabled}"
   

4. Compruebe que tiene los roles Contributor y User Access Administrator en el grupo de recursos.

5. Si ya se ejecutó az k8s-extension create una vez, al ejecutarlo de nuevo se devuelve un error porque la extensión ya existe. Use az k8s-extension update para cambiar las opciones de configuración en una extensión existente:

   az k8s-extension update \
     --cluster-name $CLUSTER_NAME \
     --resource-group $RESOURCE_GROUP \
     --cluster-type managedClusters \
     --name containernetworkingagent \
     --configuration-settings config.SOME_SETTING=new-value
   

Errores de identidad y permisos

Síntoma: El pod del agente se inicia, pero devuelve los errores 401 Unauthorized o 403 Forbidden al procesar las solicitudes. Los registros de pod muestran errores de autenticación o autorización.

Causa: La identidad gestionada carece de las asignaciones de roles de RBAC necesarias, o el sujeto de la credencial federada no coincide con la cuenta de servicio del agente.

Resolución:

1. Compruebe que la identidad administrada tiene las cuatro asignaciones de roles necesarias:

   az role assignment list --assignee <identity-principal-id> --all -o table
   

   Confirme que estos roles están presentes:

   Función	Ámbito
   Cognitive Services OpenAI User	Recurso de Azure OpenAI
   Azure Kubernetes Service Cluster User Role	Clúster de AKS
   Azure Kubernetes Service Contributor Role	Clúster de AKS
   Reader	Grupo de recursos

2. Compruebe que la identidad de carga de trabajo está habilitada en el clúster:

   az aks show \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --query "securityProfile.workloadIdentity.enabled"
   

3. Compruebe que el sujeto de credenciales federadas coincide con la cuenta de servicio:

   az identity federated-credential list \
       --identity-name $IDENTITY_NAME \
       --resource-group $RESOURCE_GROUP
   

   El subject campo debe ser system:serviceaccount:kube-system:container-networking-agent-reader.

4. Compruebe que la cuenta de servicio de Kubernetes tiene la anotación de identidad de carga de trabajo correcta:

   kubectl get serviceaccount container-networking-agent-reader -n kube-system -o yaml
   

   La azure.workload.identity/client-id anotación debe coincidir con el identificador de cliente de la identidad administrada. Si no coincide, corrígelo y reinicia el pod:

   kubectl annotate serviceaccount container-networking-agent-reader \
     -n kube-system \
     azure.workload.identity/client-id=$IDENTITY_CLIENT_ID \
     --overwrite
   
   kubectl rollout restart deployment container-networking-agent -n kube-system
   

Problemas de conectividad de Azure OpenAI

Síntoma: El pod del agente se inicia pero se produce un error en las solicitudes de chat. En los registros del pod aparecen los errores 401 Unauthorized, 404 Not Found o los errores de conexión que hacen referencia al punto de conexión de Azure OpenAI.

Cause: El punto de conexión de OpenAI Azure, el nombre de implementación o las credenciales de identidad administrada están mal configurados o se bloquea el tráfico de red al punto de conexión.

Resolución:

1. Compruebe los registros de pod para ver patrones de error específicos:

   Mensaje de registro	Causa	Corregir
   401 Unauthorized	Rol Cognitive Services OpenAI User no disponible en la identidad administrada	Asignación del rol en el recurso de OpenAI
   404 Not Found	URL del endpoint o nombre de implementación incorrectos	Comprobar AZURE_OPENAI_ENDPOINT y AZURE_OPENAI_DEPLOYMENT
   Connection refused / Name resolution failed	Problema de red o DNS	Compruebe las reglas de NSG o firewall y compruebe el nombre de host del punto de conexión.
   Token acquisition failed	Identidad de carga de trabajo no configurada	Comprobación de la anotación de la cuenta de servicio y las credenciales federadas

2. Compruebe que la identidad administrada tiene el rol de Cognitive Services OpenAI User en el recurso de OpenAI de Azure:

   az role assignment list \
     --assignee <managed-identity-principal-id> \
     --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<openai-resource-name> \
     --output table
   

3. Si usa directivas de red, Azure Firewall o NSG, asegúrese de que se permite el tráfico HTTPS saliente (puerto 443) desde el espacio de nombres kube-system al punto de conexión de OpenAI de Azure. Compruebe que ninguna directiva de red bloquea el tráfico saliente:

   kubectl get networkpolicies -n kube-system
   

Errores de autenticación de Entra ID y registro de aplicaciones

Síntoma: Los flujos de inicio de sesión de Microsoft Entra ID (MSAL) fallan, cuando se redirecciona al usuario tras iniciar sesión, se generan errores o en los registros del pod aparece el valor de marcador de posición 44444444-4444-4444-4444-444444444444 en ENTRA_CLIENT_ID.

Causa: El registro de aplicaciones no está configurado correctamente o no se estableció durante la ENTRA_CLIENT_ID implementación de la extensión.

Resolución:

1. Si en los registros del pod se visualiza el valor del marcador de posición 44444444-4444-4444-4444-444444444444, actualice la extensión con el ID de cliente real del registro de aplicaciones:

   az k8s-extension update \
     --cluster-name $CLUSTER_NAME \
     --resource-group $RESOURCE_GROUP \
     --cluster-type managedClusters \
     --name containernetworkingagent \
     --configuration-settings config.ENTRA_CLIENT_ID=<your-app-registration-client-id>
   

2. Si se produce un error en la devolución de llamada del inicio de sesión con el error redirect_uri mismatch, verifique el URI de redireccionamiento en Azure Portal en Registros de aplicaciones > Su aplicación > Autenticación > URI de redireccionamiento. Para el acceso local reenviado por puerto, el URI debe ser http://localhost:8080/auth/callback.

   Nota:

   Actualmente solo se admite localhost URI de redirección. Las direcciones URL públicas de Load Balancer no se admiten para URI de redirección.

3. Asegúrese de que el registro de aplicaciones tiene los permisos delegados necesarios de Microsoft Graph: openid, profile, User.Read, offline_access. Si se requiere el consentimiento del administrador, concédalo:

   az ad app permission admin-consent --id <app-registration-object-id>
   

4. Compruebe los registros de pod para ver si hay errores específicos de la autenticación:

   kubectl logs -n kube-system -l app=container-networking-agent | grep -i "auth\|msal\|entra"
   

Faltan variables de entorno en el inicio

Síntoma: El pod del agente se bloquea inmediatamente al iniciarse con:

RuntimeError: Missing required Azure OpenAI environment variable(s): AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_DEPLOYMENT, AZURE_OPENAI_API_VERSION.

Causa: No se establecieron uno o varios valores de configuración necesarios cuando se implementó la extensión.

Resolución:

1. Compruebe los valores de marcador de posición de ConfigMap o las configuraciones faltantes.

   kubectl get configmap -n kube-system -l app=container-networking-agent -o yaml
   

2. Confirme que estas variables necesarias se establecen con valores reales (no con marcadores de posición como 00000000-0000-0000-0000-000000000000):

   Variable	Descripción	Ejemplo
   AZURE_OPENAI_ENDPOINT	Azure punto de conexión de recursos de OpenAI	https://your-instance.openai.azure.com/
   AZURE_OPENAI_DEPLOYMENT	Nombre de implementación del modelo	gpt-4o
   AZURE_OPENAI_API_VERSION	Versión de API	2025-03-01-preview
   AZURE_CLIENT_ID	Identificador de cliente de identidad administrada	Identificador Único Universal (UUID)
   AZURE_TENANT_ID	id. de inquilino de Azure	Identificador Único Universal (UUID)
   AZURE_SUBSCRIPTION_ID	identificador de suscripción de Azure	Identificador Único Universal (UUID)
   AKS_CLUSTER_NAME	Nombre del clúster de AKS	Nombre del clúster
   AKS_RESOURCE_GROUP	Grupo de recursos del clúster	Su grupo de recursos

3. Si los valores muestran marcadores de posición, actualice la extensión con la configuración correcta:

   az k8s-extension update \
     --cluster-name $CLUSTER_NAME \
     --resource-group $RESOURCE_GROUP \
     --cluster-type managedClusters \
     --name containernetworkingagent \
     --configuration-settings config.AZURE_OPENAI_ENDPOINT=<your-endpoint> \
     --configuration-settings config.AZURE_OPENAI_DEPLOYMENT=<your-deployment>
   

El pod del agente no se está ejecutando o se cierra inesperadamente

Síntoma: El pod del agente tiene el estado CrashLoopBackOff, Error o Pending.

es-ES: Causa: Configuración incorrecta, falta de conectividad de Azure OpenAI o recursos de clúster insuficientes.

Resolución:

1. Compruebe si hay errores inmediatos en los eventos del pod:

   kubectl describe pod -n kube-system -l app=container-networking-agent
   

2. Compruebe los registros del pod para ver los mensajes de error.

   kubectl logs -n kube-system -l app=container-networking-agent --tail=200
   

3. Hacer coincidir los mensajes de registro con las causas conocidas:

   Mensaje de registro	Causa	Corregir
   Missing required Azure OpenAI environment variable(s)	ConfigMap tiene valores de marcador de posición	Establecimiento de valores correctos a través de az k8s-extension update
   bootstrap.validation_agent_failed	No se puede conectar a Azure OpenAI	Verificar red, URL del punto de conexión, e identidad administrada de RBAC
   AKS MCP binary not found	El binario falta en la imagen	Use la imagen de extensión oficial de acnpublic.azurecr.io
   FailedMount / error de montaje de volumen	Faltan secretos del certificado Hubble	Implementar con hubble.enabled=false o asegurarse de que ACNS está habilitado
   Token acquisition failed	Identidad de carga de trabajo no configurada	Comprobación de la anotación de la cuenta de servicio y las credenciales federadas

4. Compruebe que el punto de conexión de OpenAI de Azure sea accesible desde el clúster. Si usa restricciones de conexión de salida, asegúrese de que se permite el tráfico saliente HTTPS (puerto 443) del espacio de nombres kube-system al punto de conexión de Azure OpenAI.

Errores de sondeo de preparación

Síntoma: El pod está Running pero aparece activo el estado 0/1. El /ready punto de conexión devuelve HTTP 503.

Causa: No se han completado una o varias comprobaciones de inicio: el pool de agentes en espera aún no se ha inicializado, las propiedades del clúster tienen errores o no hay agentes previamente aprovisionados disponibles.

Resolución:

1. Espere entre 2 y 3 minutos después de la implementación para que el grupo que está en espera cree agentes preaprovisionados.

2. Verifique la respuesta de disponibilidad por razones específicas de falla.

   kubectl port-forward svc/container-networking-agent-service -n kube-system 8080:80
   curl -s http://localhost:8080/ready | jq
   

3. Consulte los registros de los pods para ver los problemas asociados al preaprovisionamiento.

   kubectl logs -n kube-system -l app=container-networking-agent | grep -i "warmup\|ready\|error"
   

4. Si se producen errores en las propiedades del clúster, compruebe que AKS_CLUSTER_NAME, AKS_RESOURCE_GROUPy AZURE_SUBSCRIPTION_ID estén configurados correctamente en la configuración de la extensión.

El grupo en espera sigue fallando

Síntoma: El pod está Running pero nunca llega a estar activo. Los registros de pod muestran errores repetidos "Failed to create warmed agent" incluso después de esperar varios minutos.

Causa: El grupo en espera que está en segundo plano no puede crear instancias de agente preaprovisionadas. Esto suele deberse a un problema de conectividad de OpenAI Azure sin resolver o a un error de inicialización de MCP que impide que se creen agentes.

Resolución:

1. Compruebe los registros del error subyacente específico:

   kubectl logs -n kube-system -l app=container-networking-agent | grep -i "warmup\|Failed to create"
   

2. Haga coincidir el error con su corrección:

   Error en los registros	Corregir
   401 Unauthorized o 403 Forbidden	Consulte problemas de conectividad de Azure OpenAI y verifique la asignación de roles de identidad administrada.
   Token acquisition failed	Consulte Errores de identidad y permisos.
   404 Not Found en el punto de conexión	Verifica AZURE_OPENAI_ENDPOINT y AZURE_OPENAI_DEPLOYMENT en ConfigMap
   AKS MCP binary not found	Consulte El pod del agente no se está ejecutando o se cierra inesperadamente

3. Una vez resuelto el problema subyacente, el grupo en espera vuelve a intentar la operación automáticamente. No es necesario reiniciar el pod a menos que el error persista después de corregir la causa principal.

Los comandos del Hubble fallan

Síntoma: El agente informa de errores para diagnósticos relacionados con Hubble o el análisis de flujo de Hubble no está disponible.

Causa: El clúster no tiene advanced Container Networking Services (ACNS) ni el plan de datos de Cilium habilitado.

Resolución:

• Si el clúster no usa ACNS, implemente la extensión con hubble.enabled=false y config.AKS_MCP_ENABLED_COMPONENTS=kubectl. El agente sigue generando diagnósticos de DNS, de pérdida de paquetes y de redes estándar de Kubernetes sin Hubble.

• Para habilitar Hubble, su clúster debe usar Azure CNI con tecnología de Cilium con Servicios de Red de Contenedor Avanzados (ACNS) habilitados.

• Compruebe que Hubble está en ejecución en su clúster:

  kubectl get pods -n kube-system -l k8s-app=hubble-relay
  

  Si no se devuelve ningún pod, significa que Hubble no está habilitado. Habilite ACNS en el clúster o establezca hubble.enabled=false en la configuración de la extensión.

Limitación de frecuencia de chat

Síntoma: Las solicitudes de chat devuelven HTTP 429 con X-RateLimit-* encabezados de respuesta o X-LLM-RateLimit-* .

Causa: El limitador de velocidad integrado está limitando las solicitudes para proteger el servicio.

Resolución:

Container Network Insights Agent tiene tres capas de limitación de velocidad:

• En errores 429 de chat: reduzca la frecuencia del mensaje y espere a que el controlador de límite de flujos se restablezca.
• En errores 429 de LLM: consulte la cuota de tokens por minuto (TPM) de Azure OpenAI en Azure Portal. Solicite un aumento de cuota en Cognitive Services > Cuotas si necesita mayor capacidad.

Mensaje de chat enviado pero sin respuesta

Síntoma: Se envía un mensaje de chat, pero no aparece ninguna respuesta. La solicitud se bloquea o, finalmente, devuelve un error de tiempo de espera.

Cause: Azure OpenAI puede tener limitada su capacidad o ser inaccesible, es posible que haya agentes en espera disponibles o puede que se esté ejecutando un comando de diagnóstico de larga duración.

Resolución:

1. Compruebe si el pod tiene sesiones activas y si tiene asignado un agente:

   kubectl port-forward svc/container-networking-agent-service -n kube-system 8080:80
   curl -s http://localhost:8080/api/status/sessions | jq
   

2. Compruebe los registros del pod para detectar patrones de error.

   kubectl logs -n kube-system -l app=container-networking-agent --tail=50
   

   Indicador de registro	Causa	Corregir
   429 errores	Azure OpenAI con limitación de tasa	Espere a que se restablezca el límite de tasa; comprueba tu cuota de TPM
   "No pre-warmed agents available"	Piscina de calentamiento no lista	Espere a que se inicialice; consulte El grupo en espera sigue fallando.
   Tiempos de espera de conexión	Problema de red o NSG	Verifica la red de pod, las reglas de DNS y NSG

3. Si la solicitud sigue pendiente pasados 2 minutos, inicie una nueva conversación y envíe primero una consulta simple (por ejemplo, "ver pods en el espacio de nombres predeterminado") para comprobar que el agente responde antes de formular una pregunta de diagnóstico compleja.

Latencia en la primera solicitud

Síntoma: El primer mensaje de chat después de la implementación o el reinicio del pod tarda entre 10 y 30 segundos en responder.

Causa: Container Network Insights Agent mantiene un grupo de agentes precalentados para reducir la latencia. Después de reiniciar un pod, el grupo de calentamiento necesita tiempo para inicializar cada agente, lo cual requiere el inicio del complemento MCP, la configuración de credenciales de Azure y la inicialización del marco de IA.

Resolución: Este es el comportamiento esperado. Espere a que el /ready endpoint devuelva HTTP 200 antes de enviar solicitudes, lo que confirma que hay al menos un agente precalentado disponible. Las solicitudes posteriores usan el grupo preaprovisionado y responden más rápido (normalmente entre 5 y 10 segundos en consultas sencillas).

kubectl port-forward svc/container-networking-agent-service -n kube-system 8080:80
curl -s http://localhost:8080/ready | jq

Respuestas lentas para diagnósticos complejos

Síntoma: Las respuestas de diagnóstico tardan entre 30 segundos y 2 minutos en completarse.

Causa: Los diagnósticos de varios pasos implican operaciones en secuencia: una llamada inicial de clasificación del LLM a Azure OpenAI, varios comandos kubectl/cilium/hubble ejecutados en el clúster y el análisis final del LLM de la evidencia recibida. Cada paso agrega latencia.

Resolución: Esto se espera para diagnósticos complejos. En la tabla siguiente se muestran los tiempos de respuesta típicos:

Para reducir la latencia:

• Use una consulta específica que tenga como destino un síntoma conocido en lugar de una pregunta amplia. Por ejemplo, "comprobar la resolución DNS para el servicio my-svc en el espacio de nombres my-ns" es más rápido que "diagnosticar todos los problemas de red".
• Asegúrese de que el recurso de OpenAI de Azure esté en la misma región Azure que el clúster de AKS para minimizar el tiempo de ida y vuelta de red.
• Compruebe la cuota de TPM de Azure OpenAI: una cuota mayor permite un procesamiento más paralelo de tokens.

Expiración de tiempo de espera de comandos de diagnóstico

Síntoma: El agente informa de que se agota el tiempo de espera de un comando o el chat deja de responder durante más de 10 minutos antes de devolver un error.

Causa: El tiempo de espera predeterminado para los comandos de diagnóstico (kubectl, cilium, hubble) es de 600 segundos (10 minutos). Las consultas amplias , como la recopilación de estadísticas de todos los nodos de un clúster grande, pueden superar este límite.

Resolución:

• Ámbito de la consulta a un nodo, pod o espacio de nombres específico en lugar de a todo el clúster. Por ejemplo:

  • En lugar de: "Verificar pérdidas de paquetes en todos los nodos"
  • Pida: "Verifique las caídas de paquetes en el nodo <specific-node-name>"

• Si los tiempos de espera se producen de forma coherente en un tipo de consulta, el clúster puede tener problemas de rendimiento o conectividad que ralentizan de forma independiente las respuestas de comandos.

• Consulte los registros de pod para ver las entradas relacionadas con los tiempos de espera:

  kubectl logs -n kube-system -l app=container-networking-agent | grep -i "timeout\|timed out"
  

Datos de sesión perdidos después del reinicio del pod

Síntoma: Todo el historial de chat y las sesiones activas desaparecerán después de reiniciar el pod.

Causa: Los datos de sesión solo se almacenan en memoria. Todos los datos se pierden cuando se reinicia el pod.

Resolución: Este es el comportamiento esperado para la arquitectura actual. Inicie una nueva sesión después de reiniciar un pod.

La sesión expira inesperadamente

Síntoma: Se cierra la sesión sin advertencia durante una sesión activa o la sesión finaliza después de un período de inactividad aunque esté usando la extensión.

Causa: Container Network Insights Agent aplica tiempos de espera de sesión para la seguridad. Se aplican dos límites independientes:

Resolución: Vuelva a iniciar sesión para iniciar una nueva sesión. El historial de chat de la sesión expirada no se puede recuperar.

El contexto de chat aparece perdido después de muchos intercambios

Síntoma: Después de aproximadamente 15 intercambios, el agente parece olvidar las partes anteriores de la conversación o no hace referencia al contexto anterior en la sesión.

Cause: Container Network Insights Agent resume el historial de conversaciones para permanecer dentro del límite de tokens de OpenAI de Azure. Cuando la ventana de contexto alcanza aproximadamente 15 mensajes, los mensajes más antiguos se reemplazan por un resumen generado automáticamente. Los mensajes más recientes y el resumen se conservan y pasan al modelo.

Resolución: Este es el comportamiento esperado. El resumen conserva el contexto clave de diagnóstico mientras gestiona los límites de tokens de Azure OpenAI. Si necesita hacer referencia a algo de mucho antes en la conversación:

• Repita el contexto pertinente: "Antes encontró X, ¿puede investigar más allá?"
• Inicie una nueva conversación con un resumen conciso de los hallazgos conocidos.

Límite de conversación alcanzado

Síntoma: La interfaz muestra un error que no se puede crear una nueva conversación o las conversaciones más antiguas desaparecen sin eliminarse explícitamente.

Causa: Cada cuenta de usuario está limitada a 20 conversaciones activas. Cuando se alcanza este límite, las dos conversaciones más antiguas se quitan automáticamente para hacer espacio, comenzando cuando el recuento alcanza los 18 (90% del límite de 20 conversaciones).

Resolución: Esta limpieza automática es el comportamiento esperado. Si no puede crear una nueva conversación, espere brevemente a que se ejecute la limpieza en segundo plano y vuelva a intentarlo. Las dos conversaciones menos usadas recientemente se quitan automáticamente.

El DaemonSet de depuración sigue funcionando de un fallo

Síntoma: El DaemonSet rx-troubleshooting-debug permanece en el kube-system namespace después de una sesión de diagnóstico.

Causa: el agente de información de red para contendores implementa un DaemonSet de depuración ligero durante los diagnósticos de pérdida de paquetes. Si el pod del agente se bloquea inesperadamente durante este diagnóstico, el paso de limpieza no se ejecuta.

Resolución: Elimine manualmente daemonSet:

kubectl delete ds rx-troubleshooting-debug -n kube-system

Error en el diagnóstico de pérdida de paquetes

Síntoma: Al pedir al agente que analice las pérdidas de paquetes, informa de errores que aparecen al implementar pods de diagnóstico o no puede recopilar las estadísticas sobre los nodos.

Causa: Los diagnósticos de pérdida de paquetes implementan un DaemonSet ligero (rx-troubleshooting-debug) en cada nodo para recopilar las estadísticas de red relacionadas con el de host (estadísticas de ethtool, indicadores de softnet, estado de búfer en anillo). Los errores se producen si la cuenta de servicio del agente no tiene permiso para crear DaemonSets en kube-system, o si los nodos bloquean el acceso con privilegios necesario para recopilar estadísticas de red host.

Resolución:

1. Compruebe si se creó daemonSet:

   kubectl get daemonset -n kube-system rx-troubleshooting-debug
   

   Si no existe, se produjo un error en el paso de implementación. Comprobar los registros de los pods:

   kubectl logs -n kube-system -l app=container-networking-agent | grep -i "daemonset\|rx\|packet\|error"
   

2. Si ha creado el DaemonSet, pero los pods no se inician, descríbalos para identificar la causa:

   kubectl describe pods -n kube-system -l app=cna-diagnostic
   

3. Compruebe que ClusterRole asignado al agente incluye permisos de creación de DaemonSet:

   kubectl get clusterrole -l app=container-networking-agent -o yaml | grep -A2 daemonset
   

4. Si el DaemonSet se queda tras una ejecución fallida, elimínelo manualmente y pida al agente que vuelva a intentarlo:

   kubectl delete daemonset -n kube-system -l app=cna-diagnostic
   

Los diagnósticos de DNS devuelven resultados incompletos o sin resultados

Síntoma: Al solucionar un problema de DNS, el agente devuelve datos de diagnóstico parciales, notifica errores que ejecutan comprobaciones de DNS o sale de la investigación sin resultados.

Causa: Las herramientas de diagnóstico dns del agente ejecutan pruebas de resolución e inspeccionan CoreDNS desde dentro del clúster. Los resultados incompletos pueden producirse si la cuenta de servicio del agente no tiene acceso de lectura de nivel de clúster, los pods de CoreDNS no son accesibles o los comandos individuales alcanzan el tiempo de espera de 30 segundos por comando.

Resolución:

1. Verifique que CoreDNS se está ejecutando:

   kubectl get pods -n kube-system -l k8s-app=kube-dns
   

   Si los pods de CoreDNS no se están ejecutando, esa será la causa principal. Descríbelos para más detalles.

   kubectl describe pods -n kube-system -l k8s-app=kube-dns
   

2. Verifique que la identidad administrada tenga la asignación de Azure Kubernetes Service Cluster User Role en el clúster. Este rol permite al agente recuperar kubeconfig y ejecutar comandos kubectl:

   az role assignment list --assignee <identity-principal-id> --all -o table
   

3. Si el agente notifica tiempos de espera de comandos durante las comprobaciones de DNS, limite la pregunta. Por ejemplo, en lugar de "diagnosticar todos los problemas de DNS", pregunte "comprobar la resolución DNS del pod <pod-name> en el espacio de nombres <namespace>".

El agente se detiene a mitad de la investigación.

Síntoma: El agente inicia una investigación de diagnóstico, pero se detiene antes de completarlo, sin proporcionar un análisis de causa principal o un informe final.

Causa: Varios factores pueden interrumpir una investigación en varios pasos:

• Se agotó el tiempo de espera de un comando de diagnóstico.
• Se ha llegado al límite de capacidad o el límite de tokens de Azure OpenAI a mitad de la investigación.
• La ventana de contexto del historial se ha saturado y el resumen automático ha hecho que el agente pierda la secuencia lógica del plan actual.

Resolución:

• Pida al agente que siga con la misma conversación: "Please continue the investigation" o "What other checks can you run?" el agente puede reanudarse a partir del estado actual.
• Si los tiempos de espera son la causa, defina el ámbito de la siguiente consulta de forma más estrecha. Por ejemplo, "compruebe el espacio de nombres específico <name>" en lugar de todo el clúster.
• Si la investigación se detuvo debido a la limitación de velocidad, espere un minuto y pida al agente que continúe.
• Para un nuevo inicio, abra una nueva conversación y proporcione un resumen conciso de lo que ya se encontró: "He confirmado que la resolución DNS está fallando en el espacio de nombres X. ¿Puede investigar la política de red para ese espacio de nombres?"

Identidad de carga de trabajo no habilitada en el clúster

Symptom: Error en la configuración de credenciales federadas o el pod del agente no se puede autenticar en Azure. En los registros de pods aparecen los errores "Failed to acquire token" o "AADSTS...".

Causa: El clúster de AKS se ha creado sin la identidad de la carga de trabajo o la entidad de autenticación de OIDC habilitadas.

Resolución: Habilite ambas características en el clúster existente mediante el az aks update comando :

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-oidc-issuer \
  --enable-workload-identity

Después de habilitarlo, vuelva a ejecutar los pasos de configuración de credenciales federadas de la guía de implementación para vincular la identidad administrada a la cuenta de servicio de Kubernetes.

Modelo de Azure OpenAI no disponible en la región seleccionada

Symptom: Error en la creación de la implementación de OpenAI en Azure, o falla al iniciar el agente de Container Network Insights debido a un error de punto de conexión o de modelo inmediatamente después de la implementación.

Cause: El modelo de OpenAI de Azure seleccionado no está disponible en la región de Azure elegida.

Resolución:

1. Compruebe qué modelos están disponibles en su región:

   az cognitiveservices model list -l <your-region> --output table
   

2. Use una región en la que el modelo de destino esté disponible. Consulte la referencia de soporte de regiones del modelo Azure OpenAI para obtener la disponibilidad actual.

3. Compruebe que la suscripción tiene suficiente cuota de Tokens-Per-Minute (TPM) para el modelo. Si se produce un error de cuota en la implementación del modelo, solicite un aumento de cuota en el portal de Azure en Cognitive Services > Cuotas.

Comandos de diagnóstico rápido

Use estos comandos para diagnosticar rápidamente problemas comunes:

# ──── Pod Status ────
kubectl get pods -n kube-system -l app=container-networking-agent
kubectl describe pod -n kube-system -l app=container-networking-agent
kubectl top pod -n kube-system -l app=container-networking-agent

# ──── Application Logs ────
kubectl logs -n kube-system -l app=container-networking-agent --tail=200
kubectl logs -n kube-system -l app=container-networking-agent -f              # Stream live
kubectl logs -n kube-system -l app=container-networking-agent | grep ERROR     # Errors only

# ──── Health Checks (requires port-forward) ────
kubectl port-forward svc/container-networking-agent-service -n kube-system 8080:80
curl -s http://localhost:8080/ready | jq
curl -s http://localhost:8080/live | jq
curl -s http://localhost:8080/api/status/sessions | jq

# ──── Configuration ────
kubectl get configmap -n kube-system -l app=container-networking-agent -o yaml
kubectl get serviceaccount container-networking-agent-reader -n kube-system -o yaml

# ──── Workload Identity ────
kubectl describe serviceaccount container-networking-agent-reader -n kube-system
az identity show --name $IDENTITY_NAME -g $RESOURCE_GROUP --query "{clientId:clientId, principalId:principalId}"

# ──── RBAC ────
az role assignment list --assignee <principal-id> --output table

# ──── Extension Status ────
az k8s-extension show \
  --cluster-name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --cluster-type managedClusters \
  --name containernetworkingagent \
  --query "{state:provisioningState, version:version}" -o table

# ──── Cleanup Stuck Resources ────
kubectl delete daemonset rx-troubleshooting-debug -n kube-system    # Leftover diagnostic DaemonSet
kubectl delete pod -n kube-system -l app=container-networking-agent    # Force pod restart

Pasos siguientes

• Implementación y uso del agente de Container Network Insights en AKS
• Introducción al agente de Container Network Insights
• Introducción a Advanced Container Networking Services
• Azure CNI impulsado por Cilium