Was sind Containernetzwerkmetriken?

Jeder Pod, Dienst und Knoten in einem Kubernetes-Cluster generiert ständig Netzwerkaktivitäten: Verbindungen werden geöffnet, Pakete weitergeleitet oder verworfen, DNS-Abfragen auflösen oder fehlschlagen. Das Verständnis dieser Aktivität ist für das Debuggen, die Kapazitätsplanung und das Gesunderhalten von Diensten unerlässlich. Die meisten Überwachungssetups mangeln jedoch in zwei Punkten:

• Nicht genügend Sichtbarkeit. Aggregate auf Knotenebene sagen, dass etwas falsch ist, aber nicht wo. Ohne Aufschlüsselungen auf Podebene, die den Quell- und Zielkontext enthalten, bedeutet das Isolieren einer fehlerhaften Arbeitsauslastung das Erraten.
• Zu viele Daten in großem Maßstab. Ein Cluster mit Hunderten von Mikroservices kann Tausende von Metrik-Zeitreihen pro Knoten erzeugen. Durch das Erfassen aller Daten steigen die Speicherkosten an und Dashboards werden langsamer.

Containernetzwerkmetriken in Advanced Container Networking Services für Azure Kubernetes Service (AKS) behandeln beide Aspekte. Das Feature sammelt Netzwerkmetriken auf Knotenebene und pod-Ebene über unterstützte Cilium- und nicht-Cilium-Datenebenen auf Linux und Windows.

Auf Cilium-Clustern können Sie mit der Filterung auf Quellebene einen Schritt weitergehen, mit dem Sie genau auswählen können, welche Namespaces, Workloads und Metriktypen gesammelt werden, bevor Daten den Knoten verlassen.

Die Filterung von Containermetriken ist ein Vorabaufnahmesteuerelement für Observability-Daten. Anstatt alle verfügbaren Metriken zu sammeln und später in Dashboards oder Abfragen zu filtern, definieren Sie, was an der Quelle gesammelt werden soll. Dadurch bleiben hochwertige Metriken für die Arbeitslasten, die für Sie von Interesse sind, und es wird das Erfassen von Zeitreihen mit geringem Wert oder rauschenhaften Zeitreihen vermieden.

Das Ergebnis: umsetzbare Netzwerkbeobachtbarkeit auf jeder unterstützten Datenebene mit optionaler kosteneffizienter Filterung auf Cilium.

Containernetzwerkmetriken bieten Ihnen umfassende Sichtbarkeit auf Workloadebene für die Problembehandlung und Planung, während die auf Cilium basierende Filterung auf Quellebene hilft, die Observierungskosten proportional zu geschäftskritischen Workloads zu halten.

Sammlung und Filterung auf einen Blick

Verwenden Sie diese Tabelle, um schnell zu verstehen, wo eine breite Sammlung verfügbar ist und wo feinkörnige Filterung verfügbar ist:

Hauptvorteile

• Granularität auf Knoten- und Podebene. Nachverfolgen von Datenverkehrsvolumen, Dropraten und Verbindungszuständen auf Knotenebene für den Infrastrukturstatus. Führen Sie eine detaillierte Analyse der einzelnen Pods mit Quell- und Ziellabels durch, um die genaue Workload zu identifizieren, die ein Problem verursacht.

• Schnellere Problembehandlung. Wenn ein Dienst Pakete zu verlieren beginnt oder DNS-Anfragen fehlschlagen, können Sie mithilfe von Metriken auf Pod-Ebene das Problem innerhalb von Sekunden statt Stunden auf einen bestimmten Pod, Namespace oder ein Protokoll isolieren.

• Flexible Visualisierung. Speichern Sie Metriken in Azure Managed Prometheus und visualisieren Sie sie in Azure Managed Grafana (vollständig verwaltet), oder bringen Sie Ihre eigene Prometheus- und Grafana-Infrastruktur mit.

• Skalierbar nach Design. Die Pipeline verarbeitet große, dynamische Cluster mit Hunderten von Knoten und Tausenden von Pods, ohne dass Sie zwischen umfassender Abdeckung und verwaltbaren Datenvolumes wählen müssen.

• Gezielte Observierbarkeit (Cilium-Cluster) Mithilfe der Filterung auf Cilium-Clustern können Sie die Namespaces, Pod-Labels oder Metriktypen festlegen, die Sie interessieren, und nur diese erfassen. Es ist keine Nachbearbeitung nach der Datenerhebung erforderlich.

• Niedrigere Kosten für die Aufnahme von Metriken (Cilium-Cluster). Da die Filterung an der Quelle auf jedem Knoten erfolgt, werden unerwünschte Metrik-Zeitreihen niemals abgerufen, übertragen oder in Ihr Prometheus-Backend eingespeist. Sie zahlen nur für die Metriken, die Sie tatsächlich benötigen. In großen Clustern, in denen eine ungefilterte Sammlung Tausende von Zeitreihen pro Knoten erzeugen kann, kann die Filterung auf Quellebene die Kosten für ingestion und Speicherung bei Azure Managed Prometheus erheblich reduzieren.

So funktioniert es

Der Agentstapel auf jedem Knoten hängt von der Datenebene ab, wie im Diagramm dargestellt.

Linux-Cilium-Knoten verwenden einen mehrschichtigen eBPF-basierten Stapel: eBPF-Kernel-Hooks erfassen Rohdaten, Cilium verarbeitet sie und Hubble macht ihn als Prometheus-Formatmetriken verfügbar. Da sich Hubble zwischen dem Knoten und dem Scrape-Endpunkt befindet, wird die Filterung auf Quellniveau auf dieser Ebene ausgeführt – Sie wählen aus, welche Namespaces, Pod-Labels und Metriktypen exportiert werden, bevor Daten den Knoten verlassen.

Linux-Nicht-Cilium-Knoten verwenden eBPF-Kernel-Hooks, die in Microsoft Retina eingespeist werden, mit einer darüberliegenden Hubble-Schicht zur Flussinspektion. Microsoft Retina verarbeitet metrische Sammlung und exportiert Metriken auf Knotenebene und Pod-Level-Metriken im Prometheus-Format.

Aus allen Pfaden werden Metriken im Prometheus-Format abgerufen und in Azure Managed Prometheus oder Ihr eigenes Prometheus-Backend aufgenommen und dann in Azure Managed Grafana oder Ihrem eigenen Grafana-Stack visualisiert.

Richten Sie zunächst Containernetzwerkmetriken ein, und konfigurieren Sie dann die Filterung von Containernetzwerkmetriken für Cilium-Cluster.

Wann man Container-Netzwerkmetriken verwenden sollte

Containernetzwerkmetriken sind für Teams konzipiert, die fokussierte, umsetzbare Netzwerkdaten anstelle von unformatierter Telemetrie benötigen. Zu den gängigen Szenarien gehören:

• Debuggen einer bestimmten Arbeitsauslastung. Verwenden Sie Pod-Level-Metriken, um Paketabbrüche, TCP-Zurücksetzungen oder DNS-Fehler für einen bestimmten Dienst zu isolieren. Bei Cilium-Clustern kann die Filterung auf nur diesen Namespace oder Pod-Label beschränkt werden, wodurch clusterweites Rauschen reduziert wird.
• Überwachung von Multimandantenclustern. Überwachen Sie die Netzwerkgesundheit pro Namespace, damit jedes Team Einblicke in seine eigenen Datenverkehrsmuster erhält. Bei Cilium-Clustern beschränkt die Bereichsfilterung die Sammlung auf spezifische Namespaces des Mandanten.
• Kapazitätsplanung. Verfolgen Sie weitergeleitete und verworfene Byteanzahlen pro Knoten, um gesättigte Verknüpfungen oder unausgeglichene Workloadplatzierung zu identifizieren.
• Überwachung der DNS-Gesundheit. Erkennen von DNS-Abfragefehlern und langsamen Auflösungszeiten, um Probleme zu identifizieren, bevor sie zu Anwendungsfehlern führen.
• Reduzierung der Beobachtbarkeitskosten in großem Maßstab. In großen Clustern kann eine nicht gefilterte Sammlung Tausende von Zeitreihen pro Knoten generieren. Bei Cilium-Clustern entfernt die Filterung auf Quellebene unerwünschte Datenreihen, bevor sie aufgenommen werden, sodass die Kosten mit den von Ihnen ausgewählten Workloads und Metriktypen in Einklang bleiben.

So wählen Sie aus, was gesammelt werden soll (Cilium-Cluster)

Verwenden Sie dieses Rolloutmodell, um die Sichtbarkeit und die Kosten auszugleichen:

1. Beginnen Sie mit einer umfassenden Datenerfassung in einem Namespace außerhalb der Produktion, um eine Ausgangsbasis festzulegen.
2. Halten Sie Paketverlust-, DNS- und TCP-Zustandsmetriken für kritische Namespaces.
3. Begrenzen Sie Metriken mit hohem Kardinalitätsfluss auf geschäftskritische Workloads.
4. Überprüfen Sie die Prometheus-Ingestionstrends und verfeinern Sie die Filter wöchentlich.

Dieser Ansatz hilft Ihnen dabei, hochwertige Metriken beizubehalten, während Sie das Wachstum von Zeitreihen und die Aufnahmekosten steuern.

Bevor Sie die Metriktabellen überprüfen

Beachten Sie Folgendes:

• Metriken auf Knotenebene sind in unterstützten Cilium- und nicht-Cilium-Datenebenen verfügbar.
• Pod-Level-Metriken sind unter Linux verfügbar.
• Die Filterung auf Quellebene ist nur für Cilium-Cluster verfügbar.
• Für Cilium-Cluster erfordern DNS-Metriken eine Cilium-FQDN-Netzwerkrichtlinie.

Metrikenreferenz

Metriken auf Knotenebene

Metriken auf Knotenebene bieten aggregierte Datenverkehrsstatistiken pro Knoten – weitergeleitete und verworfene Pakete, Byteanzahl und Verbindungszustände. Diese Metriken werden im Prometheus-Format gespeichert und können in Grafana visualisiert werden.

Die folgenden Metriken werden pro Knoten aggregiert. Alle Metriken enthalten die folgenden Bezeichnungen:

• cluster
• instance (Knotenname)

Metriken auf Podebene (Hubble-Metriken)

Metriken auf Pod-Ebene umfassen Quell- und Ziel-Pod-Informationen, sodass Sie Netzwerkprobleme auf der Ebene der einzelnen Workloads identifizieren können. Diese Metriken decken das Datenverkehrsvolumen, verworfene Pakete, TCP-Zurücksetzungen und Layer 4/Layer 7-Flüsse ab.

DNS-Metriken (Abfrageanzahl, Antwortcodes und Fehler) werden standardmäßig auf Nicht-Cilium-Datenebenen erfasst. Auf Cilium-Datenebenen erfordern DNS-Metriken eine Cilium-FQDN-Netzwerkrichtlinie. Sie können DNS-Probleme auch in Echtzeit beheben, indem Sie die Hubble CLI verwenden.

In der folgenden Tabelle werden die Metriken beschrieben, die pro Pod aggregiert werden (Knoteninformationen bleiben erhalten).

Alle Metriken enthalten Bezeichnungen:

• cluster

• instance (Knotenname)

• source oder destination

  • Bei ausgehendem Datenverkehr gibt ein source Label den Quell-Pod-Namespace und den Namen an.

  • Bei eingehendem Datenverkehr gibt eine destination Bezeichnung den Ziel-Pod-Namespace und den Namen an.

Limitations

Plattform- und Datenebene:

• Metriken auf Podebene sind nur unter Linux verfügbar.
• Die Cilium-Datenebene wird ab Kubernetes Version 1.29 unterstützt.
• Metrikfilter auf Quellebene sind nur für Cilium-Cluster verfügbar.
• Metrikbeschriftungen weisen subtile Unterschiede zwischen Cilium- und Nicht-Cilium-Clustern auf.

DNS-Metriken:

• Bei Cilium-Clustern benötigen DNS-Metriken eine Cilium-FQDN-Netzwerkrichtlinie, oder Sie können die Hubble CLI für die Dns-Problembehandlung in Echtzeit verwenden.

Bekannte Probleme:

• Wenn ein Hubble-Knoten-Agent abstürzt, kann das Hubble-Relay abstürzen, wodurch Hubble CLI-Sitzungen unterbrochen werden können.

FIPS-Unterstützung (Datenebenen, die nicht auf Cilium basieren):

• FIPS ist aufgrund von Kerneleinschränkungen nicht auf Ubuntu 20.04-Knoten verfügbar. Verwenden Sie stattdessen einen Azure Linux-Knotenpool. Diese Einschränkung gilt nicht für Cilium-Datenebenen. Informationen zu Updates finden Sie in der AKS-Problemverfolgung.

Skala:

• Der verwaltete Dienst für Prometheus in Azure Monitor und Azure Managed Grafana erzwingt dienstspezifische Skalierungseinschränkungen. Weitere Informationen finden Sie unter Scrape Prometheus-Metriken im großen Stil in Azure Monitor.

Pricing

Weitere Informationen zu den Preisen finden Sie unter Erweiterte Container-Netzwerkdienste – Preise.

Verwandte Inhalte

• Einrichten von Containernetzwerkmetriken
• Konfigurieren der Filterung von Containernetzwerkmetriken
• Erweiterte Containernetzwerkdienste für AKS
• Beobachtbarkeit von Containernetzwerken in fortgeschrittenen Container-Netzwerkdiensten
• Containernetzwerksicherheit in fortschrittlichen Container-Netzwerkdiensten