Einrichten von Containernetzwerkmetriken für Azure Kubernetes Service (AKS)

Verwenden Sie Containernetzwerkmetriken, um Paketabbrüche zu identifizieren, DNS-Verhalten zu untersuchen und die Workloads zu finden, die an Netzwerkproblemen beteiligt sind. Dieser Leitfaden ermöglicht die Datenerfassung auf Azure Kubernetes Service (AKS), verbindet sie mit einem Prometheus-Back-End und zeigt Ihnen, wie Sie den Netzwerkstatus in den ACNS Grafana-Dashboards anzeigen.

Verwenden Sie Azure Monitor verwalteten Dienst für Prometheus, und zeigen Sie Netzwerkdashboards direkt im Azure-Portal an. Die Grafana-Dashboards des Portals stehen ohne zusätzliche Dashboardkosten zur Verfügung; Sie müssen keine Azure Managed Grafana Instanz erstellen. Alternativ können Sie Ihre eigene Prometheus- und Grafana-Bereitstellung verwenden. Die Metriksammlung ist in unterstützten Cilium- und nicht-Cilium-Datenebenen verfügbar; Pod-Level-Metriken erfordern Linux. Sehen Sie sich die Metrikübersicht für die Plattformabdeckung und die verfügbaren Metriken an.

Auf Cilium-Clustern können Sie dann einzelne Metriken nach Workload oder Sicherheitsidentität filtern oder Metriken für externe Ziel-IPs und Zielports aktivieren. Dies sind optionale nächste Schritte, keine Anforderungen für die grundlegende Erfassung.

Beginnen Sie beispielsweise mit Include-Filtern, um Flussmetriken aus einer Anwendung zu sammeln. Fügen Sie Ausschlussfilter nur hinzu, wenn Sie eine Ausnahme benötigen, z. B. das Weglassen von Datenverkehr zu einem bestimmten Ziel. Verwenden Sie stattdessen einen reinen Ausschlussfilter, um eine breite Datenerfassung beizubehalten, während Beobachtungen zu Lasttest-Drops entfernt werden. Siehe Metrikfilterbeispiele.

Informationen zu gespeicherten Protokollen oder echtzeitbasierten Hubble-Inspektionen anstelle von Metriken finden Sie unter Container-Netzwerkprotokolle einrichten.

Prerequisites

• Ein Azure-Konto mit einem aktiven Abonnement. Erstellen Sie bei Bedarf ein kostenloses Konto.
• Verwenden Sie Bash in Azure Cloud Shell oder in einem lokalen Bash-Terminal mit dem aktuellen Azure CLI und kubectl. Führen Sie az --version aus, um die CLI-Installation zu überprüfen.
• Berechtigungen zum Erstellen oder Aktualisieren des Clusters und der von Ihnen ausgewählten Überwachungsressourcen sowie lesezugriff auf den Azure Monitor Arbeitsbereich, der die Metriken enthält. Überprüfen Sie für den verwalteten Pfad die Azure Monitor-Voraussetzungen.
• Eine unterstützte AKS-Kubernetes-Version und ein unterstütztes Knotenbetriebssystem. Erstellen Sie keine neuen Knotenpools für eingestellte Azure Linux 2.0-Images. Weitere Informationen finden Sie unter Upgraden des Betriebssystems.
• Ausführen von Workloads mit Netzwerkaktivitäten zum Befüllen der Workload-Dashboards. Ein leerer Cluster zeigt keinen Anwendungsdatenverkehr an.
• Konfigurieren Sie für DNS-Metriken in Cilium die DNS-Sichtbarkeit , indem Sie eine DNS-Inspektionsrichtlinie anwenden und DNS-Datenverkehr generieren. Schließen Sie für HTTP-Metriken die vollständige Layer 7-Richtlinienkonfiguration ab: Aktivieren Sie L7 im Cluster, wenden Sie eine HTTP-Inspektionsrichtlinie auf die Workload an, und generieren Sie HTTP-Datenverkehr über diese Richtlinie. Das Konfigurieren von Metrikfiltern wendet diese Richtlinien nicht an und überprüft die Beobachtungsgenerierung nicht. Für die grundlegende Netzwerküberwachung auf Knotenebene ist keines erforderlich.

Schritt 1: Aktivieren von ACNS und Herstellen einer Verbindung mit dem Cluster

Melden Sie sich bei Verwendung einer lokalen CLI mit az login an. Wählen Sie Ihr Abonnement aus, und legen Sie die in diesem Handbuch verwendeten Werte fest:

az account set --subscription "<subscription-id>"
export RESOURCE_GROUP="<aks-resource-group>"
export CLUSTER_NAME="<aks-cluster-name>"
export LOCATION="<azure-region>"

Verwenden eines vorhandenen Clusters

Wenn ACNS bereits aktiviert ist, überspringen Sie den Updatebefehl. Andernfalls, aktivieren Sie es:

az aks update \
    --resource-group "$RESOURCE_GROUP" \
    --name "$CLUSTER_NAME" \
    --enable-acns

Durch aktivieren von ACNS wird die Datenebene eines vorhandenen Clusters nicht geändert. Die Metrikfilterung und die später beschriebene zusätzliche Metrikaktivierung erfordern Cilium. Weitere ACNS-Funktionen und ihre Voraussetzungen finden Sie in der ACNS-Übersicht.

Oder erstellen Sie einen neuen Cluster

Erstellen Sie die Ressourcengruppe, falls sie noch nicht vorhanden ist:

az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

Wählen Sie eine der folgenden Optionen aus. Diese Befehle verwenden die Standardversion von AKS Kubernetes der Region, anstatt eine alte Version festzuschreiben. Wenn Sie eine andere unterstützte Version auswählen möchten, prüfen Sie az aks get-versions --location "$LOCATION" -o table und fügen Sie --kubernetes-version mit Ihrer ausgewählten Version hinzu.

Cilium

Wählen Sie "Cilium" aus, wenn Sie beabsichtigen, die Metrikfilterung auf Quellenebene oder die zusätzlichen Metriken für externe IPs und Zielports zu verwenden:

az aks create \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --generate-ssh-keys \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --node-count 2 \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

Nicht-Cilium

Diese Option unterstützt die Sammlung der Metriken, die für die Nicht-Cilium-Datenebene verfügbar sind. Er stellt nicht die Cilium-spezifischen CNM-Filterpfade oder Containernetzwerksicherheitsfeatures bereit. Informationen zu FIPS-Einschränkungen finden Sie in den Einschränkungen der Metrikplattform.

az aks create \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --generate-ssh-keys \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --enable-acns

Abrufen von Clusteranmeldeinformationen

Stellen Sie für einen neuen oder vorhandenen Cluster eine Verbindung her, und bestätigen Sie den aktuellen Kontext:

az aks get-credentials --name "$CLUSTER_NAME" --resource-group "$RESOURCE_GROUP"

kubectl config current-context
kubectl get nodes

Beenden Sie, wenn der Kontext nicht der beabsichtigte Cluster ist oder die Befehle fehlschlagen. Beheben Sie Verbindungs-, Berechtigungs- oder Probleme mit der Knotenbereitschaft, bevor Sie fortfahren.

Schritt 2: Sammlungspfad auswählen

Konfigurieren Sie zuerst einen Pfad. Wenn Sie bereits Netzwerkmetriken erfolgreich sammeln, behalten Sie diese Einrichtung bei, und fahren Sie mit Schritt 3 oder Schritt 4 fort. Das Konfigurieren doppelter Scrapes kann die Aufnahme erhöhen und Abfragen verzerren.

von Azure verwaltete Prometheus- und Portaldashboards

Verwenden Sie einen Azure Monitor Arbeitsbereich für Prometheus-Metriken. Ein Log Analytics Arbeitsbereich speichert Protokolle und ist kein Ersatz für diesen Metrikarbeitsbereich.

Im folgenden Beispiel wird ein Azure Monitor Arbeitsbereich in der Ressourcengruppe des Clusters erstellt. Wenn Sie bereits über einen Arbeitsbereich verfügen, setzen Sie AZURE_MONITOR_NAME auf seinen Namen, überspringen Sie die Erstellung und rufen Sie die ID mithilfe der tatsächlichen Ressourcengruppe ab. Verwenden Sie einen von Azure Monitor-Arbeitsbereichen unterstützten Speicherort.

Erstellen oder wählen Sie einen Azure Monitor-Arbeitsbereich aus

export AZURE_MONITOR_NAME="<azure-monitor-name>"

az resource create \
    --resource-group "$RESOURCE_GROUP" \
    --namespace Microsoft.Monitor \
    --resource-type accounts \
    --name "$AZURE_MONITOR_NAME" \
    --location "$LOCATION" \
    --properties '{}'

Aktivieren der verwalteten Prometheus-Erfassung

Rufen Sie die ressourcen-ID des Azure Monitor Arbeitsbereichs ab:

azuremonitorId=$(az resource show \
    --resource-group "$RESOURCE_GROUP" \
    --name "$AZURE_MONITOR_NAME" \
    --resource-type "Microsoft.Monitor/accounts" \
    --query id --output tsv)

Überprüfen Sie den Befehl auf Fehler, und bestätigen Sie, dass azuremonitorId die Ressourcen-ID des vorgesehenen Arbeitsbereichs enthält, bevor Sie fortfahren. Scraping aktivieren:

az aks update \
    --name "$CLUSTER_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --enable-azure-monitor-metrics \
    --azure-monitor-workspace-resource-id "$azuremonitorId"

Überprüfen Sie die Azure Monitor Metrik-Pods:

kubectl get pods -n kube-system -o wide | grep ama-metrics

Beheben Sie nicht bereite Pods, bevor Sie die Daten überprüfen. Das Ausführen von Pods allein reicht nicht aus, um erfolgreiches Scraping oder Ingestion zu gewährleisten. Bei Berechtigungs- oder Erfassungsproblemen folgen Sie den Anweisungen unter Überwachung auf AKS aktivieren.

Für die Azure Portaldashboards ist keine separate Grafana-Ressource oder Grafana-Verknüpfung erforderlich. Fahren Sie mit der Metrikauswahl fort, und öffnen Sie dann die Netzwerkdashboards in Schritt 4.

Ihre eigene Prometheus- und Grafana-Instanz

Verwenden Sie eine vorhandene Prometheus-Bereitstellung, mit der Kubernetes-Pods erkannt und die Endpunkte der Agentmetriken erreicht werden können. Konfigurieren Sie zuerst die Kubernetes-API-Authentifizierung, RBAC und den Netzwerkzugriff. Im folgenden Beispiel werden Hubble-Pod-Level-Metriken behandelt. Es konfiguriert keine Cilium- oder Retina-Metriken auf Knotenebene.

Fügen Sie diesen Auftrag zu Ihrer vorhandenen scrape_configs Liste hinzu, wobei andere Aufträge erhalten bleiben. Wenn ein Operator Prometheus verwaltet, verwenden Sie den unterstützten Konfigurationsmechanismus, anstatt eine generierte Konfigurationsdatei zu bearbeiten. Ersetzen Sie myAKSCluster durch Ihre Clusterbeschriftung:

scrape_configs:
  - job_name: networkobservability-hubble
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_pod_label_k8s_app]
        regex: 'kube-system;(retina|cilium)'
        action: keep
      - source_labels: [__meta_kubernetes_pod_phase]
        regex: Running
        action: keep
      - source_labels: [__meta_kubernetes_pod_ip]
        regex: '([^:]+)'
        replacement: '$1:9965'
        target_label: __address__
      - source_labels: [__meta_kubernetes_pod_ip]
        regex: '(.+:.*)'
        replacement: '[$1]:9965'
        target_label: __address__
      - target_label: cluster
        replacement: myAKSCluster
      - source_labels: [__meta_kubernetes_pod_node_name]
        target_label: instance
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'hubble_dns_queries_total|hubble_dns_responses_total|hubble_drop_total|hubble_tcp_flags_total'
        action: keep

Überprüfen Sie die zusammengeführte Konfiguration mit promtool check config "<prometheus-config-file>", falls dies in Ihrer Bereitstellung verfügbar ist, und laden Sie Prometheus dann mithilfe Ihres normalen Betriebsverfahrens neu. Überprüfen Sie in Ziele, ob die Ziele für networkobservability-hubbleUP sind. Prüfen Sie Scraping-Fehler, falls keine vorhanden sind. In diesem Beispiel wird davon ausgegangen, dass der Hubble-Endpunkt am Port 9965 verfügbar gemacht wird. Überprüfen Sie den Endpunkt Ihrer Bereitstellung, falls dieser abweicht.

Verbinden Sie Grafana mit dieser Prometheus-Datenquelle. Fahren Sie mit der Metrikauswahl in Schritt 3 fort, und öffnen Sie dann die Dashboards in Schritt 4.

Schritt 3: Auswählen der Hubble-Metriken, die aufgenommen werden sollen

Um hochkardinalitätsbezogene Daten und Aufnahmekosten zu begrenzen, sammelt das verwaltete Prometheus-Profil für die Aufnahme diese Metriken standardmäßig nicht:

• hubble_flows_processed_total
• hubble_flows_to_world_total
• hubble_port_distribution_total

Wenn Sie eine dieser drei Metriken benötigen, fügen Sie der vorhandenen Sammlungskonfiguration Ihre Namen hinzu. Fahren Sie andernfalls mit Schritt 4 fort.

Die Metriken müssen am Endpunkt des Agents verfügbar sein, bevor sie erfasst werden können. Informationen zum Aktivieren der optionalen Welt- oder Metriken für Zielports für Cilium finden Sie unter Konfigurieren der Filterung von Containernetzwerkmetriken.

Folgen Sie den Anweisungen im folgenden Abschnitt für Ihr Prometheus-Back-End.

Metrikfamilien in Managed Prometheus zulassen

Verwenden Sie Ihre Auswahl, um die networkobservabilityHubble Zulassungsliste in der ama-metrics-settings-configmap ConfigMap in kube-systemzu aktualisieren. Diese Änderung ermöglicht es dem Sammler, diese Metriken aus dem Prometheus-Metrikenendpunkt des Agents einzuschließen.

1. Wenn die ConfigMap nicht vorhanden ist, erstellen Sie sie mithilfe der unterstützten Vorlage in Customize Prometheus Scraping. Wenn sie bereits vorhanden ist, sichern Sie sie, bevor Sie Änderungen vornehmen:

   kubectl get configmap ama-metrics-settings-configmap -n kube-system \
     -o yaml > ama-metrics-settings-before.yaml
   

   Beheben Sie alle Fehler, bevor Sie fortfahren.

2. Öffnen Sie die ConfigMap zum Bearbeiten. Im Schema v2 suchen Sie networkobservabilityHubble im default-targets-metrics-keep-list Abschnitt unter data.cluster-metrics. Bewahren Sie das vorhandene Schema und andere Einstellungen Ihrer ConfigMap auf.

   kubectl edit configmap ama-metrics-settings-configmap -n kube-system
   

3. Halten Sie die minimale Ingestion aktiviert. Fügen Sie jedem zusätzlichen Metriknamen den vorhandenennetworkobservabilityHubble Wert hinzu, durch | getrennt. Beispiel: Wenn der aktuelle Wert lautet:

   networkobservabilityHubble = "hubble_dns_queries_total|hubble_drop_total"
   

   Um auch Flussmetriken aufzunehmen, ändern Sie sie in:

   networkobservabilityHubble = "hubble_dns_queries_total|hubble_drop_total|hubble_flows_processed_total"
   

   Verwenden Sie ihren eigenen vorhandenen Wert als Ausgangspunkt, nicht den Beispielwert. Diese Einstellung ist keine vollständige ConfigMap. Das Sammeln weiterer Metriken kann das Aufnahmevolumen und die Kosten erhöhen.

4. Speichern und schließen Sie den Editor. Erlauben Sie dem Sammler, die Einstellungen neu zu laden, und fragen Sie dann jede hinzugefügte Metrik in Prometheus ab. Im vorherigen Beispiel können Sie hubble_flows_processed_total abfragen und auf aktuelle Stichproben prüfen, während relevanter Datenverkehr fließt. Fragen Sie außerdem eine vorhandene Metrik ab, z. B. hubble_dns_queries_total, wenn Sie sie bereits sammeln, um zu bestätigen, dass sie weiterhin neue Messwerte empfängt. Überprüfen Sie Dashboards und Warnungen, die diese Metriken verwenden, bevor Sie mit Schritt 4 fortfahren.

Metrikfamilien in Ihrem eigenen Prometheus zulassen

Fügen Sie zusätzliche Metriknamen an den Keep-Ausdruck des metric_relabel_configs vorhandenen Auftrags an, getrennt durch |. Behalten Sie alle vorhandenen Namen und Muster bei. Wenn der aktuelle Ausdruck beispielsweise lautet hubble_dns_queries_total|hubble_drop_total, fügen Sie Ablaufmetriken wie folgt hinzu:

metric_relabel_configs:
  - source_labels: [__name__]
    regex: 'hubble_dns_queries_total|hubble_drop_total|hubble_flows_processed_total'
    action: keep

Verwenden Sie Ihre eigene vorhandene Expression als Startpunkt. Aktualisieren Sie die vorhandene Keep-Regel, anstatt eine zweite anzufügen; Eine zweite Keep-Regel kann Metriken verwerfen, die von der ersten aufbewahrt werden. Überprüfen und laden Sie die Konfiguration erneut. Fragen Sie jede hinzugefügte Metrik, z. B. hubble_flows_processed_total, und eine vorhandene Metrik in Prometheus ab. Vergewissern Sie sich, dass beide aktuelle Samples erhalten, während relevanter Datenverkehr fließt, und öffnen Sie dann die Netzwerkdashboards in Schritt 4.

Schritt 4: Anzeigen von ACNS-Netzwerkdashboards

Azure portal

Öffnen Sie nach dem Aktivieren der Azure Monitor-Erfassung ein Netzwerkdashboard:

1. Öffnen Sie Ihren AKS-Cluster im Azure-Portal.
2. Wählen Sie unter "Überwachung" die Option "Dashboards mit Grafana" aus.
3. Wählen Sie in der Liste ein Dashboard aus, und wählen Sie dann den Namespace oder die Workload und einen Zeitraum mit Netzwerkaktivität aus.

Ausführliche Informationen finden Sie unter Verwenden von Dashboards mit Grafana in AKS.

Verfügbare Netzwerkdashboards

Verwenden Sie die folgenden sechs Kubernetes/Networking-Dashboards , um die Netzwerkaktivität Ihres Clusters zu erkunden. Import-IDs werden nur für Kunden bereitgestellt, die ihre eigene Grafana verwenden; Sie benötigen sie nicht für die integrierten Azure Portaldashboards.

Beginnen Sie mit Clustern für die Netzwerkintegrität auf Knotenebene, und öffnen Sie dann ein Workload- oder Namespace-Dashboard, um Datenverkehr, Paketverluste oder DNS-Verhalten zu untersuchen. Berücksichtigen Sie eine Sammlungsverzögerung nach dem Aktivieren der Überwachung oder dem Ändern der Aufbewahrungsliste.

DNS-Panels erfordern DNS-Sichtbarkeit. Pod Flows-Panels erfordern hubble_flows_processed_total in der in Schritt 3 konfigurierten Keep-Liste. Ein leeres Panel kann bedeuten, dass kein übereinstimmender Datenverkehr vorliegt, Daten nicht erfasst wurden oder der Zeitraum bzw. die Auswahl falsch ist. Es bedeutet nicht unbedingt, dass es ein Netzwerkproblem gibt.

Optional: Verwenden Sie eine separate Grafana-Bereitstellung

Wenn Sie bereits Azure Managed Grafana verwenden, können Sie es mit dem Azure Monitor-Arbeitsbereich verbinden und die Dashboards Kubernetes / Networking / ... unter Dashboards > Azure Managed Prometheus verwenden. Azure Managed Grafana ist ein separater kostenpflichtiger Dienst und keine Voraussetzung für die Portaldashboards.

Importieren Sie für Ihr eigenes Grafana die Dashboards mithilfe der IDs in der vorherigen Tabelle, und wählen Sie Ihre Prometheus-Datenquelle aus.

Beheben von Problemen mit fehlenden Metriken

Bereinigen von Ressourcen

Stellen Sie nur Ihre Änderungen an der Untersuchung in den CNM- und Prometheus-Allow-Listen wieder her. Behalten Sie Einstellungen, die von anderen Teams verwendet werden, und alle seit Ihrer Sicherung vorgenommenen Änderungen bei. Durch das Entfernen eines CNM-Eintrags wird eine optionale Metrik nur dann deaktiviert, wenn dieser Eintrag sie aktiviert hat; vom Dienst bereitgestellte Metriken bleiben aktiviert. Das Entfernen von Filtern kann die Sammlung erweitern. Historische Muster unterliegen weiterhin der Back-End-Aufbewahrung.

Löschen Sie eine Ressourcengruppe nur, wenn Sie sie exklusiv für diese Übung erstellt haben und niemand eine Ressource darin benötigt. Der folgende Befehl löscht den Cluster und alle anderen Ressourcen in dieser Gruppe:

az group delete --name "$RESOURCE_GROUP"

Nächste Schritte

• Wählen Sie Metriken aus und verstehen Sie ihre Grenzen.
• Filtern Sie Metriken, und aktivieren Sie zusätzliche Metriken für Cilium.
• Richten Sie gespeicherte oder On-Demand-Netzwerkprotokolle ein.
• Erkunden Sie erweiterte Containernetzwerkdienste.