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:
- Verwaltetes Prometheus für die Metriksammlung
- Containererkenntnisse für die Protokollsammlung
- Managed Grafana zur Visualisierung.
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:
- Konfigurieren Sie die Datenerfassung und Kostenoptimierung in Container Insights mithilfe von Datenerfassungsregeln
Details zum Anpassen der Protokollsammlung, nachdem Sie die Überwachung aktiviert haben, einschließlich voreingestellter Kostenoptimierungskonfigurationen. - Bewährte Methoden für die Überwachung von Kubernetes mit Azure Monitor
Bewährte Methoden für die Überwachung von Kubernetes-Clustern, die von den fünf Säulen des Azure Well-Architected Frameworks organisiert sind, einschließlich Kostenoptimierung. - Kostenoptimierung in Azure Monitor
Bewährte Methoden zum Konfigurieren aller Features von Azure Monitor, um die Kosten zu optimieren und die Menge der von Ihnen gesammelten Daten zu begrenzen.
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
- Für das Onboarding müssen Sie mindestens Zugriff als Mitwirkender auf den Cluster haben.
- Sie benötigen Überwachungsleser oder Überwachungsmitwirkender, um Daten anzuzeigen, nachdem die Überwachung aktiviert wurde.
Voraussetzungen für verwaltetes Prometheus
- Der Cluster muss die Authentifizierung der verwalteten Identität verwenden.
- Die folgenden Ressourcenanbieter müssen im Abonnement des AKS-Clusters und des Azure Monitor-Arbeitsbereichs registriert sein:
- 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
- Voraussetzungen für Erweiterungen für Azure Arc-fähige Kubernetes-Cluster.
- Überprüfen Sie die Firewallanforderungen zusätzlich zu den Netzwerkanforderungen für Azure Arc-fähiges Kubernetes.
- Wenn Sie zuvor die Überwachung für AKS installiert haben, stellen Sie sicher, dass Sie die Überwachung deaktiviert haben, bevor Sie fortfahren, um Probleme während der Erweiterungsinstallation zu vermeiden.
- Wenn Sie zuvor die Überwachung auf einem Cluster mithilfe eines Skripts ohne Clustererweiterungen installiert haben, befolgen Sie die Anweisungen unter Deaktivieren der Überwachung Ihrer Kubernetes-Cluster, um dieses Helm-Diagramm zu löschen.
Hinweis
Die Arc-aktivierte Kubernetes-Erweiterung für Managed Prometheus (Vorschau) unterstützt die folgenden Konfigurationen nicht:
- Red Hat Openshift-Distributionen, einschließlich Azure Red Hat OpenShift (ARO)
- Windows-Knoten
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.
Funktion | Arbeitsbereich | Hinweise |
---|---|---|
Verwalteter 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, die Azure Managed Grafana-Systemidentitätsrolle Monitoring Reader für den Azure Monitor-Arbeitsbereich vergeben können muss, die Metriken abzufragen. |
Container Insights | Log Analytics-Arbeitsbereich | Sie können einen AKS-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 AKS-Cluster mit einem Log Analytics-Arbeitsbereich in einem anderen Abonnement verbinden, muss der Ressourcenanbieter Microsoft.ContainerService 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. |
Grafana (verwaltet) | 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.
Hinweis
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. Die für das Prometheus-Add-On erforderliche Konfiguration ist aufgrund der Einschränkung für private Verbindungen nicht regionsübergreifend verfügbar. Um dies zu beheben, erstellen Sie einen neuen DCE im AKS-Clusterspeicherort und eine neue DCRA (Zuordnung) in derselben AKS-Clusterregion. Ordnen Sie den neuen DCE dem AKS-Cluster zu, und nennen Sie die neue Zuordnung (DCRA) „configurationAccessEndpoint“. Vollständige Anweisungen zum Konfigurieren der DCEs, die Ihrem Azure Monitor-Arbeitsbereich zugeordnet sind, um eine private Verbindung für die Datenaufnahme zu verwenden, finden Sie unter Aktivieren von Private Link 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
- Az CLI-Version von 2.49.0 oder höher ist erforderlich.
- Die Erweiterung „aks-preview“ muss mithilfe des
az extension remove --name aks-preview
-Befehls von AKS-Clustern deinstalliert werden. - 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.
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.
Beispielbefehle
### 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 (Vorschau)
### 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]"
Jeder der Befehle kann die folgenden optionalen Parameter verwenden:
- AKS:
--ksm-metric-annotations-allow-list
Arc:--AzureMonitorMetrics.KubeStateMetrics.MetricAnnotationsAllowList
Eine durch Komma getrennte Liste von Kubernetes-Anmerkungsschlüsseln, die in der 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. Beispielsweisepods=[kubernetes.io/team,...],namespaces=[kubernetes.io/team],...
. - 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. Beispielsweisepods=[app],namespaces=[k8s-label-1,k8s-label-n,...],...
. - AKS:
--enable-windows-recording-rules
Ermöglicht es Ihnen, die Aufzeichnungsregelgruppen zu aktivieren, die für das ordnungsgemäße Funktionieren der Windows-Dashboards erforderlich sind.
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.
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ähige Cluster mit Weiterleitungsproxy
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 einen neuen AKS-Cluster im Azure-Portal erstellen, können Sie Prometheus, Container Insights und Grafana auf der Registerkarte Überwachung aktivieren. Aktivieren Sie dazu die Kontrollkästchen Containerprotokolle aktivieren, Prometheus-Metriken aktivieren und Grafana aktivieren.
Vorhandener Cluster (Prometheus, Container Insights und Grafana)
- Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.
- Wählen Sie im Dienstmenü unter Überwachung die Option Insights>Überwachung konfigurieren aus.
- Container Insights ist bereits aktiviert. Aktivieren Sie die Kontrollkästchen Prometheus-Metriken aktivieren und Grafana aktivieren. Wenn Sie über einen vorhandenen Azure Monitor-Arbeitsbereich und einen Garafana-Arbeitsbereich verfügen, werden diese für Sie ausgewählt.
- Wählen Sie die Option Erweiterte Einstellungen aus, um alternative Arbeitsbereiche auszuwählen oder neue zu erstellen. Mit der Einstellung Kostenvoreinstellungen können Sie die Standardauflistungsdetails ändern, um Ihre Überwachungskosten zu reduzieren. Weitere Informationen finden Sie unter Aktivieren von Kostenoptimierungseinstellungen.
- Wählen Sie Konfigurierenaus.
Vorhandener Cluster (nur Prometheus)
- Navigieren Sie im Azure-Portal zu Ihrem AKS-Cluster.
- Wählen Sie im Dienstmenü unter Überwachung die Option Insights>Überwachung konfigurieren aus.
- Aktivieren Sie das Kontrollkästchen Prometheus-Metriken aktivieren.
- Wählen Sie die Option Erweiterte Einstellungen aus, um alternative Arbeitsbereiche auszuwählen oder neue zu erstellen. Mit der Einstellung Kostenvoreinstellungen können Sie die Standardauflistungsdetails ändern, um Ihre Überwachungskosten zu reduzieren.
- 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.
Legen Sie beim Bereitstellen von Workloads Ressourcenarbeitsspeicher- und CPU-Grenzwerte für Container fest. 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 die 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.
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 Collectors 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
Wenden Sie die ama-metrics-settings-configmap auf Ihren Cluster an. Legen Sie die booleschen Werte
windowsexporter
undwindowskubeproxy
auftrue
fest. Weitere Informationen finden Sie unter ConfigMap-Einstellungen des Metrik-Add-Ons.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
auftrue
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.
- Wenn Sie das Onboarding mithilfe der CLI durchführen, beziehen Sie die Option
Überprüfen der Bereitstellung
Verwenden Sie das kubectl-Befehlszeilentool, um zu überprüfen, ob der Agent ordnungsgemäß bereitgestellt ist.
Verwalteter 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üfen der Bereitstellung der Lösung für Containererkenntnisse
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 der Befehlszeilenschnittstelle
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/Speicherort | 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/Speicherort | 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 Container Insights-Unterstützung für das Betriebssystem Windows Server 2022 befindet sich in der Vorschau.
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 ein- und ausgehend geöffnet sein, damit Metriken zur Leistung der Windows-Knoten und -Container erfasst werden können.
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.