Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Container Network Insights Agent ist ein KI-basierter Diagnoseassistent, der Ihnen hilft, Netzwerkprobleme in Ihren Azure Kubernetes Service (AKS) Clustern zu identifizieren und zu beheben. Beschreiben Sie ein Problem in natürlicher Sprache, z. B. DNS-Fehler, Paketabbrüche, nicht erreichbare Dienste oder blockierten Datenverkehr. Der Agent sammelt Nachweise aus Ihrem Cluster und gibt einen strukturierten Bericht mit Anleitungen zur Ursachenanalyse und Behebung zurück.
Im Gegensatz zu Tools, die nur auf der Kubernetes-Ebene ausgeführt werden, kann der Container Network Insights-Agent auch Netzwerkstatistiken auf Hostebene über das Linux Networking-Plug-In sammeln. Der Agent kann NIC-Ringspeicher, Kernelpaketzähler, SoftIRQ-Verteilung und Socketpufferauslastung auf Ihren Clusterknoten überprüfen. Dies zeigt Probleme auf niedriger Ebene wie Paketverluste, Netzwerkengpässe und hardwarebasierte Sättigung, die andernfalls in einer Kubernetes-Umgebung schwer zu diagnostizieren sind.
Der Agent wird als In-Cluster-Webanwendung ausgeführt, die als AKS-Clustererweiterung bereitgestellt wird. Sie greifen über Ihren Browser darauf zu. Es bietet Einblicke, Analysen und empfohlene Aktionen. Sie überprüfen die Ergebnisse und wenden alle vorgeschlagenen Änderungen selbst an.
Hinweis
Container Network Insights Agent ist ein reines Cloudfeature für Azure Kubernetes Service (AKS). Es wird nicht auf AKS-Hybrid, AKS auf Azure Stack HCI oder Arc-fähigen Kubernetes-Clustern unterstützt.
Von Bedeutung
AKS-Preview-Funktionen stehen auf Selbstbedienungs- und Opt-in-Basis zur Verfügung. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:
Was können Sie mit container Network Insights Agent tun?
Container Network Insights Agent hilft Ihnen bei der Behandlung der häufigsten und zeitaufwendigen Kategorien von AKS-Netzwerkproblemen:
| Fähigkeit | Was es tut |
|---|---|
| DNS-Problembehandlung | Diagnose von CoreDNS-Fehlern, falsch konfigurierten DNS-Richtlinien, Netzwerkrichtlinien, die DNS-Datenverkehr blockieren, NodeLocal-DNS-Probleme und Cilium-FQDN-Ausgangsbeschränkungen |
| Paketverlustanalyse | Untersucht RX-Verluste auf NIC-Ebene, Verlust von Kernelpaketen, Überlauf des Socketpuffers, SoftIRQ-Sättigung und Ringpufferausschöpfung über Clusterknoten hinweg. |
| Kubernetes-Netzwerkdiagnose | Identifiziert Pod-Konnektivitätsfehler, Fehlkonfigurationen des Dienstports, Netzwerkrichtlinienkonflikte, fehlende Endpunkte und Hubble-Flussanalyse |
| Clusterressourcenabfragen | Beantwortet Fragen zu Pods, Diensten, Deployments, Nodes und Namespaces und bietet Ihnen ein schnelles Verständnis der Situation. |
Jede Diagnose erzeugt einen strukturierten Bericht, der beinhaltet, was überprüft wurde, was fehlerfrei ist, was fehlgeschlagen ist, die identifizierte Hauptursache sowie die genauen Befehle zum Beheben und Überprüfen des Problems.
Wann der Container Network Insights-Agent verwendet werden soll
Verwenden sie den Container Network Insights-Agent, wenn Sie dies benötigen
- Beschreiben Sie das Problem in einfachem Englisch: Sie müssen keine CLI-Befehle erstellen oder wissen, welches Tool die einzelnen Netzwerkebenen verarbeitet. Der Agent bestimmt automatisch die richtigen Diagnoseschritte.
- Verfolgen von Problemen in Kubernetes und Hostnetzwerken in einer Unterhaltung: Arbeiten Sie mit Netzwerkrichtlinien und Pod-Scheduling bis hin zu NIC-Ringpuffern und Kernelzählern, ohne die Tools zu wechseln oder sich per SSH in Knoten einzuloggen.
- Erkennung aktiver Probleme, nicht nur veralteter Zähler: Delta-basierte Messungen unterscheiden Probleme, die gerade auftreten, von historischem Rauschen.
- Erhalten Sie automatisierte Ursachenanalyse mit sofort einsatzbereiten Fixes: Der Agent korreliert Nachweise aus mehreren Clusterdatenquellen und liefert einen strukturierten Bericht mit Wartungsbefehlen, die Sie kopieren und ausführen können.
- Problembehandlung für AKS-Cluster ohne zusätzliche Einrichtung: DNS, Paketverlust und Kubernetes-Netzwerkdiagnose funktionieren standardmäßig. Aktivieren Sie Advanced Container Networking Services (ACNS) für die Cilium-Richtlinie und die Hubble-Flussanalyse.
Container Network Insights Agent ist nicht dafür konzipiert,
- Unterstützung beim Debuggen von Anwendungscode oder bei der Softwareentwicklung
- Problembehandlung bei Speicher, PersistentVolume oder Datenträger
- RBAC-Konfiguration, geheime Verwaltung oder Sicherheitsüberwachung (außer Netzwerkrichtlinien)
- Arbeitsauslastungsplanung, Ressourcenoptimierung oder Kostenverwaltung
- Nicht Azure Cloudumgebungen (AWS, GCP)
- Vornehmen von Änderungen an Ihrem Cluster (der Agent enthält nur Empfehlungen; Sie wenden sie an)
So funktioniert es
Wenn Sie ein Netzwerkproblem beschreiben, folgt der Container Network Insights Agent einem strukturierten Diagnoseworkflow:
You describe the issue → Agent classifies it → Collects evidence from the cluster → Analyzes findings → Reports results
Der Container Network Insights Agent läuft als Pod innerhalb Ihres AKS-Clusters. Sie interagieren mit diesem über einen Webbrowser über HTTPS. Innerhalb des Clusters führt der Agent Diagnosebefehle über den AKS MCP-Server aus und stellt über spezielle Plug-Ins eine Verbindung mit fünf Datenquellen bereit:
-
Kubernetes-API-Server: Abfragen von Pods, Diensten, Knoten, Netzwerkrichtlinien und anderen Clusterressourcen über
kubectlden AKS MCP-Server. - CoreDNS: Erfasst den DNS-Integritätsstatus und Metriken über das DNS-Plug-In.
- Cilium Agent: Prüft Cilium-Netzwerkrichtlinien und Endpunktstatus über den AKS MCP-Server über das Kubernetes Networking-Plug-In.
- Hubble: Beobachtet Live-Netzwerkflüsse und identifiziert den verworfenen Datenverkehr über den AKS MCP-Server über das Kubernetes Networking-Plug-In.
- Node Network Stack: Sammelt Netzwerkstatistiken auf Hostebene (RX/TX-Puffer, Ringpufferzustand, Softnetzähler) über das Linux Networking-Plug-In.
Der Agent kommuniziert bidirektional mit dem Azure OpenAI Service: Er sendet Ihre natürliche Sprachabfrage und sammelt Diagnosenachweise zur Analyse und empfängt strukturierte Diagnoseeinblicke im Austausch.
Der Diagnoseworkflow führt vier Schritte aus:
- Klassifizieren: Der Agent bestimmt die Problemkategorie (DNS, Konnektivität, Netzwerkrichtlinie, Dienstrouting oder Paketabbrüche), basierend auf Ihrer Beschreibung.
-
Sammeln von Nachweisen: Der Agent führt Diagnosebefehle für Ihren Cluster über den AKS MCP-Server aus, unter Verwendung
kubectl,ciliumund .hubbleJede Diagnosekategorie verwendet einen dedizierten Beweissammlungsworkflow, um die richtigen Daten automatisch zu sammeln. - Analysieren: Der Agent untersucht gesammelte Nachweise, um gesunde Signale von Anomalien zu trennen. Der Agent stützt alle Schlussfolgerungen auf die tatsächlichen Ausgaben von Befehlen, niemals auf Spekulationen.
- Bericht: Sie erhalten einen strukturierten Bericht, der Folgendes umfasst:
- Eine Zusammenfassung des Problems und seines Status
- Eine Nachweistabelle mit den einzelnen Überprüfungen, deren Ergebnis und ob sie bestanden oder fehlgeschlagen ist
- Analyse dessen, was funktioniert und was defekt ist
- Ursachenidentifikation mit spezifischen Nachweisen
- Genaue Befehle zum Beheben des Problems und Überprüfen des Fixs
Integrationen
Container Network Insights Agent arbeitet mit den AKS-Netzwerktools, die Sie bereits verwenden:
| Integration | Wie diese verwendet wird |
|---|---|
| AKS MCP-Server | Stellt die Ausführungsebene für Clustervorgänge bereit; leitet kubectl, cilium und hubble Befehle vom Agenten zum Cluster weiter. |
| kubectl | Abfragen von Pods, Diensten, Endpunkten, Knoten, Netzwerkrichtlinien und anderen Kubernetes-Ressourcen |
| Cilium | Analysiert CiliumNetworkPolicy, CiliumClusterWideNetworkPolicy und den Gesundheitszustand des CiliumAgent |
| Hubble | Beobachtet den Netzwerkverkehr zwischen Pods und identifizieren verworfenen Datenverkehr. |
| CoreDNS | Überprüft die Pod-Gesundheit, Dienstendpunkte, Konfiguration und Prometheus-Metriken. |
| Azure OpenAI | Unterstützt die Unterhaltungs-KI, die Ihre Fragen interpretiert und Diagnoseberichte generiert |
Tipp
Stellen Sie für den vollständigen Diagnosefeaturesatz, einschließlich Hubble-Flussanalyse und Cilium-Richtliniendiagnose, den Container Network Insights Agent auf einem AKS-Cluster mit Azure CNI bereit, das von Cilium und den Advanced Container Networking Services (ACNS) aktiviert wird.
Sicherheitsmodell und Einschränkungen
Interaktion des Agents mit Ihrem Cluster
Container Network Insights Agent sammelt Diagnosedaten aus Ihrem Cluster, um Einblicke, Berichte und empfohlene Aktionen zu generieren. Er führt Clustervorgänge über den AKS MCP-Server aus und verwendet ein dediziertes Kubernetes-Dienstkonto (container-networking-agent-reader) mit minimalen Berechtigungen für die Daten, die für die Diagnose benötigt werden.
Der Container Network Insights-Agent nimmt keine Änderungen an Ihrem Cluster vor. Es bietet Wartungsbefehle und Empfehlungen, aber Sie überprüfen und wenden sie selbst an.
Bereichseinschränkungen
Der Agent beantwortet nur Netzwerk- und Kubernetes-bezogene Fragen und beantwortet keine thematisch unpassenden Anfragen. Das System umfasst auch Schutz gegen Prompt-Injection, um Missbrauch zu verhindern.
Grenzwerte für Sitzungen und Unterhaltungen
| Begrenzung | Vorgabe | Hinweise |
|---|---|---|
| Chatkontextfenster | ~15 Handelsplattformen | Der Agent entfernt ältere Nachrichten aus dem Kontext. Beginnen Sie eine neue Unterhaltung für nicht verwandte Probleme. |
| Nachrichten pro Gespräch | 100 | Der Agent entfernt beim Erreichen dieses Grenzwerts automatisch ältere Nachrichten. |
| Unterhaltungen pro Benutzer | 20 | Das System bereinigt am wenigsten kürzlich verwendete Unterhaltungen bei 90% Kapazität. |
| Leerlaufzeitüberschreitung bei Sitzung | 30 Minuten | Sitzungen laufen nach 30 Minuten Inaktivität ab |
| Absolutes Timeout der Sitzung | 8 Stunden | Sitzungen laufen nach 8 Stunden ab, unabhängig von der Aktivität |
Konkurrenz
Container Network Insights Agent unterstützt 1 bis 7 gleichzeitige Benutzer unter typischen Bedingungen. Die Paketablagediagnose auf größeren Clustern (25+ Knoten) erfordert möglicherweise das Einschränken gleichzeitiger Benutzer, um die Auslastung des API-Servers zu vermeiden. Ausführliche Informationen finden Sie unter "Skalierungsleitfaden".
Beispielszenarien und Beispielaufforderungen
DNS-Problembehandlung
DNS-Auflösungsfehler sind eines der häufigsten Netzwerkprobleme in Kubernetes. Wenn Pods keine Dienstnamen, externen Domänen oder beides auflösen können, führt der Container Network Insights Agent eine umfassende DNS-Diagnose aus, die den CoreDNS-Status, die Konfiguration, die DNS-Auflösung auf mehreren Pfaden überprüft und Netzwerkrichtlinien, die den DNS-Datenverkehr blockieren könnten.
Häufige Situationen:
- Pods-Protokoll
Name or service not known- oderNXDOMAIN-Fehler - Timeout für Anwendungen beim Erreichen von Diensten nach Namen
- DNS funktioniert für einige Pods, aber nicht für andere
- Die externe Domänenauflösung schlägt fehl, während die interne funktioniert (oder umgekehrt).
Beispielaufforderungen:
| Was Sie sehen | Prompt |
|---|---|
| DNS vollständig beschädigt | "Das gesamte DNS-System ist im Cluster ausgefallen" |
| Pod kann Namen nicht auflösen |
"Ein Pod im Namespace my-app kann keine DNS-Namen auflösen" |
| Spezifischer Name kann nicht aufgelöst werden |
"DNS-Auflösung für backend.default.svc.cluster.local schlägt fehl" |
| Zeitweilige DNS-Fehler |
"Pods in production haben sporadische DNS-Fehler" |
| Externes DNS blockiert | Externes DNS schlägt für Pods in my-namespace fehl |
| NodeLocal DNS-Probleme | "Können Sie überprüfen, ob NodeLocal DNS funktioniert?" |
Was der Agent überprüft:
Die DNS-Diagnose überprüft den CoreDNS-Podstatus, Dienstendpunkte und die CoreDNS-Konfiguration, einschließlich benutzerdefinierter ConfigMaps. Außerdem wird die DNS-Auflösung über mehrere Pfade hinweg getestet: same-namespace, cross-namespace, FQDN und extern. Der Agent wertet CoreDNS Prometheus-Metriken und Netzwerkrichtlinienregeln aus, einschließlich Cilium toFQDN-Ausgangsrichtlinien, die möglicherweise stillschweigend die Auflösung externer Domänen einschränken.
Beispiel für die Ursachen, die der Agent identifiziert:
- CoreDNS-Pods werden nicht ausgeführt oder sind nicht bereit
- Benutzerdefinierte CoreDNS ConfigMap mit falsch konfigurierten Neu- oder Weiterleitungsregeln
- Netzwerkrichtlinien blockieren UDP/TCP-Port 53 (DNS-Datenverkehr)
- Cilium toFQDNs-Richtlinie enthält eine erforderliche Domäne nicht in ihrer Erlaubnisliste
- NodeLocal DNS DaemonSet ohne Cilium LocalRedirectPolicy bereitgestellt
- Anwendung, die mit dem falschen Dienst-DNS-Namen konfiguriert ist
Problembehandlung bei RX/Paketverlust
Paketabbrüche sind schwierig zu diagnostizieren, da sie auf mehreren Ebenen auftreten können: NIC-Hardware, Kernelnetzwerkstapel oder Anwendungssocketpuffer. Der Container Network Insights-Agent stellt für jeden Knoten einen einfachen Debug-Pod bereit, um Netzwerkstatistiken auf Hostebene zu sammeln. Anschließend werden Deltamessungen verwendet, um zu ermitteln, wo Pakete verloren gehen.
Häufige Situationen:
- Anwendungen melden zeitweilige Verbindungsabbrüche oder Timeouts
- Werkzeuge wie
iperfzeigen Paketverluste zwischen Knoten an - Netzwerklatenzspitzen werden auf bestimmten Knoten angezeigt
- Hohe CPU-Auslastung korreliert mit der Netzwerkverarbeitung
-
ethtool -Szeigt inkrementierende RX-Verwerfungszähler an
Beispielaufforderungen:
| Was Sie sehen | Prompt |
|---|---|
| Tropfen auf einen bestimmten Knoten |
"Ich sehe Paketverluste auf Knoten aks-nodepool1-12345678-vmss000000" |
| Latenzspitzen | "Meine Anwendung erlebt intermittierende Latenzspitzen" |
| Clusterweite Leistungsprobleme | "Die Netzwerkleistung wird clusterweit beeinträchtigt" |
| Paketverlust erkannt | "Ich sehe Paketabbrüche und hohe Latenz. Die Iperf-Tests zeigen erhebliche Paketverluste." |
| Proaktiver Gesundheitscheck |
"Netzwerkintegrität auf Knoten my-nodeüberprüfen" |
Was der Agent überprüft:
Die Paketablagediagnose untersucht die NIC-Ringpufferauslastung (ethtool), Kernel-Softnet-Statistiken (/proc/net/softnet_stat), die per-CPU-SoftIRQ-Verteilung und die Socketpuffersättigung. Außerdem werden die Netzwerkschnittstellenstatistiken (/proc/net/dev), Kernelpuffer-Tunables (tcp_rmem, rmem_max, netdev_max_backlog), die RPS/XPS/RFS-Konfiguration sowie die CNI-spezifische Schnittstellenanalyse überprüft. Der Agent verwendet Delta-Messungen (Vorher-Nachher-Schnappschüsse), um aktive Datenverluste im Vergleich zu historischen Zählern zu erkennen.
Beispiel für die Ursachen, die der Agent identifiziert:
- Erschöpfung des NIC-Ringpuffers: aktive
rx_droppedZähler erhöhen sich - Kernel-Paketverluste: Nicht-Null-Werte in
/proc/net/softnet_statVerlustspalte - Socketpufferüberlauf: Socket-Empfangswarteschlange, die über Puffergrenzen hinausgeht
- SoftIRQ CPU-Engpass: hoch
%softauf einer einzelnen CPU mit ungleichgewichtiger Interruptverteilung - Alle Überprüfungen sind erfolgreich: Der Agent meldet "Kein Problem erkannt" anstelle von Vermutungen.
Von Bedeutung
Die Diagnose des Paketverlusts stellt ein Debug-DaemonSet (rx-troubleshooting-debug) im kube-system-Namespace Ihres Clusters bereit. Dieses DaemonSet erfordert hostNetwork, hostPID, hostIPCund NET_ADMIN Funktionen für den Zugriff auf Netzwerkdaten auf Hostebene. Er wird als Nicht-Stammbenutzer mit einem schreibgeschützten Stammdateisystem ausgeführt. Sie wird über Diagnosesitzungen hinweg geteilt und automatisch bereinigt, kann jedoch beibehalten werden, wenn der Agent-Pod unerwartet abstürzt. Informationen zur Bereinigung finden Sie unter "Bekannte Probleme ".
Problembehandlung bei Kubernetes-Netzwerken
Wenn Pods nicht mit Diensten kommunizieren können, Netzwerkrichtlinien den erwarteten Datenverkehr blockieren oder Dienste keine Endpunkte haben, untersucht der Container Network Insights-Agent den vollständigen Netzwerkpfad. Der Agent überprüft die Planung und Bereitschaft des Pods, die Registrierung des Dienstendpunkts, die Auswertung der Netzwerkrichtlinien und die Hubble-Flussbeobachtung.
Häufige Situationen:
- Pod-zu-Pod- oder Pod-zu-Service-Kommunikation schlägt fehl
- Dienste sind von bestimmten Namespaces nicht erreichbar
- Netzwerkrichtlinien blockieren unerwartet Datenverkehr
- Dienstendpunkte sind vorhanden, aber Verbindungen sind immer noch timeout
- Hubble zeigt
DROPPEDdas Urteil über Datenflüsse zwischen Pods
Beispielaufforderungen:
| Was Sie sehen | Prompt |
|---|---|
| Dienst nicht erreichbar | "Mein Client-Pod kann keine Verbindung mit dem Back-End-Dienst herstellen in production. Die Verbindung wird durch Zeitüberschreitung unterbrochen. |
| Datenverkehr blockiert | "Mein Client-Pod kann den Back-End-Dienst nicht mehr erreichen. Es funktionierte vorher." |
| Keine Endpunkte |
"Der Dienst hat keine Endpunkte im Namespace my-app" |
| Pod hängen geblieben | "Ich habe meine App bereitgestellt, aber der Dienst hat keine Endpunkte, und der Pod hat keine IP" |
| Pods nicht einsatzbereit |
"Pods sind im Namespace stagingnicht bereit" |
| Proaktiver Gesundheitscheck |
"Alles sieht im Namespace production einwandfrei aus – können Sie überprüfen?" |
Was der Agent überprüft:
Die Kubernetes-Netzwerkdiagnose untersucht den Pod-Status und die Planung, Dienstkonfiguration und Endpunktregistrierung sowie Netzwerkrichtlinien (sowohl Kubernetes NetworkPolicy als auch CiliumNetworkPolicy). Außerdem analysiert es die Hubble-Datenströme, einschließlich des verworfenen Datenverkehrs und der Zuordnung von Diensten zu Pod-Ports. Eine häufige Fehlkonfiguration, die der Agent erfasst, ist ein Dienst targetPort , der nicht mit dem Pod containerPortübereinstimmt. Dieses Missverhältnis führt dazu, dass Verbindungstimeouts auftreten, obwohl die Endpunkte als gesund erscheinen.
Beispiel für die Ursachen, die der Agent identifiziert:
- Netzwerkrichtlinie (oder CiliumNetworkPolicy), die den Ingress-Datenverkehr oder Egress-Datenverkehr blockiert
- Der Dienst
targetPortstimmt nicht mit dem PodcontainerPortüberein. - Dienstselektor-Labels stimmen mit keinen Pod-Labels überein (leere Endpunkte)
- Pod steckt aufgrund nicht planbarer Ressourcenanforderungen im Status "Pending" fest.
- Fehler bei der Readiness-Probe, sodass Pods von Dienstendpunkten ausgeschlossen werden.
- Cilium-Agent-Pods nicht gesund
Hinweis
Für die Hubble-Flussanalyse (hubble observe) ist die Aktivierung von Advanced Container Networking Services (ACNS) auf Ihrem Cluster erforderlich. Auf Clustern ohne ACNS bietet der Container Network Insights-Agent weiterhin vollständige Diagnosen mithilfe von kubectl und standardmäßigen Kubernetes-Ressourcen, aber die Flussdatensichtbarkeit ist nicht gegeben.
Bekannte Probleme und Produktbeschränkungen
Skalierungsleitfaden
| Clustergröße | Empfohlene gleichzeitige Nutzer | Hinweise |
|---|---|---|
| 1–3 Knoten | Bis zu 7 | Optimal für die meisten Diagnosen |
| 25 Knoten | Bis zu 3 | Paketverlust-Diagnosen erzeugen Beweispakete pro Knoten. |
| 50 Knoten | 1 | Große Datenbündel nähern sich den Kontextgrenzen von KI-Modellen. |
Die erste Abfrage eines neuen Benutzers kann länger dauern, wenn alle Agents im vorgewärmten Pool (Standard: drei Agents) verwendet werden. Nachfolgende Abfragen aus derselben Sitzung verwenden den bereits initialisierten Agent.
Bekannte Probleme
| Thema | Beschreibung | Workaround |
|---|---|---|
| Debug DaemonSet bleibt nach dem Absturz erhalten | Wenn der Container Network Insights Agenten-Pod während einer Paketverlustanalyse abstürzt, kann das rx-troubleshooting-debug DaemonSet möglicherweise in kube-system verbleiben. |
Führen Sie kubectl delete ds rx-troubleshooting-debug -n kube-system aus. |
| Die erste Paketverlustdiagnose ist langsamer. | Das Debug DaemonSet benötigt 30 bis 60 Sekunden, um geplant und bei der ersten Nutzung einsatzbereit zu sein. | Nachfolgende Diagnosen verwenden vorhandene Pods wieder und sind schneller |
| Nicht-Cilium-Cluster haben reduzierte Diagnosemöglichkeiten | Die Cilium-Analyse der Richtlinien und die Beobachtung des Hubble-Flusses sind nicht verfügbar. | Agent stellt weiterhin vollständige DNS-, Paketverlust- und Standard-Kubernetes-Diagnose bereit. |
| ACNS-freie Cluster verfügen nicht über Hubble |
hubble observe Befehle schlagen bei Clustern ohne Advanced Container Networking Services fehl |
Aktivieren Sie ACNS oder verlassen Sie sich auf kubectl-basierte Diagnosen. |
| DNS-Tests, die von Agent-Pod ausgeführt werden | DNS-Auflösungstests werden über den Container Network Insights Agent-Pod ausgeführt, der möglicherweise eine andere DNS-Richtlinie aufweist als der betroffene Pod. | Agent notiert seine eigene DNS-Richtlinie in den Nachweisen für den Vergleich |
| Sitzungsdaten sind im Arbeitsspeicher | Sitzungsstatus (Chatverlauf, Agentzuweisungen) gehen verloren, wenn der Pod neu gestartet wird. | Melden Sie sich erneut an, um eine neue Sitzung zu starten; kein Gesprächsverlauf gespeichert. |
| Chatkontextfenster | Der Agent behält nur die letzten ~15 Interaktionen in seinem Arbeitskontext bei. | Bei nicht verwandten Problemen beginnen Sie eine neue Unterhaltung, um Kontextverwechslungen zu vermeiden |
Verfügbarkeit der Erweiterung
Bei der Bereitstellung als AKS-Erweiterung (microsoft.containernetworkingagent) ist der Container Network Insights Agent verfügbar in: centralus, eastus, eastus2, uksouth, westus2.
Preise
Container Network Insights Agent wird als Pod in Ihrem AKS-Cluster ausgeführt. Direkte Kosten umfassen:
- Azure OpenAI-Verwendung: Die Tokennutzung hängt von der Länge der Unterhaltung und der Diagnosekomplexität ab. Aktuelle Preise finden Sie unter Azure OpenAI-Preise.
- AKS-Node-Berechnung: Der Container Network Insights-Agent-Pod und (zur Diagnose von Paketverlusten) der Debug-DaemonSet verbrauchen Cluster-Compute-Ressourcen.
Container Network Insights Agent selbst hat keine separate Lizenzierungsgebühr während der öffentlichen Vorschau.
Zugreifen und Verwenden des Container Network Insights-Agents
Container Network Insights Agent ist ein browserbasierter Chatbot, der in Ihrem AKS-Cluster ausgeführt wird. Öffnen Sie nach der Bereitstellung die Anwendungs-URL in einem beliebigen modernen Browser, um eine Unterhaltung zu starten. Sie benötigen kein CLI-Tool auf Ihrer Arbeitsstation oder ein Portalblatt, um zu navigieren. Es ist eine eigenständige Chatschnittstelle, die für die Netzwerkdiagnose entwickelt wurde.
Anmelden
Wenn Sie die Container Network Insights Agent-URL zum ersten Mal öffnen, werden Sie von der Anwendung aufgefordert, sich anzumelden. Je nachdem, wie Ihr Administrator die Bereitstellung konfiguriert hat, melden Sie sich entweder mit einem einfachen Benutzernamen (Entwicklungsumgebungen) oder Ihren Microsoft Entra ID Anmeldeinformationen (Produktionsumgebungen) an.
Berechtigungen erteilen
Nach der Anmeldung werden Sie möglicherweise von der Anwendung aufgefordert, Berechtigungen zu erteilen. Überprüfen Sie die angeforderten Berechtigungen, und wählen Sie "Annehmen" aus, um den Vorgang fortzusetzen.
Chatschnittstelle
Nachdem Sie sich authentifiziert haben, gelangen Sie zur Chatoberfläche. Der Server verwaltet Ihre Sitzung, sodass Sie innerhalb des Sitzungs-Timeout-Fensters die Browserregisterkarte schließen und erneut öffnen können, ohne Ihre Unterhaltung zu verlieren.
Die Chatschnittstelle ist der Ort, an dem Sie:
- Stellen Sie Fragen in natürlicher Sprache: Geben Sie Eingabeaufforderungen wie "Warum kann mein Pod DNS nicht auflösen?" oder "Paketabbrüche auf Knoten aks-nodepool1-vmss000000" ein. Es ist keine spezielle Syntax erforderlich.
- Erhalten Sie strukturierte Diagnoseberichte: Antworten umfassen Nachweistabellen, Ursachenanalyse und Wartungsbefehle, die Sie kopieren und ausführen können.
- Neue Unterhaltungen starten: Jede Unterhaltung behält ihren eigenen Kontext bei. Wechseln Sie das Thema, indem Sie eine neue Unterhaltung starten.
- Feedback übermitteln: Verwenden Sie nach jeder Diagnoseantwort die integrierten Feedback-Steuerungselemente (Daumen nach oben und Daumen nach unten), um die Qualität der Diagnose zu bewerten. Ihr Feedback hilft, die zukünftige Diagnosegenauigkeit zu verbessern.
Melden von Problemen
Wenn ein Problem mit dem Container Network Insights-Agent auftritt:
- Beachten Sie die Sitzungs-ID und den Zeitstempel des Problems (sichtbar in der Chatschnittstelle)
- Überprüfen Sie die Integritätsendpunkte:
/health,/ready,/live - Überprüfen Sie die Pod-Protokolle:
kubectl logs -l app=container-networking-agent -n kube-system - Reichen Sie ein Problem über Ihren Standardkanal für Azure-Support ein