Freigeben über


Aktivieren der Überwachung für Kubernetes-Cluster

In diesem Artikel wird beschrieben, wie Sie die vollständige Überwachung Ihrer Kubernetes-Cluster mithilfe der folgenden Azure Monitor-Features aktivieren:

Mittels dem Azure-Portal, Sie können alle Features gleichzeitig aktivieren. Sie können sie auch einzeln aktivieren, indem Sie Azure CLI, Azure Resource Manager-Vorlage, Terraform oder Azure Policy verwenden. Alle diese Schritte werden in diesem Artikel beschrieben.

Wichtig

Kubernetes-Cluster generieren viele Protokolldaten, was zu erheblichen Kosten führen kann, wenn Sie nicht selektiv über die von Ihnen gesammelten Protokolle sind. Bevor Sie die Überwachung für Ihren Cluster aktivieren, lesen Sie die folgenden Artikel, um sicherzustellen, dass Ihre Umgebung für Kosten optimiert ist und dass Sie Ihre Protokollsammlung auf die Daten beschränken, die Sie benötigen:

Unterstützte Cluster

Dieser Artikel enthält Anleitungen zum Onboarding für die folgenden Arten von Clustern. Alle Unterschiede im Prozess für jeden Typ werden in den relevanten Abschnitten aufgeführt.

Voraussetzungen

Berechtigungen

Voraussetzungen für verwaltetes Prometheus

  • Der Cluster muss die Authentifizierung der verwalteten Identität verwenden.
  • Die folgenden Ressourcenanbieter müssen im Abonnement des Clusters und im Azure Monitor-Arbeitsbereich registriert werden:
    • Microsoft.ContainerService
    • Microsoft.Insights
    • Microsoft.AlertsManagement
    • Microsoft.Monitor
    • Die folgenden Ressourcenanbieter müssen im Abonnement des Grafana-Arbeitsbereichsabonnements registriert werden:
      • Microsoft.Dashboard

Voraussetzungen für Arc-fähige Kubernetes-Cluster

Hinweis

Die Arc-aktivierte Kubernetes-Erweiterung für Managed Prometheus unterstützt die folgenden Konfigurationen nicht:

  • Red Hat Openshift-Distributionen, einschließlich Azure Red Hat OpenShift (ARO)
  • Windows-Knoten*

*Für ARC-fähige Cluster mit Windows-Knoten können Sie Azure Managed Prometheus auf einem Linux-Knoten innerhalb des Clusters einrichten und Scraping-Metriken von Metrikendpunkten konfigurieren, die auf den Windows-Knoten ausgeführt werden.

Arbeitsbereiche

Die folgende Tabelle beschreibt die Arbeitsbereiche, die erforderlich sind, um verwaltetes Prometheus und Containererkenntnisse zu unterstützen. Sie können jeden Arbeitsbereich als Teil des Onboardingprozesses erstellen oder einen vorhandenen Arbeitsbereich verwenden. Unter Entwerfen einer Log Analytics-Arbeitsbereichsarchitektur finden Sie Anleitungen dazu, wie viele Arbeitsbereiche erstellt und wo sie platziert werden sollen.

Eigenschaft Arbeitsbereich Hinweise
Verwaltetes Prometheus Azure Monitor-Arbeitsbereich Die Contributor-Berechtigung reicht aus, um das Add-On zum Senden von Daten an den Azure Monitor-Arbeitsbereich zu aktivieren. Sie werden Berechtigung auf Owner-Ebene benötigen, um Ihren Azure Monitor-Arbeitsbereich zum Anzeigen von Metriken in Azure Managed Grafana zu verknüpfen. Dies ist erforderlich, da der Benutzer, der den Onboardingschritt ausführt, in der Lage sein muss, die Azure Managed Grafana-Systemidentitätsrolle Monitoring Reader für den Azure Monitor-Arbeitsbereich zu vergeben, um die Metriken abzufragen.
Container Insights Log Analytics-Arbeitsbereich Sie können einen Cluster an einen Log Analytics-Arbeitsbereich in einem anderen Azure-Abonnement im selben Microsoft Entra-Mandanten anfügen, aber Sie müssen die Azure CLI oder eine Azure Resource Manager-Vorlage verwenden. Sie können diese Konfiguration derzeit nicht mit dem Azure-Portal ausführen.

Wenn Sie einen vorhandenen Cluster mit einem Log Analytics-Arbeitsbereich in einem anderen Abonnement verbinden, muss der Microsoft.ContainerService-Ressourcenanbieter im Abonnement mit dem Log Analytics-Arbeitsbereich registriert werden. Weitere Informationen finden Sie unter Registrieren des Ressourcenanbieters.

Eine Liste der unterstützten Zuordnungspaare für den Standardarbeitsbereich finden Sie unter Von Container Insights unterstützte Regionszuordnungen. Anleitungen zum Konfigurieren des Arbeitsbereichs mit Netzwerksicherheitsperimeter finden Sie unter "Konfigurieren von Azure Monitor mit Netzwerksicherheitsperimeter ".
Managed Grafana Azure Managed Grafana-Arbeitsbereich Verknüpfen Sie Ihren Grafana-Arbeitsbereich mit Ihrem Azure Monitor-Arbeitsbereich, um die aus Ihrem Cluster gesammelten Prometheus-Metriken für Grafana-Dashboards verfügbar zu machen.

Prometheus und Grafana aktivieren

Verwenden Sie eine der folgenden Methoden, um das Scraping von Prometheus-Metriken aus Ihrem Cluster zu ermöglichen und Managed Grafana zu aktivieren, um Metriken zu visualisieren. Unter Verknüpfen eines Grafana-Arbeitsbereichs finden Sie Optionen zum Verbinden Ihres Azure Monitor-Arbeitsbereichs und des Azure Managed Grafana-Arbeitsbereichs.

Wichtig

  • Wenn Sie für die Bereitstellung eine Vorlage oder Azure Policy verwenden, stellen Sie sicher, dass die Datensammlungsendpunkte, die Datensammlungsregeln und die Zuordnungen zu Datensammlungsregeln als MSProm-<Location of Azure Monitor Workspace>-<Name of cluster resource> benannt sind. Andernfalls wird der Onboardingprozess nicht erfolgreich abgeschlossen.

  • Wenn Sie über eine einzelne Azure Monitor-Ressource verfügen, die privat verknüpft ist, funktioniert die Aktivierung von Prometheus nicht, wenn sich der AKS-Cluster und der Azure Monitor-Arbeitsbereich in verschiedenen Regionen befinden. Erstellen Sie einen neuen DCE und DCRA in derselben Clusterregion. Ordnen Sie den neuen DCE dem Cluster zu, und nennen Sie den neuen DCRA als configurationAccessEndpoint. Siehe "Aktivieren eines privaten Links" für die Kubernetes-Überwachung in Azure Monitor.

Aktivieren mit der CLI

Wenn Sie in den folgenden Befehlen keinen vorhandenen Azure Monitor-Arbeitsbereich angeben, wird der Standardarbeitsbereich für die Ressourcengruppe verwendet. Wenn in der Region des Clusters noch kein Standardarbeitsbereich vorhanden ist, wird ein Arbeitsbereich mit einem Namen im Format DefaultAzureMonitorWorkspace-<mapped_region> in einer Ressourcengruppe mit dem Namen DefaultRG-<cluster_region>erstellt.

Voraussetzungen

  • Für die Az CLI ist eine Version von 2.49.0 oder höher erforderlich.
  • Die Erweiterung „aks-preview“ muss mithilfe des -Befehls az extension remove --name aks-preview.
  • Die Erweiterung „k8s-extension“ muss mit dem Befehl az extension add --name k8s-extension installiert werden.
  • Die k8s-Erweiterung, Version 1.4.1 oder höher, ist erforderlich.

Optionale Parameter

Jeder der Befehle für AKS und Arc-Enabled Kubernetes lässt die folgenden optionalen Parameter zu. Der Parametername unterscheidet sich für jeden, die Verwendung ist jedoch identisch.

Parameter Name und Beschreibung
Anmerkungsschlüssel AKS: --ksm-metric-annotations-allow-list
Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList

Eine durch Trennzeichen getrennte Liste von Kubernetes-Anmerkungsschlüsseln, die in der kube_resource_annotations-Metrik für Bezeichnungen der Ressource verwendet werden. Beispielsweise ist „kube_pod_annotations“ die Anmerkungsmetrik für die Pods-Ressource. Standardmäßig enthält diese Metrik nur Namens- und Namespacebezeichnungen. Um weitere Anmerkungen einzuschließen, geben Sie eine Liste von Ressourcennamen in der jeweiligen Pluralform sowie Kubernetes-Anmerkungsschlüssel an, die Sie dafür zulassen möchten. Es kann ein einzelnes * für jede Ressource bereitgestellt werden, um Anmerkungen zu ermöglichen, dies hat jedoch schwerwiegende Auswirkungen auf die Leistung. Beispielsweise pods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],....
Bezeichnungsschlüssel AKS: --ksm-metric-labels-allow-list
Arc: --AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist

Eine durch Komma getrennte Liste weiterer Kubernetes-Bezeichnungsschlüssel, die in der „kube_resource_labels“-Metrik der Ressource verwendet werden. Beispielsweise ist „kube_pod_labels“ die Bezeichnungsmetrik für die Pods-Ressource. Standardmäßig enthält die Metrik nur Namens- und Namespace-Bezeichnungen. Um weitere Bezeichnungen einzuschließen, stellen Sie eine Liste von Ressourcennamen in ihrer Pluralform und Kubernetes-Bezeichnungsschlüssel, die Sie für sie zulassen möchten, bereit. Ein einzelnes * kann für jede Ressource bereitgestellt werden, jegliche Bezeichnungen zuzulassen, aber dies hat schwerwiegende Auswirkungen auf die Leistung. Beispielsweise pods=[app],namespaces=[k8s-label-1,k8s-label-n,...],....
Aufzeichnungsregeln AKS: --enable-windows-recording-rules

Hiermit können Sie die Aufzeichnungsregelgruppen aktivieren, die für die ordnungsgemäße Funktion der Windows-Dashboards erforderlich sind.

AKS-Cluster

Verwenden Sie die -enable-azure-monitor-metrics-Option az aks create oder az aks update (je nachdem, ob Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren), um das Metrik-Add-On zu installieren, das Prometheus-Metriken ausliest.

### Use default Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group>

### Use existing Azure Monitor workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --azure-monitor-workspace-resource-id <azure-monitor-workspace-name-resource-id> --grafana-resource-id  <grafana-workspace-name-resource-id>

### Use optional parameters
az aks create/update --enable-azure-monitor-metrics --name <cluster-name> --resource-group <cluster-resource-group> --ksm-metric-labels-allow-list "namespaces=[k8s-label-1,k8s-label-n]" --ksm-metric-annotations-allow-list "pods=[k8s-annotation-1,k8s-annotation-n]"

Arc-fähiger Cluster

### Use default Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics

## Use existing Azure Monitor workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id>

### Use an existing Azure Monitor workspace and link with an existing Grafana workspace
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id>

### Use optional parameters
az k8s-extension create --name azuremonitor-metrics --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers.Metrics --configuration-settings azure-monitor-workspace-resource-id=<workspace-name-resource-id> grafana-resource-id=<grafana-workspace-name-resource-id> AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList="pods=[k8s-annotation-1,k8s-annotation-n]" AzureMonitorMetrics.KubeStateMetrics.MetricLabelsAllowlist "namespaces=[k8s-label-1,k8s-label-n]"

Die folgenden zusätzlichen optionalen Parameter sind für Azure Arc-fähige Cluster verfügbar:

Parameter Beschreibung Standard Upstream Arc-Clusterkonfiguration
ClusterDistribution Die Verteilung des Clusters. Azure.Cluster.Distribution ja
CloudEnvironment Die Cloudumgebung für den Cluster. Azure.Cluster.Cloud ja
MountCATrustAnchorsDirectory Gibt an, ob das ZS-Vertrauensankerverzeichnis eingebunden werden soll. true Nein
MountUbuntuCACertDirectory Ob das Ubuntu-ZS-Zertifikatsverzeichnis eingebunden werden soll. true, es sei denn, es ist eine aks_edge-Distribution. Nein

Aktivieren von Container Insights

Verwenden Sie eine der folgenden Methoden, um Containererkenntnisse in Ihrem Cluster zu aktivieren. Sobald dies abgeschlossen ist, lesen Sie Konfigurieren der Agent-Datensammlung für Containerkenntnisse zum Anpassen Ihrer Konfiguration, um sicherzustellen, dass Sie nicht mehr Daten sammeln, als Sie benötigen.

Wichtig

Verwenden Sie einen der folgenden Befehle, um die Überwachung Ihrer AKS- und Arc-fähigen Cluster zu aktivieren. Wenn Sie keinen vorhandenen Log Analytics-Arbeitsbereich angeben, wird der Standardarbeitsbereich für die Ressourcengruppe verwendet. Wenn in der Region des Clusters noch kein Standardarbeitsbereich vorhanden ist, wird einer mit einem Namen im Format DefaultWorkspace-<GUID>-<Region> erstellt.

Voraussetzungen

  • Azure CLI-Version 2.43.0 oder höher
  • Die Authentifizierung mit verwalteter Identität ist der Standard in der CLI-Version 2.49.0 oder höher.
  • Azure k8s-Erweiterung, Version 1.3.7 oder höher
  • Die Authentifizierung verwalteter Identitäten ist in der k8s-Erweiterungsversion 1.43.0 oder höher standardmäßig aktiviert.
  • Die Authentifizierung mit verwalteter Identität wird für Arc-fähige Kubernetes-Cluster mit ARO (Azure Red Hat Openshift) oder Windows-Knoten nicht unterstützt. Verwenden der Legacy-Authentifizierung.
  • Für CLI-Version 2.54.0 oder höher wird das Protokollierungsschema mittels ConfigMap auf ContainerLogV2 konfiguriert.

Hinweis

Sie können das ContainerLogV2-Schema für einen Cluster entweder über die Datensammlungsregel (Data Collection Rule, DCR) des Clusters oder ConfigMap aktivieren. Wenn beide Einstellungen aktiviert sind, hat ConfigMap Vorrang. Stdout- und stderr-Protokolle werden nur dann in der ContainerLog-Tabelle erfasst, wenn sowohl DCR als auch ConfigMap explizit auf deaktiviert festgelegt sind.

AKS-Cluster

### Use default Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name>

### Use existing Log Analytics workspace
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id>

### Use legacy authentication
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --enable-msi-auth-for-monitoring false

Beispiel

az aks enable-addons --addon monitoring --name "my-cluster" --resource-group "my-resource-group" --workspace-resource-id "/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Arc-fähiger Cluster

### Use default Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers

### Use existing Log Analytics workspace
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID=<workspace-resource-id>

### Use managed identity authentication (default as k8s-extension version 1.43.0)
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=true

### Use advanced configuration settings
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings  amalogs.resources.daemonset.limits.cpu=150m amalogs.resources.daemonset.limits.memory=600Mi amalogs.resources.deployment.limits.cpu=1 amalogs.resources.deployment.limits.memory=750Mi

### With custom mount path for container stdout & stderr logs
### Custom mount path not required for Azure Stack Edge version > 2318. Custom mount path must be /home/data/docker for Azure Stack Edge cluster with version <= 2318
az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.logsettings.custommountpath=<customMountPath>

Informationen zu den verfügbaren Konfigurationseinstellungen finden Sie im Abschnitt „Ressourcenanforderungen und Grenzwerte“ des Helm-Charts.

Beispiel

az k8s-extension create --name azuremonitor-containers --cluster-name "my-cluster" --resource-group "my-resource-group" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID="/subscriptions/my-subscription/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace"

Arc-fähiger Cluster mit vorgeschaltetem Proxy

Wenn der Cluster mit einem Forwardproxy konfiguriert wurde, werden Proxyeinstellungen automatisch auf die Erweiterung angewendet. Bei einem Cluster mit AMPLS + Proxy sollte die Proxykonfiguration ignoriert werden. Führens Sie das Onboarding der Erweiterung mit der Konfigurationseinstellung „amalogs.ignoreExtensionProxySettings=true“ durch.

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.ignoreExtensionProxySettings=true

Arc-fähige Cluster mit ARO-, OpenShift- oder Windows-Knoten

Die Authentifizierung mit verwalteter Identität wird für Arc-fähige Kubernetes-Cluster mit ARO- (Azure Red Hat Openshift), OpenShift- oder Windows-Knoten nicht unterstützt. Sie können die Legacyauthentifizierung verwenden, indem Sie amalogs.useAADAuth=false wie im folgenden Beispiel angeben.

az k8s-extension create --name azuremonitor-containers --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

Löschen der Erweiterungsinstanz

Mit dem folgenden Befehl wird nur die Erweiterungsinstanz gelöscht, nicht aber der Log Analytics-Arbeitsbereich. Die Daten in der Log Analytics-Ressource bleiben intakt.

az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <cluster-name> --resource-group <resource-group>

Aktivieren der vollständigen Überwachung mit dem Azure-Portal

Neuer AKS-Cluster (Prometheus, Container Insights und Grafana)

Wenn Sie im Azure-Portal einen neuen AKS-Cluster erstellen, sind die Kontrollkästchen Containerprotokolle aktivieren, Prometheus-Metriken aktivieren, Grafana aktivieren und Empfohlene Benachrichtigungen aktivieren standardmäßig auf der Registerkarte "Überwachung" aktiviert.

Screenshot: Registerkarte „Überwachung“ für einen neuen AKS-Cluster.

Vorhandener Cluster (Prometheus, Container Insights und Grafana)

  1. Navigieren Sie im Azure-Portal zu Ihrem Cluster.
  2. Wählen Sie im Dienstmenü Monitor>Monitoreinstellungen aus.
  3. Prometheus-Metriken, Grafana- und Containerprotokolle und -ereignisse werden für Sie ausgewählt. Wenn Sie über einen Azure Monitor-Arbeitsbereich, einen Grafana-Arbeitsbereich und einen Log Analytics-Arbeitsbereich verfügen, werden sie für Sie ausgewählt.
  4. Wählen Sie die Option Erweiterte Einstellungen aus, um alternative Arbeitsbereiche auszuwählen oder neue zu erstellen. Mit der Einstellung " Protokollierungsprofile" und "Klassische Profile " können Sie die Standardauflistungsdetails ändern, um Ihre Überwachungskosten zu reduzieren. Weitere Informationen finden Sie unter Aktivieren von Kostenoptimierungseinstellungen in Container Insights.
  5. Wählen Sie Konfigurierenaus.

Aktivieren der Windows-Metrikensammlung (Vorschau)

Hinweis

In „windows-exporter-daemonset.yaml“ gibt es keinen CPU-/Arbeitsspeichergrenzwert, sodass die Windows-Knoten möglicherweise überdimensioniert werden.
Weitere Informationen finden Sie unter Ressourcenreservierung.

Beim Bereitstellen von Arbeitslasten setzen Sie Speicher- und CPU-Grenzwerte für Ressourcen in Containern. Diese werden auch von NodeAllocatable subtrahiert, was dem clusterweiten Scheduler bei der Bestimmung hilft, welche Pods auf welchen Knoten platziert werden sollen. Das Planen von Pods ohne Grenzwerte kann die Windows-Knoten überdimensionieren und in extremen Fällen dazu führen, dass die Knoten fehlerhaft werden.

Ab Version 6.4.0-main-02-22-2023-3ee44b9e des Verwalteten Prometheus-Add-On-Containers (prometheus_collector) wurde die Windows-Metriksammlung für AKS-Cluster aktiviert. Durch das Onboarding mit dem Azure Monitor-Metrik-Add-On können die Windows-DaemonSet-Pods für Ihre Knotenpools ausgeführt werden. Sowohl Windows Server 2019 als auch Windows Server 2022 werden unterstützt. Führen Sie diese Schritte aus, um die Pods zum Sammeln von Metriken aus Ihren Windows-Knotenpools zu ermöglichen.

  1. Installieren Sie Windows-Exporter manuell auf AKS-Knoten, um auf Windows-Metriken zuzugreifen, indem Sie die Windows-Exporter-Daemonset-YAML-Datei bereitstellen. Aktivieren Sie die folgenden Kollektoren:

    • [defaults]
    • container
    • memory
    • process
    • cpu_info

    Weitere Sammler finden Sie unter Prometheus-Exporter für Windows-Metriken.

    Stellen Sie die YAML-Datei „windows-exporter-daemonset“ bereit. Beachten Sie, dass Sie die entsprechenden Toleranzen anwenden müssen, wenn in dem Knoten irgendwelche Taints angewendet werden.

        kubectl apply -f windows-exporter-daemonset.yaml
    
  2. Wenden Sie die ama-metrics-settings-configmap auf Ihren Cluster an. Legen Sie die booleschen Werte windowsexporter und windowskubeproxy auf true fest. Weitere Informationen finden Sie unter ConfigMap-Einstellungen des Metrik-Add-Ons.

  3. Aktivieren Sie die Aufzeichnungsregeln, die für die vorgefertigten Dashboards erforderlich sind:

    • Wenn Sie das Onboarding mithilfe der CLI durchführen, beziehen Sie die Option --enable-windows-recording-rules ein.
    • Wenn Sie beim Onboarding eine ARM-Vorlage, Bicep oder Azure Policy verwenden, legen Sie in der Parameterdatei enableWindowsRecordingRules auf true fest.
    • Wenn für den Cluster bereits ein Onboarding durchgeführt wurde, verwenden Sie diese ARM-Vorlage und diese Parameterdatei, um die Regelgruppen zu erstellen. Dadurch werden die erforderlichen Aufzeichnungsregeln hinzugefügt, und es handelt sich nicht um einen ARM-Vorgang auf dem Cluster und wirkt sich nicht auf den aktuellen Überwachungszustand des Clusters aus.
  4. [Nur für Windows-Knoten in ARC-fähigen Clustern] Wenn Sie verwaltete Prometheus für einen ARC-fähigen Cluster aktivieren, können Sie verwaltete Prometheus konfigurieren, die auf einem Linux-Knoten innerhalb des Clusters ausgeführt wird, um Metriken von Endpunkten abzuwischen, die auf den Windows-Knoten ausgeführt werden. Fügen Sie den folgenden Scrape-Auftrag zu ama-metrics-prometheus-config-configmap.yaml hinzu, und wenden Sie die Configmap auf Ihren Cluster an.

  scrape_configs:
    - job_name: windows-exporter
      scheme: http
      scrape_interval: 30s
      label_limit: 63
      label_name_length_limit: 511
      label_value_length_limit: 1023
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        insecure_skip_verify: true
      bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
      kubernetes_sd_configs:
      - role: node
      relabel_configs:
      - source_labels: [__meta_kubernetes_node_name]
        target_label: instance
      - action: keep
        source_labels: [__meta_kubernetes_node_label_kubernetes_io_os]
        regex: windows
      - source_labels:
        - __address__
        action: replace
        target_label: __address__
        regex: (.+?)(\:\d+)?
        replacement: $$1:9182
kubectl apply -f ama-metrics-prometheus-config-configmap.yaml

Überprüfen der Bereitstellung

Verwenden Sie das kubectl-Befehlszeilentool, um zu überprüfen, ob der Agent ordnungsgemäß bereitgestellt ist.

Verwaltetes Prometheus

Überprüfen, ob das DaemonSet in den Linux-Knotenpools ordnungsgemäß bereitgestellt wurde

kubectl get ds ama-metrics-node --namespace=kube-system

Die Anzahl der Pods sollte gleich der Anzahl der Linux-Knoten im Cluster sein. Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-node   1         1         1       1            1           <none>          10h

Überprüfen, ob Windows-Knoten ordnungsgemäß bereitgestellt wurden

kubectl get ds ama-metrics-win-node --namespace=kube-system

Die Anzahl der Pods sollte gleich der Anzahl der Windows-Knoten im Cluster sein. Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

User@aksuser:~$ kubectl get ds ama-metrics-node --namespace=kube-system
NAME                   DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-metrics-win-node   3         3         3       3            3           <none>          10h

Überprüfen, ob die beiden ReplicaSets für Prometheus bereitgestellt wurden

kubectl get rs --namespace=kube-system

Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

User@aksuser:~$kubectl get rs --namespace=kube-system
NAME                            DESIRED   CURRENT   READY   AGE
ama-metrics-5c974985b8          1         1         1       11h
ama-metrics-ksm-5fcf8dffcd      1         1         1       11h

Container Insights

Überprüfen, ob die DaemonSets in den Linux-Knotenpools ordnungsgemäß bereitgestellt wurden

kubectl get ds ama-logs --namespace=kube-system

Die Anzahl der Pods sollte gleich der Anzahl der Linux-Knoten im Cluster sein. Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

User@aksuser:~$ kubectl get ds ama-logs --namespace=kube-system
NAME       DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ama-logs   2         2         2         2            2           <none>          1d

Überprüfen, ob Windows-Knoten ordnungsgemäß bereitgestellt wurden

kubectl get ds ama-logs-windows --namespace=kube-system

Die Anzahl der Pods sollte gleich der Anzahl der Windows-Knoten im Cluster sein. Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

User@aksuser:~$ kubectl get ds ama-logs-windows --namespace=kube-system
NAME                   DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR     AGE
ama-logs-windows           2         2         2         2            2       <none>            1d

Überprüfung der Bereitstellung der Container-Insights-Lösung

kubectl get deployment ama-logs-rs --namespace=kube-system

Die Ausgabe sollte in etwa wie das folgende Beispiel aussehen:

User@aksuser:~$ kubectl get deployment ama-logs-rs --namespace=kube-system
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
ama-logs-rs   1/1     1            1           24d

Anzeigen der Konfiguration mit CLI

Verwenden Sie den aks show-Befehl, um herauszufinden, ob die Lösung aktiviert ist, und um die Ressourcen-ID des Log Analytics-Arbeitsbereichs sowie Zusammenfassungsinformationen zum Cluster anzuzeigen.

az aks show --resource-group <resourceGroupofAKSCluster> --name <nameofAksCluster>

Der Befehl gibt JSON-formatierte Informationen zur Lösung zurück. Der Abschnitt addonProfiles sollte Informationen zu dem omsagent wie im folgenden Beispiel enthalten:

"addonProfiles": {
    "omsagent": {
        "config": {
            "logAnalyticsWorkspaceResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
            "useAADAuth": "true"
        },
        "enabled": true,
        "identity": null
    },
}

Bereitgestellte Ressourcen

Wenn Sie die Überwachung aktivieren, werden die folgenden Ressourcen in Ihrem Abonnement erstellt:

Ressourcenname Ressourcentyp Ressourcengruppe Region/Standort Beschreibung
MSCI-<aksclusterregion>-<clustername> Datensammlungsregel Identisch mit dem Cluster Identisch mit dem Log Analytics-Arbeitsbereich Diese Datensammlungsregel dient der Protokollsammlung durch den Azure Monitor-Agent, der den Log Analytics-Arbeitsbereich als Ziel verwendet und der AKS-Clusterressource zugeordnet ist.
MSPROM-<aksclusterregion>-<clustername> Datensammlungsregel Identisch mit dem Cluster Identisch mit dem Azure Monitor-Arbeitsbereich Diese Datensammlungsregel gilt für die Sammlung von Prometheus-Metriken nach Metrik-Add-On, das den ausgewählten Azure Monitor-Arbeitsbereich als Ziel aufweist und zudem der AKS-Clusterressource zugeordnet ist
MSPROM-<aksclusterregion>-<clustername> Datensammlungsendpunkt Identisch mit dem Cluster Identisch mit dem Azure Monitor-Arbeitsbereich Dieser Datensammlungsendpunkt wird von der obigen Datensammlungsregel zum Erfassen von Prometheus-Metriken aus dem Metrik-Add-On verwendet

Wenn Sie einen neuen Azure Monitor-Arbeitsbereich erstellen, werden die folgenden zusätzlichen Ressourcen als Teil des Arbeitsbereichs erstellt

Ressourcenname Ressourcentyp Ressourcengruppe Region/Standort Beschreibung
<azuremonitor-workspace-name> Datensammlungsregel MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed Identisch mit dem Azure Monitor-Arbeitsbereich DCR, die erstellt wird, wenn Sie den OSS Prometheus-Server zum Remote-Schreiben in den Azure Monitor-Arbeitsbereich verwenden.
<azuremonitor-workspace-name> Datensammlungsendpunkt MA_<azuremonitor-workspace-name>_<azuremonitor-workspace-region>_managed Identisch mit dem Azure Monitor-Arbeitsbereich DCE, die erstellt wird, wenn Sie den OSS Prometheus-Server zum Remote-Schreiben in den Azure Monitor-Arbeitsbereich verwenden.

Unterschiede zwischen Windows- und Linux-Clustern

Die wichtigsten Unterschiede bei der Überwachung eines Windows Server-Clusters im Vergleich zu einem Linux-Cluster beinhalten:

  • Windows bietet keine RSS-Metrik für den Arbeitsspeicher. Folglich ist für Windows-Knoten und -Container keine entsprechende Metrik verfügbar. Die Metrik Arbeitssatz ist verfügbar.
  • Für Windows-Knoten sind keine Informationen zur Speicherkapazität des Datenträgers verfügbar.
  • Nur Pod-Umgebungen werden überwacht, nicht aber Docker-Umgebungen.
  • Mit der Vorschauversion werden maximal 30 Windows Server-Container unterstützt. Diese Einschränkung gilt nicht für Linux-Container.

Hinweis

Die Unterstützung für Container Insights für das Betriebssystem Windows Server 2022 ist als Vorschau verfügbar.

Der containerisierte Linux-Agent (ReplicaSet-Pod) führt API-Aufrufe an alle Windows-Knoten am sicheren Kubelet-Port (10250) im Cluster aus, um Metriken zur Knoten- und Containerleistung zu erfassen. Der sichere Kubelet-Port (10250) sollte im virtuellen Netzwerk des Clusters für eingehenden und ausgehenden Datenverkehr geöffnet sein, damit die Erfassung von leistungsspezifischen Metriken von Windows-Knoten und -Containern funktioniert.

Wenn Sie über einen Kubernetes-Cluster mit Windows-Knoten verfügen, überprüfen und konfigurieren Sie die Netzwerksicherheitsgruppe und Netzwerkrichtlinien, um sicherzustellen, dass der sichere Kubelet-Port (10250) für ein- und ausgehenden Datenverkehr im virtuellen Netzwerk des Clusters geöffnet ist.

Nächste Schritte

  • Wenn beim Onboarding der Lösung Probleme auftreten, lesen Sie den Leitfaden zur Problembehandlung.
  • Wenn die Überwachung aktiviert ist, um Integrität und Ressourcennutzung Ihres AKS-Clusters und der darauf ausgeführten Workloads zu erfassen, informieren Sie sich über die Verwendung von Container Insights.