Qu’est-ce que l’agent Container Network Insights pour AKS ? (Préversion publique)

Container Network Insights Agent est un assistant de diagnostic basé sur l’IA qui vous permet d’identifier et de résoudre les problèmes réseau dans vos clusters Azure Kubernetes Service (AKS). Décrivez un problème dans le langage naturel, comme les échecs DNS, les suppressions de paquets, les services inaccessibles ou le trafic bloqué. L’agent collecte des preuves à partir de votre cluster et retourne un rapport structuré avec des instructions d’analyse et de correction de la cause racine.

Contrairement aux outils qui fonctionnent uniquement au niveau de la couche Kubernetes, Container Network Insights Agent peut également collecter des statistiques réseau au niveau de l’hôte via son plug-in réseau Linux. L’agent peut inspecter les mémoires tampons d’anneau de carte réseau, les compteurs de paquets du noyau, la distribution SoftIRQ et l’utilisation des mémoires tampons de socket sur vos nœuds de cluster. Cela présente des problèmes de bas niveau, tels que les suppressions de paquets, les goulots d’étranglement réseau et la saturation au niveau du matériel, qui sont autrement difficiles à diagnostiquer dans un environnement Kubernetes.

L’agent s’exécute en tant qu’application web en cluster déployée en tant qu’extension de cluster AKS. Vous y accédez via votre navigateur. Il fournit des insights, une analyse et des actions recommandées. Vous passez en revue les résultats et appliquez vous-même les modifications suggérées.

Que pouvez-vous faire avec l’agent Container Network Insights ?

L’agent Container Network Insights vous aide à résoudre les problèmes de mise en réseau AKS les plus courantes et les plus fastidieuses :

Chaque diagnostic produit un rapport structuré qui inclut ce qui a été vérifié, ce qui est sain, ce qui a échoué, la cause racine identifiée et les commandes exactes pour résoudre et vérifier le problème.

Quand utiliser l’agent Container Network Insights

Utiliser l’agent Container Network Insights lorsque vous avez besoin de

• Décrivez le problème en anglais brut : il n’est pas nécessaire de construire des commandes CLI ou de savoir quel outil gère chaque couche réseau. L’agent détermine automatiquement les étapes de diagnostic appropriées.
• Suivez les problèmes liés à Kubernetes et à la mise en réseau de l’hôte en une seule conversation : passez des stratégies réseau et du planning des pods aux tampons en anneau de la carte réseau et aux compteurs de noyau sans changer d’outils ni se connecter en SSH aux nœuds.
• Détecter les problèmes actifs, pas seulement les compteurs obsolètes : les mesures basées sur delta distinguent les problèmes qui se produisent actuellement par le bruit historique.
• Obtenir une analyse automatisée des causes racines avec des correctifs prêts à l’emploi : l’agent met en corrélation les preuves de plusieurs sources de données de cluster et fournit un rapport structuré avec des commandes de correction que vous pouvez copier et exécuter.
• Résolvez les problèmes sur un cluster AKS sans configuration supplémentaire : les diagnostics DNS, la suppression de paquets et le réseau Kubernetes fonctionnent prêtes à l’emploi. Activez Advanced Container Networking Services (ACNS) pour la stratégie Cilium et l’analyse de flux Hubble.

L’agent Container Network Insights n’est pas conçu pour

• Débogage de code d’application ou assistance au développement logiciel
• Résolution des problèmes de stockage, PersistentVolume ou disque
• Configuration RBAC, gestion des secrets ou audit de sécurité (à l’exception des stratégies réseau)
• Planification des charges de travail, optimisation des ressources ou gestion des coûts
• Environnements cloud non Azure (AWS, GCP)
• Apporter des modifications à votre cluster (l’agent fournit uniquement des recommandations ; vous les appliquez)

Fonctionnement

Lorsque vous décrivez un problème réseau, Container Network Insights Agent suit un flux de travail de diagnostic structuré :

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

L’agent Container Network Insights s’exécute en tant que pod à l’intérieur de votre cluster AKS. Vous interagissez avec celui-ci via un navigateur web via HTTPS. À l’intérieur du cluster, l’agent exécute des commandes de diagnostic via le serveur MCP AKS et se connecte à cinq sources de données via des plug-ins spécialisés :

• Serveur d’API Kubernetes : interroge des pods, des services, des nœuds, des stratégies réseau et d’autres ressources de cluster via kubectl le serveur AKS MCP.
• CoreDNS : collecte l’état d’intégrité et les métriques DNS via le plug-in DNS.
• Agent Cilium : inspecte les stratégies réseau Cilium et l’état du point de terminaison via le serveur AKS MCP via le plug-in Kubernetes Networking.
• Hubble : observe les flux réseau en direct et identifie le trafic supprimé via le serveur AKS MCP via le plug-in Kubernetes Networking.
• Pile réseau de nœuds : collecte les statistiques réseau au niveau de l’hôte (mémoires tampons RX/TX, état de la mémoire tampon en anneau, compteurs de réseau logiciel) via le plug-in réseau Linux.

L’agent communique de manière bidirectionnelle avec Azure OpenAI Service : il envoie votre requête en langage naturel, rassemble des preuves de diagnostic pour le raisonnement, et reçoit en retour des résultats diagnostiques structurés.

Le flux de travail de diagnostic suit quatre étapes :

1. Classifier : l’agent détermine la catégorie de problème (DNS, connectivité, stratégie réseau, routage de service ou suppressions de paquets) en fonction de votre description.
2. Collecter des preuves : l’agent exécute des commandes de diagnostic sur votre cluster via le serveur AKS MCP, à l’aide kubectlde , ciliumet hubble. Chaque catégorie de diagnostic utilise un workflow de collecte de preuves dédié pour collecter automatiquement les données appropriées.
3. Analyser : l’agent examine les preuves collectées pour séparer les signaux sains des anomalies. L’agent base toutes les conclusions sur la sortie de commande réelle, jamais sur la spéculation.
4. Rapport : Vous recevez un rapport structuré incluant :

• Résumé du problème et de son état
• Tableau de preuves montrant chaque vérification, son résultat et s’il a réussi ou échoué
• Analyse de ce qui fonctionne et de ce qui est rompu
• Identification de la cause racine avec des citations de preuves spécifiques
• Commandes exactes pour résoudre le problème et vérifier le correctif

Intégrations

L’agent Container Network Insights fonctionne avec les outils de mise en réseau AKS que vous utilisez déjà :

Modèle de sécurité et limitations

Interaction de l’agent avec votre cluster

Container Network Insights Agent collecte les données de diagnostic de votre cluster pour générer des insights, des rapports et des actions recommandées. Il exécute des opérations de cluster via le serveur AKS MCP et utilise un compte de service Kubernetes dédié (container-networking-agent-reader) avec des autorisations minimales limitées aux données dont il a besoin pour les diagnostics.

L’agent Container Network Insights n’apporte pas de modifications à votre cluster. Il fournit des commandes et des recommandations de correction, mais vous les examinez et appliquez-les vous-même.

Restrictions d’étendue

L’agent répond uniquement aux questions relatives à la mise en réseau et kubernetes et ne répond pas aux demandes hors rubrique. Le système inclut également des défenses d’injection rapide pour empêcher toute utilisation incorrecte.

Limites de session et de conversation

Parallélisme

Container Network Insights Agent prend en charge 1 à 7 utilisateurs simultanés dans des conditions classiques. Les diagnostics de suppression de paquets sur des clusters plus volumineux (25 nœuds+ ) peuvent nécessiter la limitation des utilisateurs simultanés afin d’éviter la charge du serveur d’API. Pour plus d’informations, consultez conseils sur la mise à l’échelle.

Scénarios et exemples d’invites

Dépannage DNS

Les échecs de résolution DNS sont l’un des problèmes de mise en réseau les plus courants dans Kubernetes. Lorsque les pods ne peuvent pas résoudre les noms de service, les domaines externes ou les deux, l’agent Container Network Insights exécute un diagnostic DNS complet qui vérifie l’intégrité, la configuration, la résolution DNS à partir de plusieurs chemins d’accès et les stratégies réseau susceptibles de bloquer le trafic DNS.

Situations courantes :

• Journal des pods ou journal des erreurs Name or service not known ou NXDOMAIN
• Les applications échouent lors de la connexion aux services par leur nom
• DNS fonctionne pour certains pods, mais pas pour d’autres
• La résolution de domaine externe échoue pendant que la résolution interne fonctionne (ou inversement)

Exemples d’invites :

Qu’est-ce que l’agent vérifie :

Le diagnostic DNS vérifie l’intégrité des pods CoreDNS, les points de terminaison de service et la configuration CoreDNS, y compris les ConfigMaps personnalisés. Il teste également la résolution DNS sur plusieurs chemins : même espace de noms, espace de noms croisés, nom de domaine complet et externe. L’agent évalue les métriques CoreDNS Prometheus et les règles de stratégie réseau, y compris les stratégies de sortie Cilium toFQDN susceptibles de restreindre silencieusement la résolution de domaine externe.

Exemples de causes racines identifiées par l'agent :

• Pods CoreDNS non en cours d’exécution ou non prêts
• ConfigMap CoreDNS personnalisé avec des règles de réécriture ou de transfert mal configurées
• Stratégie réseau bloquant le port UDP/TCP 53 (trafic DNS)
• La stratégie Cilium toFQDNs ne contient pas de domaine requis dans sa liste d'autorisation
• NodeLocal DNS DaemonSet déployé sans Cilium LocalRedirectPolicy
• Application configurée avec le nom DNS du service incorrect

Résolution des problèmes de suppression de paquets / RX

Les pertes de paquets sont difficiles à diagnostiquer, car elles peuvent se produire à plusieurs couches : matériel NIC, pile réseau du noyau ou tampons de mémoire des sockets d'application. L’agent Container Network Insights déploie un pod de débogage léger sur chaque nœud pour collecter les statistiques réseau au niveau de l’hôte. Il utilise ensuite des mesures delta pour identifier où les paquets sont perdus.

Situations courantes :

• Les applications signalent des réinitialisations ou des délais d’expiration intermittents des connexions
• Les outils comme iperf affichent la perte de paquets entre les nœuds
• Les pics de latence réseau apparaissent sur des nœuds spécifiques
• Utilisation élevée du processeur corrélée au traitement réseau
• ethtool -S affiche l’incrémentation des compteurs de suppression RX

Exemples d’invites :

Qu’est-ce que l’agent vérifie :

Le diagnostic de suppression de paquets examine l’utilisation de la mémoire tampon en anneau de carte réseau (ethtool), les statistiques de réseau logiciel du noyau (/proc/net/softnet_stat), la distribution par processeur SoftIRQ et la saturation de la mémoire tampon de socket. Il passe également en revue les statistiques d'interface réseau (/proc/net/dev), les tampons de noyau paramétrables (tcp_rmem, rmem_max, netdev_max_backlog), la configuration RPS/XPS/RFS et l'analyse des interfaces propres à CNI. L’agent utilise des mesures delta (captures avant et après) pour détecter les pertes actives par opposition aux compteurs historiques.

Exemples de causes racines identifiées par l'agent :

• Épuisement du tampon circulaire de la carte réseau : compteurs actifs rx_dropped en cours d’incrémentation
• Pertes de paquets du noyau : valeurs non nulles dans la /proc/net/softnet_stat colonne de pertes
• Dépassement de mémoire tampon du socket : la file d’attente de réception du socket augmente au-delà des limites de mémoire tampon
• Goulot d’étranglement du processeur SoftIRQ : élevé %soft sur un seul processeur avec une distribution d’interruption déséquilibrée
• Toutes les vérifications réussissent : l'agent signale « Aucun problème détecté » plutôt que de faire des suppositions.

Résolution des problèmes de mise en réseau Kubernetes

Lorsque les pods ne peuvent pas communiquer avec les services, les stratégies réseau bloquent le trafic attendu ou les services n’ont aucun point de terminaison, Container Network Insights Agent examine le chemin d’accès réseau complet. L’agent vérifie la planification et la préparation des pods, l’inscription des points de terminaison de service, l’évaluation de la stratégie réseau et l’observation des flux Hubble.

Situations courantes :

• Échec de la communication entre pods ou entre un pod et un service
• Les services ne sont pas accessibles à partir de certains espaces de noms
• Les stratégies réseau bloquent de façon inattendue le trafic
• Les points de terminaison de service existent, mais les connexions expirent toujours
• Hubble affiche DROPPED le verdict sur les flux entre les pods

Exemples d’invites :

Qu’est-ce que l’agent vérifie :

Le diagnostic réseau Kubernetes examine l’état et la planification des pods, la configuration du service et l’inscription des points de terminaison, ainsi que les stratégies réseau (Kubernetes NetworkPolicy et CiliumNetworkPolicy). Il analyse également les flux Hubble, incluant le trafic interrompu et le mappage des ports entre les services et les pods. Une erreur de configuration courante que l'agent intercepte est un service targetPort qui ne correspond pas au pod containerPort. Cette incompatibilité entraîne des délais d’expiration de connexion même si les points de terminaison semblent sains.

Exemples de causes racines identifiées par l'agent :

• Stratégie réseau (ou CiliumNetworkPolicy) bloquant le trafic d’entrée ou de sortie
• Le service targetPort ne correspond pas au pod containerPort
• Les étiquettes du sélecteur de service ne correspondent à aucune étiquette de pod (points de terminaison vides)
• Pod bloqué en attente en raison de demandes de ressources non planifiées
• Échec de la sonde de préparation, ce qui entraîne l’exclusion des pods des points de terminaison de service
• Les pods de l'agent Cilium ne sont pas en bon état

Problèmes connus et limitations du produit

Conseils de mise à l’échelle

La première requête d’un nouvel utilisateur peut prendre plus de temps si tous les agents du pool préchauffé (par défaut : trois agents) sont en cours d’utilisation. Les requêtes suivantes de la même session utilisent l’agent déjà initialisé.

Problèmes connus

Disponibilité de l’extension

L’extension AKS microsoft.containernetworkingagent est disponible dans toutes les régions publiques Azure où AKS est pris en charge. Il n'est pas disponible dans Azure Government, Microsoft Azure géré par 21Vianet ou d'autres clouds souverains.

Tarification

L’agent Container Network Insights s’exécute en tant que pod dans votre cluster AKS. Les coûts directs sont les suivants :

• Azure utilisation d’OpenAI : la consommation de jetons dépend de la longueur de conversation et de la complexité du diagnostic. Consultez Azure tarification OpenAI pour connaître les tarifs actuels.
• Calcul du nœud AKS : les pods de l’Agent Container Network Insights et, pour les diagnostics de suppression de paquets, le DaemonSet de débogage consomment des ressources de calcul du cluster.

Container Network Insights Agent lui-même n’a pas de frais de licence distincts pendant la préversion publique.

Accès et utilisation de l’agent Container Network Insights

Container Network Insights Agent est un chatbot basé sur un navigateur qui s’exécute à l’intérieur de votre cluster AKS. Après le déploiement, ouvrez l’URL de l’application dans n’importe quel navigateur moderne pour démarrer une conversation. Vous n’avez pas besoin d’un outil CLI sur votre station de travail ou un panneau portail pour naviguer. Il s’agit d’une interface de conversation autonome conçue pour les diagnostics réseau.

S’inscrire

Lorsque vous ouvrez d’abord l’URL de l’agent Container Network Insights, l’application vous invite à vous connecter. Selon la façon dont votre administrateur a configuré le déploiement, vous vous connectez avec un nom d’utilisateur simple (environnements de développement) ou vos informations d’identification Microsoft Entra ID (environnements de production).

Accorder des autorisations

Une fois connecté, l’application peut vous inviter à accorder des autorisations. Passez en revue les autorisations demandées et sélectionnez Accepter pour continuer.

Interface de conversation

Après vous être authentifié, vous accédez à l’interface de conversation. Le serveur gère votre session. Vous pouvez donc fermer et rouvrir l’onglet du navigateur dans la fenêtre de délai d’expiration de session sans perdre votre conversation.

L’interface de conversation est l’endroit où vous :

• Posez des questions en langage naturel : Tapez des invites telles que « Pourquoi mon pod ne peut-il pas résoudre DNS ? » ou « Vérifiez les pertes de paquets sur le nœud aks-nodepool1-vmss000000 ». Aucune syntaxe spéciale n’est requise.
• Recevoir des rapports de diagnostic structurés : les réponses incluent les tables de preuves, l’analyse de la cause racine et les commandes de correction que vous pouvez copier et exécuter.
• Démarrez de nouvelles conversations : chaque conversation conserve son propre contexte. Changez de rubriques en démarrant une nouvelle conversation.
• Envoyer des commentaires : après chaque réponse de diagnostic, utilisez les contrôles de commentaires intégrés (pouces haut et bas) pour évaluer la qualité du diagnostic. Vos commentaires permettent d’améliorer la précision future des diagnostics.

Signaler des problèmes

Si vous rencontrez un problème avec l’agent Container Network Insights :

1. Notez l’ID de session et l’horodatage du problème (visible dans l’interface de conversation)
2. Vérifiez les points de terminaison de santé : /health, /ready, /live
3. Vérifiez les journaux des pods : kubectl logs -l app=container-networking-agent -n kube-system
4. Émettre un problème via votre canal de support Azure standard

Étapes suivantes

• Démarrage rapide : Déployer l’agent Container Network Insights
• Résoudre les problèmes liés à l’agent Container Network Insights sur AKS
• Vue d’ensemble de Advanced Container Networking Services
• Azure CNI alimenté par Cilium