Diagnostizieren und Beheben von AKS-Netzwerkproblemen mit Advanced Container Networking Services

Dieser Leitfaden führt Sie durch die Diagnose und Behebung von Problemen mit realen Netzwerken in Azure Kubernetes Service (AKS) mithilfe von Advanced Container Networking Services (ACNS). Jedes Playbook beginnt mit einem Symptom (DNS-Fehler, Paketausfälle, Datenverkehrsungleichgewicht, L7-Fehler), zeigt Ihnen, welches Signal zuerst überprüft werden soll, und informiert Sie, wann Sie einen Drilldown in Protokolle durchführen müssen.

Der Leitfaden ist nach Aufgaben und nicht nach Funktionen organisiert. Lesen Sie das mentale Modell einmal, und springen Sie dann direkt zum Playbook, das Ihrem Symptom entspricht.

Was dieser Leitfaden ihnen hilft, zu lösen

• DNS-Auflösungsfehler in Pods (NXDOMAIN, SERVFAIL, fehlende Antworten).
• Paketverluste , die durch falsch konfigurierte Netzwerkrichtlinien, Verbindungsnachverfolgung oder Beeinträchtigung der Konnektivität verursacht werden.
• Ungleichgewicht beim Datenverkehr zwischen Pods oder Namespaces (heiße Pods, ungleichmäßige Auslastungsverteilung).
• L7-Anwendungsfehler (HTTP 4xx/5xx, gRPC-Fehler, Kafka-Tropfen).
• Clusterweite Netzwerkintegritätsüberwachung und Kapazitätsplanung.
• Steuerung der Observabilitätskosten durch gezielte Erfassung von Metriken und Logs.

Mentales Modell: Zusammenpassen von Metriken, Protokollen und Filtern

ACNS gibt Ihnen drei Signale. Jede antwortt auf eine andere Frage.

Eine tiefergehende Funktionsreferenz finden Sie unter Containernetzwerkmetriken, Containernetzwerkprotokolle und Konfigurieren der Metrikfilterung.

Standard-Problembehandlungsfluss

Verwenden Sie diese Vorgehensweise für alle Netzwerkvorfälle:

1. Beginnen Sie bei den Metrik-Dashboards. Bestätigen Sie die Anomalie: eine Spitze bei Abbrüchen, Fehlern, TCP-Resets oder DNS-Fehlern. Identifizieren Sie den betroffenen Knoten, Namespace oder Workload.
2. Wechseln zu gespeicherten Protokollen. Filtern Sie die ContainerNetworkLogs Tabelle nach dem Namespace und dem Zeitfenster aus Schritt 1. Protokolle informieren Sie über das Urteil, den Drop-Grund, die Quell-/Zielarbeitslasten und L7-Statuscodes, die von Metriken nicht übertragen werden.
3. Wiedergabe live mit Protokollen bei Bedarf. Wenn das Problem zeitweise oder bereits in gespeicherten Daten behoben wurde, verwenden Sie die Hubble CLI- oder Hubble-Benutzeroberfläche, um Liveflüsse für diese Workload zu erfassen.
4. Validieren Sie die Lösung. Überprüfen Sie denselben Metrikbereich erneut, und führen Sie dieselbe KQL-Abfrage erneut aus. Die Anomalie sollte weg sein.
5. Optimieren sie die Sammlung. Wenn Sie während des Vorfalls zu viel gesammelt haben, schränken Sie Ihre ContainerNetworkLog CRD ein oder wenden Sie einen ContainerNetworkMetric Filter an, damit Sie künftig nur das erfassen, was Sie benötigen.

Integrierte Dashboards auf einen Blick

Richten Sie diese einmal ein, indem Sie die Beobachtbarkeit des Containernetzwerks einrichten. Sie beziehen sich in allen Playbooks darauf.

Leitfaden 1: Diagnose von DNS-Auflösungsfehlern

Symptom. Pods protokollieren Fehler wie DNS_PROBE_FINISHED_NXDOMAIN, SERVFAIL oder hängen beim Auflösen von Dienstnamen.

Ziel. Ermitteln Sie, ob der Fehler upstream (CoreDNS oder externer Resolver), richtliniengesteuert (FQDN-Verweigerung) oder workloadspezifisch ist.

Schritt 1: Bestätigen der Anomalie in DNS-Metriken

Öffnen Sie das DNS-Dashboard (Cluster). Suchen Sie nach plötzlichen Änderungen des Anforderungsvolumens, des Antwortvolumens oder der Anfragen ohne Antwort %. Die Zusammenfassungspanels enthalten die am häufigsten verwendeten Abfragen, die am häufigsten verwendeten Antwortcodes und die Knoten, die die meisten Fehler generieren.

Wonach sie suchen sollten: Eine anhaltende Zunahme der Fehlerantworten, ein Rückgang der erfolgreichen Antworten oder ein einzelner Knoten, der die Fehleranzahl dominiert. Notieren Sie sich den Zeitstempel der Anomalie.

Schritt 2: Identifizieren der lautesten Pods

Scrollen Sie im selben Dashboard nach unten zum Panel, das Pods nach DNS-Fehlern in allen Namespaces bewertet. Die wichtigsten Einträge sind Ihre Anfangsverdächtigen.

Entscheidungspunkt.

• Wenn Fehler in CoreDNS-Pods konzentriert sind, springen Sie zum DNS-Dashboard (Workload), indem Sie kube-system / coredns auswählen – entweder ist CoreDNS selbst oder deren Upstream-Resolver das Problem.
• Wenn Fehler in einer Anwendungsworkload konzentriert sind, generiert diese Workload fehlerhafte Abfragen oder wird von einer FQDN-Richtlinie verweigert.

Schritt 3: Untersuchen Sie die betroffene Arbeitslast

Öffnen Sie das DNS-Dashboard (Workload) für die von Ihnen identifizierte Workload.

• DNS-Anforderungen/DNS-Antwortbereiche. Eine hohe Anfragen mit fehlender Antwort % weist auf upstream-Zeitüberschreitungen oder Abfrageüberlastung hin.

  

• DNS-Fehler nach Typ. Zuordnen der Spitzen zu einem Code:

  • NXDOMAIN – falscher oder veralteter Domänenname in der App-Konfiguration.
  • SERVFAIL — Problem mit dem Upstream-Resolver.
  • Abfrage verweigert – FQDN-Richtlinie oder DNS-Konfiguration stimmt nicht überein.

  

• Zurückgegebene DNS-Antwort-IPs. Bestätigt die Erfolgsquote bei Problemlösungen. Ein Drop bedeutet in der Regel, dass CoreDNS nicht nach oben gelangen kann; ein plötzlicher Anstieg kann auf einen Abfragesturm hinweisen.

• DNS-Antworttabelle. Verwenden Sie dies, um Muster wie "A records fail but AAAA records succeed" zu erkennen, die in der Regel auf einen Stapel zeigen, der für IPv4-Umgebungen falsch konfiguriert ist.

  

Schritt 4: Bestätigen mit gespeicherten Protokollen

Führen Sie diese KQL-Abfrage in Ihrem Log Analytics Arbeitsbereich aus, um DNS-Fehlermuster anzuzeigen. Aggregierte Zeilen bleiben erhalten Verdict, Namespaces, Workloads und Layer7.dns.rcode, sodass diese Abfrage mit der Standardtabelle (aggregiert) ContainerNetworkLogs funktioniert:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L4 = parse_json(Layer4), L7 = parse_json(Layer7)
| where L4.UDP.destination_port == 53
| where Reply == true
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name),
         DnsRcode    = tostring(L7.dns.rcode)
| where DnsRcode != "NOERROR"
| summarize ResponseCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DnsRcode, Verdict
| order by ResponseCount desc

Ersetzen Sie <start-time> und <end-time> durch Zeitstempel im Format 2026-04-30T15:00:00Z.

Was sie in die Ergebnisse einchecken sollten:

• Urteil. DROPPED bedeutet, dass eine FQDN- oder Netzwerkrichtlinie die Abfrage blockiert. FORWARDED mit einem nicht-NOERRORDnsRcode (z. B. NXDOMAIN, SERVFAIL) bedeutet, dass der Upstream-Resolver einen Fehler zurückgegeben hat.
• Quell-/Zielarbeitslasten. Bestätigen Sie, dass der Datenverkehr zum erwarteten CoreDNS-Dienst geht.
• DnsRcode. Der DNS-Antwortcode identifiziert den Fehlermodus auf einen Blick.

Sie können auch die gleichen Datenflüsse im Azure portal unter AKS cluster>Insights>Networking>Flow Logs visualisieren.

Schritt 5: Live reproduzieren, wenn das Problem intermittierend auftritt

Wenn die Spitzen bereits bestanden haben und sie nicht in gespeicherten Protokollen erfassen können, verwenden Sie die Hubble CLI bei Bedarf:

hubble observe --namespace <ns> --port 53 --type l7 --follow

Schritt 6: Korrektur überprüfen

Nachdem Sie die FQDN-Richtlinie aktualisiert, die Anwendungskonfiguration behoben oder CoreDNS skaliert haben, öffnen Sie das DNS-Dashboard (Workload) erneut. Die Fehlerrate sollte innerhalb einer oder zwei Minuten fallen. Führen Sie die KQL-Abfrage für dasselbe Zeitfenster erneut aus, um zu bestätigen, dass die fehlerhaften Abfragen nicht mehr vorhanden sind.

Playbook 2: Untersuchung von Paketverlusten

Symptom. Dienste können sich nicht gegenseitig erreichen. Proben schlagen fehl. Zeitüberschreitungen bei Verbindungen. Drop-Counter steigen in Dashboards.

Ziel. Ermitteln Sie, ob Ausfalle durch Netzwerkrichtlinien, Verbindungsnachverfolgungs-Erschöpfung oder Upstreamverbindungsprobleme verursacht werden – und welche Workload verantwortlich ist.

Schritt 1: Suchen der Tropfen auf Namespaceebene

Öffnen Sie Pod Flows (Namespace). Die Heatmaps zeigen Namespaces und Pods mit den höchsten ausgehenden und eingehenden Drop-Raten an.

Hellere Zellen deuten auf höhere Dropraten hin. Beachten Sie den Namespace und das Zeitfenster.

Schritt 2: Detaillierte Analyse der betroffenen Arbeitslast

Öffnen Sie Drops (Workload) und wählen Sie die von Ihnen identifizierte Workload aus.

• Die Workload-Momentaufnahme zeigt max/min ausgehende Verluste in Paketen pro Sekunde. Verwenden Sie sie, um den Schweregrad zu bewerten.

  

• Verworfener Datenverkehr nach Grund ist das wichtigste Panel. Der Grund teilt Ihnen mit, was Sie beheben müssen:

  • Richtlinienverweigerung – eine NetworkPolicy oder CiliumNetworkPolicy blockiert den Datenverkehr.
  • CT: Karteneinfügungsfehler – Die Verbindungsnachverfolgungstabelle ist voll; Knoten skalieren oder Verbindungswechsel reduzieren.
  • Nicht unterstütztes L3-Protokoll /Ungültiges Paket – Anwendung oder Proxy sendet falsch formatierten Datenverkehr.

  

• Heatmap von eingehenden/ausgehenden Datenübertragungen. Gibt an, welche bestimmten Pod-Paare Datenverkehr verlieren.

  

• Gestapelte Total-Tropfen nach Source Pod. Ordnen Sie die Täter an, damit Sie wissen, welches Replikat zuerst betrachtet werden soll.

  

Schritt 3: Überprüfen der verworfenen Datenflüsse in gespeicherten Protokollen

Suchen Sie die genauen Quell- und Zielarbeitslasten des verworfenen Datenverkehrs. Verdict, DropReason, Namespaces, und Workloads befinden sich alle im Aggregationsschlüssel, sodass diese Abfrage auf aggregierten Daten funktioniert.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload, DestinationNamespace, DstWorkload, DropReason, bin(TimeGenerated, 5m)
| order by TimeGenerated desc, DropCount desc

Beschränken Sie sich auf einen Namespace, sobald Sie ihn identifiziert haben.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where Verdict == "DROPPED"
| where SourceNamespace == "<namespace-name>"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| summarize DropCount = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DestinationNamespace, DstWorkload, DropReason, TrafficDirection
| order by DropCount desc

Das Dashboard Flow Logs im Azure-Portal zeigt die gleichen Daten visuell an, einschließlich eines Dienstabhängigkeitsdiagramms, das blockierte Pfade hervorhebung.

Schritt 4: Kreuzüberprüfung mit Richtlinien

Sobald Sie den Quell-Pod und den Ziel-Pod kennen:

kubectl get netpol,cnp -A
kubectl describe cnp -n <namespace> <policy-name>

Vergleichen Sie den fehlgeschlagenen Datenfluss mit den Eingangs-/Ausgangsnetzwerkregeln. Die häufigste Ursache ist eine Standard-Ablehnungsrichtlinie, die ohne eine Zulassungsregel für einen legitimen Pfad erstellt wird.

Schritt 5: Überprüfen der Behebung

Nach dem Anpassen der Richtlinie sollte das Dropped Traffic by Reason Diagramm für Richtlinienverweigerung stabil bleiben. Führen Sie die KQL-Abfrage erneut aus – DROPPED Die Bewertungen für dieses Quell-/Zielpaar sollten nicht mehr angezeigt werden.

Playbook 3: Suchen von Verkehrsungleichgewichten und heißen Pods

Symptom. Einige Pods einer Bereitstellung nutzen die CPU oder das Netzwerk vollständig aus, während andere im Leerlauf sind. TCP setzt Aufsteigen zurück. Latenzberichte stammen von Benutzern (Latenz selbst ist in ACNS-Metriken nicht sichtbar – siehe Hinweis im mentalen Modell).

Ziel. Ermitteln Sie, welche Pods unnötigen Datenverkehr tragen und ob Resets eine Überlastung oder falsch konfiguriertes Load Balancing anzeigen.

Schritt 1: Vergleichen des Datenverkehrs auf Podebene

Öffnen Sie Pod Flows (Workload). Die Workload-Momentaufnahme fasst ausgehenden/eingehenden Datenverkehr zusammen und bricht ab.

Im Panel "Datenverkehr nach Trace-Typ" wird die Form des Datenverkehrs im Laufe der Zeit angezeigt. Eine breite Lücke zwischen ausgehendem und eingehendem Volumen verweist häufig auf einen nachgelagerten Engpass.

Schritt 2: Erkennen Sie heiße Pods mit Heatmaps

Die Pod-Level-Heatmaps machen Ungleichgewichte deutlich. Wenn ein Pod (z. B. default/tcp-client-0) sowohl in den ausgehenden als auch in den eingehenden Heatmaps mit viel dunkleren Zellen als seine Replikate erscheint, konzentriert sich der Datenverkehr dort.

Häufige Ursachen:

• Service sessionAffinity: ClientIP pinnt Clients an einen Pod.
• Headless Dienst mit bindender DNS-Auflösung.
• Hashing von externen Load Balancer auf einem Feld mit niedriger Kardinalität.

Schritt 3: Verwenden von TCP-Resets als Sättigungssignal

Öffnen Sie die TCP-Reset-Metrik-Panels.

• Heatmap der ausgehenden TCP-RSTs nach Quell-Pod. Ein Hot Source-Pod, der auch RSTs generiert, wird überladen – die Anwendung schließt Verbindungen aggressiv.

  

• Heatmap der eingehenden TCP-RST nach Ziel-Pod. Ein Pod, der RSTs aus vielen Quellen empfängt, weist in der Regel darauf hin, dass neue Verbindungen nicht schnell genug akzeptiert werden können (Backlog voll, Listener langsam).

  

• Gestapelte Gesamt-RST nach Quelle/Ziel. Trends im Laufe der Zeit informieren Sie, ob Resets ein Ereignis oder ein neuer stabiler Zustand sind.

Schritt 4: Bestätigen mit Protokollen

Identifizieren Sie die arbeitsreichsten Arbeitslasten nach Gesamtflussvolumen. Verwenden Sie die Spalten für die aggregierte Flussanzahl statt count(), die nur aggregierte Zeilen und nicht die zugrunde liegenden Flüsse zählt.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend SrcWorkload = tostring(SourceWorkloads[0].name)
| summarize TotalFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SourceNamespace, SrcWorkload
| top 10 by TotalFlows desc

Schritt 5: Überprüfen der Korrektur

Nach der Skalierung der Workload, der Neubalancierung des Dienstes oder der Behebung von Affinitätsproblemen sollte die Heatmap gleichmäßiger über mehr Pods aufhellen, und die TCP-RST-Rate sollte sinken.

Playbook 4: Überwachen der clusterweiten Netzwerkgesundheit

Verwenden Sie diese, wenn Sie eine Flottenübersicht benötigen: Kapazitätsplanung, Bereitschafts-Dashboards oder einen schnellen Gesundheitscheck über viele Cluster hinweg.

Öffnen Sie Kubernetes / Networking / Cluster.

Signale zu beobachten und was sie bedeuten:

Wenn etwas auf diesem Dashboard falsch aussieht, springen Sie zum passenden Playbook (Playbook 1 für DNS, Playbook 2 für Tropfen, Playbook 3 für hot pods).

Playbook 5: Diagnostizieren von Anwendungsschichtfehlern (L7)

Symptom. HTTP 4xx/5xx Fehlerraten steigen. gRPC-Aufrufe schlagen fehl. Kafka-Verbraucher liegen zurück. Verfügbar auf Cilium-Cluster mit der aktivierten L7-Richtlinienerzwingung und einem CiliumNetworkPolicy mit L7-Regeln — siehe Konfigurieren einer Layer 7-Richtlinie.

Ziel. Ermitteln Sie, ob L7-Fehler von falsch konfigurierten Clients, serverseitigen Fehlern oder verweigerten Flüssen stammen.

Schritt 1: Öffnen des L7-Dashboards

Verwenden Sie Kubernetes / Networking / L7 (Workload) für einen einzelnen Dienst oder L7 (Namespace) für einen ganzen Mandanten.

Schritt 2: Trennen von abgelegten und weitergeleiteten HTTP-Datenverkehr

Im Entscheidungsausschuss wird der HTTP-Traffic in weitergeleitete und verworfene Datenströme aufgeteilt. Ein Anstieg an abgelehntem HTTP bedeutet in der Regel, dass eine CiliumNetworkPolicy die Anforderung auf L7-Ebene verweigert (z. B. indem sie einen Pfad oder eine Methode blockiert).

Schritt 3: Nachverfolgen von Statuscodes im Laufe der Zeit

Der Statuscodebereich gibt an, ob Fehler clientseitig oder serverseitig sind. Ein Anstieg von 4xx weist auf schlechte Eingaben, abgelaufene Token oder verweigerte Pfade hin. Ein Anstieg von 5xx Punkten bei Back-End-Fehlern.

Schritt 4: Suchen der problematischen Pods

In der 4xx-Heatmap wird angezeigt, welche Quell-Pods die meisten fehlgeschlagenen Anfragen generieren. Ein einzelner Pod, der hell leuchtet, bedeutet in der Regel eine hängen gebliebene Client-Wiederholungsschleife oder ein falsch konfiguriertes Replikat.

Schritt 5: Bestätigen mit KQL

Abrufen des HTTP-Datenverkehrs aufgeschlüsselt nach Statuscode. Layer7.http.code ist Teil des Aggregationsschlüssels, sodass dies für aggregierte Zeilen funktioniert:

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| extend L7 = parse_json(Layer7)
| where isnotnull(L7.http)
| extend StatusCode  = tostring(L7.http.code),
         SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where StatusCode startswith "4" or StatusCode startswith "5"
| summarize ErrorFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount),
            UniqueCodes = dcount(StatusCode)
    by SrcWorkload, DstWorkload, StatusCode
| order by ErrorFlows desc

Für gRPC und Kafka trägt die protokollspezifische Nutzlast, Layer7 aber nur http.code und dns.rcode sind Aggregationsschlüssel. Filtern Sie nach Verdict und der Workload-Identität und verwenden Sie On-Demand-Protokolle, wenn Sie die gRPC-Methode oder das Kafka-Thema benötigen.

ContainerNetworkLogs
| where TimeGenerated between (datetime(<start-time>) .. datetime(<end-time>))
| where FlowType == "L7"
| extend SrcWorkload = tostring(SourceWorkloads[0].name),
         DstWorkload = tostring(DestinationWorkloads[0].name)
| where Verdict == "DROPPED"
| summarize DroppedFlows = sum(IngressFlowCount + EgressFlowCount + UnknownDirectionFlowCount)
    by SrcWorkload, DstWorkload
| order by DroppedFlows desc

Worauf man sich bei L7 RCA konzentrieren sollte

• Datenverkehrsvolumen und -form. Verwenden Sie Heatmaps, um Ungleichgewichte zu finden; Ein überlastetes Replikat ist häufig die Ursache für die Fehlerrate.
• Statuscode-Trend. 4xx vs 5xx schränkt die Untersuchung auf den Client oder die Serverseite ein.
• Fazit.Verworfen L7-Datenflüsse bedeuten, dass eine L7-Richtlinie die Anforderung ablehnt – lesen Sie die Richtlinie und bestätigen Sie die Absicht.

Feature-Detaillierte Analyse (wann welches verwendet werden soll)

Verwenden Sie diesen Abschnitt als Kurzübersicht, sobald Sie die Playbooks kennen.

Containernetzwerkmetriken

• Wird für: Anomalieerkennung, Dashboards, Warnungen, Kapazitätsplanung.
• Überspringen für: die Hauptursache, die eine Identität benötigt (welcher Pod, welcher Pfad, welches Urteil).
• Granularität: Knotenebene auf allen Datenebenen; Pod-Level unter Linux.
• Kostensensitive Workloads: Wenden Sie Metrikfilterung auf Cilium-Cluster an, um nur die Namespaces, Bezeichnungen und Metriktypen beizubehalten, die Ihnen wichtig sind. Filterung geschieht vor Scrape, so dass unerwünschte Serie nie Prometheus erreicht.

Containernetzwerkprotokolle (gespeichert)

• Verwendung für: Ursachenanalyse, historische Trends, Compliance/Audit.

• Datenebene:Nur Cilium. Gespeicherte Protokolle sind für Nicht-Cilium-Cluster nicht verfügbar.

• Obligatorischer Schritt: Definieren Sie eine ContainerNetworkLog CRD, die den gewünschten Datenverkehr auswählt. Ohne dies werden keine Protokolle gesammelt. Siehe Einrichten von Containernetzwerkprotokollen.

• Wenn Protokolle landen: Standardmäßig schreibt Cilium Flusseinträge /var/log/acns/hubble/events.log auf jeden Knoten (50 MB gedrehten Puffer). Von dort aus haben Sie zwei Speicherpfade:

  • Azure Log Analytics (verwaltet, empfohlen) – Container Insights sendet Logs in die Tabelle ContainerNetworkLogs für KQL-Abfragen und integrierte Azure Portal-Dashboards.
  • Bring your own collector - richten Sie einen OpenTelemetry-kompatiblen Agenten (Splunk, Datadog, Elastic, jeden OTel-Collector) auf den Host-Protokollpfad, um Datenströme in Ihren bestehenden Observability-Stack weiterzuleiten, anstelle von oder zusätzlich zu Log Analytics.

• Kostenkontrolle: Die Aggregation von Flussprotokollen fasst ähnliche Datenströme in einem 30-Sekunden-Zeitraum zusammen und bewahrt Muster, während das Volumen reduziert wird. Kombinieren Sie es mit schmalen includeFilters, um optimale Ergebnisse zu erzielen.

• Verwenden Sie die Dashboards Flow Logs - Analytics Tier oder Flow Logs - Basic Tier unter Azure>Insights>Containers>Networking.

  

  

Protokolle für Containernetzwerke (On-Demand)

• Verwendung für: Live-Vorfälle, zeitweilige Probleme, Ad-hoc-Untersuchung ohne Änderung der Sammlungskonfiguration.

• Datenebene:Nur Cilium.

• Werkzeuge: Hubble CLI für Terminalfilterung; Hubble UI für visuelle Dienst-zu-Dienst-Zuordnungen.

• Kein beständiger Speicher, keine zusätzlichen Kosten, kein Setup über die Aktivierung von ACNS hinaus.

  

Metrikfilterung (Cilium-Cluster)

Wenden Sie eine ContainerNetworkMetric CRD an, um zu steuern, welche Hubble-Metriken pro Knoten exportiert werden. Nützlich, wenn Sie eine umfassende Überwachbarkeit für einige kritische Namespaces benötigen, aber nicht für Flussserien mit hoher Kardinalität in allen Namespaces bezahlen möchten.

Häufige Muster:

• DNS- und Dropmetriken clusterweit beibehalten; Flussmetriken auf Produktiv-Namensräume beschränken.
• Schließen Sie systemeigene Namespaces mit hohem Aufkommen wie kube-system aus den Flussmetriken aus.
• Begrenze Mandanten-Namespaces auf jeweils eigene Filterblöcke.

Vollständige CRD-Beispiele finden Sie unter Konfigurieren der Filterung von Containernetzwerkmetriken.

Bewährte Methoden

• Beginnen Sie breit und dann schmal. Aktivieren Sie umfassende Protokolle/Metriken für ein paar Tage, überprüfen Sie die tatsächliche Nutzung und straffen Sie anschließend die ContainerNetworkLog und ContainerNetworkMetric Filter.
• Halten Sie metrik- und Log-Zeitfenster ausgerichtet. Wenn Sie einen Vorfall untersuchen, verwenden Sie die gleiche Start-/Endzeit über das Dashboard und die KQL-Abfrage, damit Signale sauber korrelieren.
• Bevorzugen Sie die vorinstallierten Dashboards. Sie behandeln die häufigsten Fragen. Benutzerdefinierte Panels werden in der Regel erst benötigt, nachdem Sie die anfängliche Triage abgeschlossen haben.
• Ebene ContainerNetworkLogs nach Bedarf. Wechseln Sie zur Stufe "Basic " für kostensensitive Arbeitslasten; verwenden Sie das entsprechende Basic-Tier-Dashboard. Siehe Log Analytics Tabellenpläne.
• Behandeln Sie aggregierte Protokolle und On-Demand-Protokolle als Ergänzungen. Aggregierte Protokolle eignen sich hervorragend für die Trend- und Mustererkennung, überspringen aber die Detaildetails pro Fluss. Verwenden Sie On-Demand (Hubble) für feinkörnige Inspektionen.
• Überprüfen Sie Korrekturen mit demselben Panel, in dem das Problem angezeigt wurde. Wenn dasselbe Panel nach der Änderung flach wird, haben Sie eine echte Lösung.

Häufige Fallstricke

• Vergiss die ContainerNetworkLog CRD. Durch das Aktivieren von Container-Netzwerkprotokollen im Cluster wird erst etwas erfasst, wenn Sie mindestens eine CRD anwenden, die den Datenverkehr auswählt.
• Sie versuchen, gespeicherte Protokolle für bereits vergangene Live-Vorfälle zu verwenden. Wenn Protokolle vor dem Vorfall nicht aktiviert waren oder außerhalb des erfassten Filters lagen, wechseln Sie für das nächste Ereignis zu bedarfsgesteuerten Hubble-Flüssen.
• L7-Dashboards leer auf einem Cilium-Cluster. L7-Metriken erfordern sowohl --acns-advanced-networkpolicies L7 auf dem Cluster als auch eine CiliumNetworkPolicy mit L7-Regeln. CCNP unterstützt keine L7-Regeln. Siehe Anwenden von L7-Richtlinien.
• DNS-Metriken sind auf Cilium leer. DNS-Sichtbarkeit erfordert eine CiliumNetworkPolicy mit einer dns-Regel, in der Regel zusammen mit toFQDNs. Der FQDN/DNS-Proxy ist nicht mit node-local DNS oder AKS Local DNS kompatibel . Die Ausführung deaktiviert entweder DNS-Proxying und die resultierenden Metriken. Siehe FQDN-Filterbeschränkungen.
• matchPattern: "*" blockiert alle DNS-Einträge. Ein bares Wildcard wird nicht unterstützt. Verwenden Sie ein Wildcard-Muster wie z. B. *.example.com oder app*.example.com. Siehe Anwenden von FQDN-Filterrichtlinien.

In Azure Monitoring enthaltene Netzwerkeinblicke

Wenn Sie den verwalteten Azure Monitor-Dienst für Prometheus auf einem AKS-Cluster aktivieren, werden standardmäßig grundlegende Metriken zur Netzwerküberwachung von Knoten über das Ziel networkobservabilityRetina erfasst. Dies bietet Folgendes:

• Grundlegende Netzwerkmetriken auf Knotenebene: Grundlegende Sichtbarkeit des Netzwerkdatenverkehrs auf Knotenebene
• Standardmäßige Prometheus-Ziele: Metriken für Netzwerkeinblicke, die von Azure Monitor automatisch verworfen werden
• Azure Monitor-Integration: Nahtlose Integration in Azure Monitor; Metriken werden automatisch erfasst und können in Grafana visualisiert werden.
• Kein zusätzliches Setup erforderlich: Automatisch aktiviert, wenn von Azure Monitor verwaltetes Prometheus konfiguriert ist
• Microsoft-Support: Unterstützt als Teil von Azure Monitor und AKS

Hinweis: Dies erfordert, dass der verwaltete Azure Monitor-Dienst für Prometheus auf Ihrem AKS-Cluster aktiviert ist, was möglicherweise Kosten verursacht hat.

Erste Schritte: Aktivieren Sie den verwalteten Azure Monitor-Dienst für Prometheus auf Ihrem AKS-Cluster über das Azure-Portal oder die CLI. Metriken zur Netzwerkbeobachtung werden automatisch gesammelt und für die Visualisierung in Azure Managed Grafana zur Verfügung gestellt.

Netzwerkeinblicke mit Retina OSS

Während erweiterte Container-Netzwerkdienste (ACNS) ein kostenpflichtiges Angebot ist, das umfassende Netzwerkeinblickfunktionen bereitstellt, unterstützt Microsoft auch die Netzwerkeinblicke mit Retina OSS, einer Open-Source-Netzwerkeinblick-Plattform, die wesentliche Netzwerküberwachungsfunktionen bereitstellt.

Retina OSS ist die Open-Source-Einblickplattform, die auf retina.sh und GitHub verfügbar ist. Sie bietet:

• eBPF-basierte Netzwerkbeobachtbarkeit: Verwendet eBPF-Technologien, um Erkenntnisse mit minimalem Aufwand zu sammeln
• Umfassende Datenverkehrsanalyse mit Kubernetes-Kontext: Umfassende Erfassung und Analyse von Netzwerkdatenverkehrsflüssen mit vollständiger Kubernetes-Integration
• Erweiterte Metriksammlung: Layer 4-Metriken, DNS-Metriken und verteilte Paketerfassungsfunktionen
• Plug-In-basierte Erweiterbarkeit: Anpassen und Erweitern der Funktionalität über eine Plug-In-Architektur
• Prometheus-kompatible Metriken: Exportieren umfassender Netzwerkmetriken im Prometheus-Format mit konfigurierbaren Metrikmodi
• Verteilte Paketerfassung: On-Demand-Paketerfassungen über mehrere Knoten hinweg, um umfassende Problembehandlung zu ermöglichen.
• Platform- and CNI-unabhängig: Kompatibel mit jedem Kubernetes-Cluster (AKS, Arc-fähig, lokal), jedem Betriebssystem (Linux/Windows) und jedem CNI.
• Community-Support: Open-Source mit communitygesteuertem Support und Beiträgen
• Selbstverwaltet: Vollständige Kontrolle über Bereitstellung und Konfiguration
• Hubble-Integration: Integration in Cilium Hubble für zusätzliche Netzwerkeinblicke

Erste Schritte: Bereitstellen von Retina OSS mithilfe von Helm-Diagrammen oder Kubernetes-Manifesten aus dem offiziellen Retina-Repository. Richten Sie Prometheus und Grafana ein, um Metriken zu visualisieren, umfassende Datenverkehrsanalyse mit Kubernetes-Kontext zu konfigurieren, verteilte Paketerfassung für erweiterte Problembehandlung zu aktivieren und Funktionen mithilfe der Plug-In-basierten Architektur für bestimmte Anwendungsfälle anzupassen.

Vergleich von Netzwerkeinblick-Angeboten

Weitere Informationen

Erweiterte Container-Netzwerkdienste (ACNS)

• Plattformübersicht:Was ist Advanced Container Networking Services für AKS?
• Einrichten der Beobachtbarkeit:Einrichten der Beobachtbarkeit des Containernetzwerks
• Containernetzwerkmetriken:Übersicht über Containernetzwerkmetriken
• Containernetzwerkprotokolle:Übersicht über Containernetzwerkprotokolle und Einrichten von Containernetzwerkprotokollen
• Metrikfilterung (Cilium):Konfigurieren der Filterung von Containernetzwerkmetriken

KI-gesteuerte Diagnose

• Container Network Insights Agent (Vorschau):Übersicht und Einrichten des Agents
• AKS MCP-Server:AKS Model Context Protocol Server

Containernetzwerksicherheit (Cilium)

• FQDN-Filterung:Konzepte und Anwenden von FQDN-Filterrichtlinien
• Layer 7-Richtlinie:Konzepte und Anwenden von L7-Richtlinien
• Mutual TLS (Cilium):Konzepte und Konfigurieren von gegenseitigem TLS
• Verschlüsselung während der Übertragung:WireGuard-Verschlüsselungskonzepte

Datenebene und -plattform

• Azure CNI powered by Cilium:Configure Azure CNI powered by Cilium
• eBPF-Hostroutingleistung:Containernetzwerkleistung mit eBPF-Hostrouting
• Log Analytics Tabellenpläne:Wählen Sie einen Tabellenplan basierend auf der Datennutzung

Open-Source-Werkzeuge

• Retina:retina.sh und das Repository Microsoft Retina GitHub
• Hubble (Cilium-Projekt):Hubble-Dokumentation