Freigeben über

Aktivieren der Überwachung für Azure Kubernetes Service (AKS) Cluster

Wie in Kubernetes Monitoring in Azure Monitor beschrieben, arbeiten mehrere Funktionen von Azure Monitor zusammen, um eine vollständige Überwachung Ihrer Azure Kubernetes Service (AKS) Cluster bereitzustellen. In diesem Artikel wird beschrieben, wie Sie die folgenden Features für AKS-Cluster aktivieren:

  • Prometheus-Metriken
  • Verwaltetes Grafana
  • Containerprotokollierung
  • Control-Plane-Protokolle

Voraussetzungen

Von Bedeutung

Wenn Ihre Cluster mithilfe einer Azure Private Link eine Verbindung mit dem Azure Monitor-Arbeitsbereich oder dem Log Analytics-Arbeitsbereich herstellen, lesen Sie Private Link für das Überwachen von virtuellen Maschinen und Kubernetes-Clustern in Azure Monitor aktivieren.

Erstellen von Arbeitsbereichen

In der folgenden Tabelle werden die Arbeitsbereiche beschrieben, die erforderlich sind, um die in diesem Artikel aktivierten Azure Monitor Features zu unterstützen. Wenn Sie noch nicht über einen Vorhandenen Arbeitsbereich jedes Typs verfügen, können Sie sie als Teil des Onboardingprozesses erstellen. Unter Design a Log Analytics workspace architecture finden Sie Anleitungen dazu, wie viele Arbeitsbereiche erstellt und wo sie platziert werden sollen.

Eigenschaft Arbeitsbereich Hinweise
Verwaltetes Prometheus Azure Monitor Arbeitsbereich Wenn Sie beim Onboarding 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.

Contributor Berechtigung reicht aus, um dem Addon das Senden von Daten an den Azure Monitor Arbeitsbereich zu ermöglichen. Sie benötigen Owner-Berechtigungen, um Ihren Azure Monitor-Arbeitsbereich mit Azure Managed Grafana zu verknüpfen und Metriken anzuzeigen. Dies ist erforderlich, da der Benutzer, der den Onboarding-Schritt durchführt, in der Lage sein muss, die Rolle der Azure Managed Grafana-Systemidentität Monitoring Reader für den Azure Monitor-Arbeitsbereich zuzuweisen, damit er die Metriken abfragen kann.
Containerprotokollierung
Control-Plane-Protokolle
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 sein. Weitere Informationen finden Sie unter Registrieren des Ressourcenanbieters.

Wenn Sie keinen vorhandenen Log Analytics Arbeitsbereich angeben, wird der Standardarbeitsbereich für die Ressourcengruppe verwendet. Wenn im Bereich des Clusters noch kein Standardarbeitsbereich vorhanden ist, wird ein Arbeitsbereich mit einem Namen im Format DefaultWorkspace-<GUID>-<Region>erstellt.

Eine Liste der unterstützten Zuordnungspaare für den Standardarbeitsbereich finden Sie unter Von Container Insights unterstützte Regionszuordnungen. Unter Configure Azure Monitor mit Netzwerksicherheitsperimeter finden Sie Anleitungen zum Konfigurieren des Arbeitsbereichs mit Netzwerksicherheitsperimeter.
Verwaltetes Grafana Azure Managed Grafana-Arbeitsbereich Linken Sie Ihren Grafana-Arbeitsbereich mit Ihrem Azure Monitor Arbeitsbereich, um die prometheus-Metriken aus Ihrem Cluster für Grafana-Dashboards zur Verfügung zu stellen.

Prometheus-Metriken und Containereinblicke

Hinweis

Die Verwendung von Application Insights zum Überwachen der Anwendungen, die auf Ihrem AKS-Cluster ausgeführt werden, mithilfe des OpenTelemetry Protocol (OTLP) für die Instrumentierung und Datensammlung befindet sich jetzt in der öffentlichen Vorschau. Siehe Monitor AKS-Anwendungen mit OpenTelemetry Protocol (OTLP) Eingeschränkte Vorschau.

Wenn Sie Prometheus und Containereinblicke für einen Cluster aktivieren, wird eine containerisierte Version des Azure Monitor-Agents im Cluster installiert. Sie können diese Features auf einem neuen oder vorhandenen Cluster gleichzeitig konfigurieren oder jedes Feature separat aktivieren.

Aktivieren Sie das Managed Grafana für Ihren Cluster gleichzeitig mit der Aktivierung des Scrapings von Prometheus-Metriken. Unter Link a Grafana workspace finden Sie Optionen zum Verbinden Ihres Azure Monitor Arbeitsbereichs und Azure Managed Grafana Arbeitsbereichs.

Voraussetzungen

  • 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
  • Die Authentifizierung mit verwalteter Identität ist der Standard in der CLI-Version 2.49.0 oder höher.
  • Die aks-preview Erweiterung muss über den Befehl az extension remove --name aks-preview werden.

Aktivieren von Prometheus-Metriken für einen AKS-Cluster

Aktivieren Sie Prometheus-Metriken für einen AKS-Cluster mithilfe der --enable-azure-monitor-metrics Option mit dem az aks create Befehl für einen neuen Cluster oder den az aks update Befehl für einen vorhandenen Cluster. Diese Option verwendet die in Default Prometheus-Metrikkonfiguration in Azure Monitor beschriebene Konfiguration. Informationen zum Ändern dieser Konfiguration finden Sie unter Anpassen des Scraping von Prometheus-Metriken im Azure Monitor Managed Service für Prometheus.

Befehlsbeispiele:

### 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]"

Optionale Parameter

Die Beispielbefehle ermöglichen die folgenden optionalen Parameter. Der Parametername unterscheidet sich für jeden, die Verwendung ist jedoch identisch.

Parameter Name und Beschreibung
Anmerkungsschlüssel --ksm-metric-annotations-allow-list

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 --ksm-metric-labels-allow-list

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 --enable-windows-recording-rules

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

Hinweis

Die Parameter, die mit --ksm-metric-annotations-allow-list und --ksm-metric-labels-allow-list festgelegt werden, können übersteuert oder alternativ mithilfe der ama-metrics-settings-configmap gesetzt werden.

Aktivieren von Container-Insights und Logging auf einem AKS-Cluster

Aktivieren Sie containererkenntnisse und Containerprotokollierung in einem AKS-Cluster mithilfe der --addon monitoring Option mit dem az aks create Befehl für einen neuen Cluster oder dem az aks enable-addon Befehl zum Aktualisieren eines vorhandenen Clusters.

Befehlsbeispiele:

### 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 custom log configuration file
az aks enable-addons --addon monitoring --name <cluster-name> --resource-group <cluster-resource-group-name> --workspace-resource-id <workspace-resource-id> --data-collection-settings dataCollectionSettings.json

Protokollkonfigurationsdatei

Um die Protokollsammlungseinstellungen für den Cluster anzupassen, können Sie die Konfiguration als JSON-Datei mit dem folgenden Format bereitstellen. Wenn Sie keine Konfigurationsdatei bereitstellen, werden die in der Tabelle angegebenen Standardeinstellungen verwendet.

{
  "interval": "1m",
  "namespaceFilteringMode": "Include",
  "namespaces": ["kube-system"],
  "enableContainerLogV2": true, 
  "streams": ["Microsoft-Perf", "Microsoft-ContainerLogV2"]
}

In der folgenden Tabelle werden die einzelnen Einstellungen in der Protokolldatei beschrieben:

Name Beschreibung
interval Bestimmt, wie oft der Agent Daten sammelt. Gültige Werte sind 1m - 30m in 1m-Intervallen Wenn sich der Wert außerhalb des zulässigen Bereichs befindet, wird standardmäßig 1m festgelegt.

Standard: 1 m.
namespaceFilteringMode Include: Erfasst nur Daten aus den Werten im Feld Namespaces.
Exclude: Erfasst Daten aus allen Namespaces mit Ausnahme der Werte im Feld Namespaces.
Off: Ignoriert mögliche ausgewählte Namespaces und sammelt Daten für alle Namespaces.

Standard: Aus
namespaces Array von durch Kommas getrennten Kubernetes-Namespaces zum Sammeln von Bestands- und Leistungsdaten basierend auf der namespaceFilteringMode.
Beispielsweise werden bei namespaces = [“kube-system“, „default“] mit der Einstellung Include nur Daten für diese beiden Namespaces erfasst. Bei der Einstellung Exclude sammelt der Agent Daten aus allen Namespaces mit Ausnahme der Namespaces kube-system und default. Bei der Einstellung Off sammelt der Agent Daten aus allen Namespaces, einschließlich kube-system und default. Ungültige und nicht erkannte Namespaces werden ignoriert.

Keiner.
enableContainerLogV2 Boolesches Flag zum Aktivieren des ContainerLogV2-Schemas. Wenn dieser Wert auf „true“ festgelegt ist, werden die Stdout/stderr-Protokolle in die Tabelle ContainerLogV2 aufgenommen. Andernfalls werden die Containerprotokolle in die Tabelle Containerlog aufgenommen, sofern nicht anders in der ConfigMap angegeben. Wenn Sie die einzelnen Datenströme angeben, müssen Sie die entsprechende Tabelle für „ContainerLog“ oder „ContainerLogV2“ einschließen.

Standard: Wahr
streams Ein Array von Tabellendatenströmen, die erfasst werden sollen. Eine Liste der gültigen Datenströme und der entsprechenden Tabellen finden Sie unter Stream-Werte .

Standard: Microsoft-ContainerInsights-Group-Default

Datenstromwerte

Wenn Sie die Tabellen angeben, die mit CLI oder BICEP/ARM gesammelt werden sollen, geben Sie Datenstromnamen an, die bestimmten Tabellen im Log Analytics Arbeitsbereich entsprechen. In der folgenden Tabelle sind die Datenstromnamen und die entsprechenden Tabellen aufgeführt.

Hinweis

Wenn Sie mit der Struktur einer Datensammlungsregel vertraut sind, können Sie die Datenstromnamen in dieser Tabelle im Abschnitt der Datenflüsse der Datensammlungsregel angegeben.

STREAM Container Insights-Tabelle
Microsoft-ContainerInventory ContainerInventory
Microsoft-ContainerLog ContainerLog
Microsoft-ContainerLogV2 ContainerLogV2
Microsoft-ContainerLogV2-HighScale ContainerLogV2 (Hoher Skalierungsmodus)1
Microsoft-ContainerNodeInventory Container-Knoten-Inventar
Microsoft-InsightsMetrics InsightsMetrics
Microsoft-KubeEvents KubeEvents
Microsoft-KubeMonAgentEvents KubeMonAgentEvents
Microsoft-KubeNodeInventory KubeNodeInventory
Microsoft-KubePodInventory KubePodInventory
Microsoft-KubePVInventory KubePVInventory
Microsoft-KubeServices KubeServices
Microsoft-Perf Perf
Microsoft-ContainerInsights-Group-Default Gruppendatenstrom, der alle oben genannten Datenströme enthält. 2

1 Verwenden Sie nicht sowohl Microsoft-ContainerLogV2 als auch Microsoft-ContainerLogV2-HighScale zusammen. Dies führt zu doppelten Daten. 2 Verwenden Sie den Gruppendatenstrom als Kurzform, um alle einzelnen Datenströme anzugeben. Wenn Sie einen bestimmten Satz von Datenströmen sammeln möchten, geben Sie jeden Datenstrom einzeln an, anstatt den Gruppendatenstrom zu verwenden.

Anwendbare Tabellen und Metriken

Die Einstellungen für die Sammlungshäufigkeit und Namespacefilterung gelten nicht für alle Protokolldaten. In den folgenden Tabellen sind die Tabellen im Log Analytics Arbeitsbereich zusammen mit den einstellungen aufgeführt, die für jeden gelten.

Tabellenname Intervall Namespaces? Bemerkungen
ContainerInventory Yes Yes
Container-Knoten-Inventar Yes Nein Die Einstellung zur Datensammlung für Namespaces ist nicht anwendbar, da Kubernetes Node keine Namespace-Ressource ist.
KubeNodeInventory Yes Nein Die Einstellung für die Datensammlung für Namespaces ist nicht anwendbar; Kubernetes Node ist keine Namespace-Ressource
KubePodInventory Yes Yes
KubePVInventory Yes Yes
KubeServices Yes Yes
KubeEvents Nein Yes Die Einstellung zur Datensammlung für das Intervall ist für Kubernetes Events nicht anwendbar
Perf Yes Yes Die Einstellung zur Datensammlung für Namespaces gilt nicht für die auf Kubernetes Node bezogenen Metriken, da Kubernetes Node kein Namespace-Objekt ist.
InsightsMetrics Yes Yes Die Datensammlungseinstellungen gelten nur für die Metriken, die die folgenden Namespaces sammeln: container.azm.ms/kubestate, , container.azm.ms/pvund container.azm.ms/gpu.

Hinweis

Die Namespacefilterung gilt nicht für ama-logs-Agent-Datensätze. Selbst wenn der Kube-System-Namespace unter ausgeschlossenen Namespaces aufgeführt ist, werden Datensätze, die einem Agentcontainer mit ama-logs zugeordnet sind, weiterhin aufgenommen.

Metrik-Namensraum Intervall Namespaces? Bemerkungen
Insights.container/nodes Yes Nein Node ist keine Namespace-Ressource.
Insights.container/pods Yes Yes
Insights.container/containers Yes Yes
Insights.container/persistentvolumes Yes Yes

Spezielle Szenarien

Verwenden Sie die folgenden Ressourcen für Konfigurationsanforderungen für bestimmte Szenarien:

Aktivieren von Steuerebenenprotokollen in einem AKS-Cluster

Steuerebenenprotokolle werden als Ressourcenprotokolle in Azure Monitor implementiert. Um diese Protokolle zu sammeln, erstellen Sie eine Diagnoseeinstellung für den Cluster. Senden Sie sie an den gleichen Log Analytics Arbeitsbereich wie Ihre Containerprotokolle.

Verwenden Sie den Befehl az monitor diagnostic-settings create, um eine Diagnoseeinstellung mit dem Azure CLI zu erstellen. Beschreibungen der zugehörigen Parameter finden Sie in der Dokumentation zu diesem Befehl.

Im folgenden Beispiel wird eine Diagnoseeinstellung erstellt, die alle Kubernetes-Kategorien an einen Log Analytics Arbeitsbereich sendet. Dies umfasst den ressourcenspezifischen Modus, um die Protokolle an bestimmte Tabellen zu senden, die in Supported Resource Logs für Microsoft.ContainerService/fleets aufgeführt sind.

az monitor diagnostic-settings create \
--name 'Collect control plane logs' \
--resource  /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ContainerService/managedClusters/<cluster-name> \
--workspace /subscriptions/<subscription ID>/resourcegroups/<resource group name>/providers/microsoft.operationalinsights/workspaces/<log analytics workspace name> \
--logs '[{"category": "karpenter-events","enabled": true},{"category": "kube-audit","enabled": true},
{"category": "kube-apiserver","enabled": true},{"category": "kube-audit-admin","enabled": true},{"category": "kube-controller-manager","enabled": true},{"category": "kube-scheduler","enabled": true},{"category": "cluster-autoscaler","enabled": true},{"category": "cloud-controller-manager","enabled": true},{"category": "guard","enabled": true},{"category": "csi-azuredisk-controller","enabled": true},{"category": "csi-azurefile-controller","enabled": true},{"category": "csi-snapshot-controller","enabled": true},{"category": "fleet-member-agent","enabled": true},{"category": "fleet-member-net-controller-manager","enabled": true},{"category": "fleet-mcs-controller-manager","enabled": true}]'
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--export-to-resource-specific true

Aktivieren Windows Metriken (Vorschau)

Windows-Metriksammlung ist für AKS-Cluster ab Version 6.4.0-main-02-22-2023-3ee44b9e des verwalteten Prometheus-Addon-Containers aktiviert. Durch das Onboarding in das Add-On Azure Monitor Metriken können die Windows DaemonSet-Pods mit der Ausführung in Ihren Knotenpools beginnen. Sowohl Windows Server 2019 als auch Windows Server 2022 werden unterstützt. Führen Sie die folgenden Schritte aus, um die Pods zum Sammeln von Metriken aus Ihren Windows Knotenpools zu aktivieren.

Hinweis

In windows-exporter-daemonset.yaml gibt es keine CPU-/Arbeitsspeicherbeschränkung, wodurch die Windows-Nodes möglicherweise überprovisioniert werden. Details 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 Ressourcengrenzen kann die Windows Knoten überprovisionieren und kann in extremen Fällen dazu führen, dass die Knoten unzuverlässig werden.

Installieren Sie den Windows Exporter

Installieren Sie windows-Exporter manuell auf AKS-Knoten, um auf Windows Metriken zuzugreifen, indem Sie die Datei windows-exporter-daemonset YAML bereitstellen. Aktivieren Sie die folgenden Kollektoren. Weitere Sammler finden Sie unter Prometheus-Exporter für Windows-Metriken.

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

Stellen Sie die YAML-Datei „windows-exporter-daemonset“ bereit. Wenn Taints im Knoten angewendet werden, müssen Sie die entsprechenden Toleranzen anwenden.

kubectl apply -f windows-exporter-daemonset.yaml

Aktivieren Windows Metriken

Setzen Sie die windowsexporter und windowskubeproxy Booleans in den Metrikeinstellungen ConfigMap auf true und wenden Sie sie auf den Cluster an. Siehe Anpassen der Sammlung von Prometheus-Metriken aus Ihrem Kubernetes-Cluster mithilfe von ConfigMap.

Aktivieren von Aufzeichnungsregeln

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

  • Wenn das Onboarding mit CLI erfolgt, schließen Sie die Option --enable-windows-recording-rulesein.
  • Wenn das Onboarding mithilfe einer ARM-Vorlage, Bicep oder Azure Policy erfolgt, legen Sie in der Parameterdatei enableWindowsRecordingRules auf true fest.
  • Wenn der Cluster bereits integriert ist, 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.

Ü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

Verifizieren Sie, dass Windows Knoten ordnungsgemäß bereitgestellt wurden

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

Die Anzahl der Pods sollte der Anzahl der Windows Knoten im Cluster entsprechen. 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

Containereinblicke und Protokollierung

Ü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

Verifizieren Sie, dass Windows Knoten ordnungsgemäß bereitgestellt wurden

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

Die Anzahl der Pods sollte der Anzahl der Windows Knoten im Cluster entsprechen. 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 Containerprotokollierungslö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 Befehl aks show, um herauszufinden, ob die Lösung aktiviert ist, die Log Analytics Arbeitsbereichsressourcen-ID und zusammenfassende Informationen zum Cluster.

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
    },
}

Verwandte Inhalte

  • Wenn Probleme beim Onboarding auftreten, lesen Sie das Handbuch zur Problembehandlung.
  • Erfahren Sie, wie Sie Kubernetes-Überwachungsdaten im Azure-Portal-Containerüberprüfung analysieren.
  • Last updated on