**Unterstützung für die Verbesserung dieser Seite beitragen**
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Überwachung der Cluster-Leistung und Anzeige von Protokollen
Sie können Ihre Daten in Amazon EKS mit vielen verfügbaren Überwachungs- oder Protokollierungstools beobachten. Ihre Amazon EKS-Protokolldaten können an AWS Services oder Partner-Tools zur Datenanalyse gestreamt werden. In der sind viele Dienste verfügbar AWS-Managementkonsole , die Daten zur Behebung Ihrer Amazon EKS-Probleme bereitstellen. Sie können auch eine AWS-unterstützte Open-Source-Lösung für die [Überwachung der Amazon EKS-Infrastruktur](https://docs.aws.amazon.com/grafana/latest/userguide/solution-eks.html) verwenden.
Nachdem Sie im linken Navigationsbereich der Amazon-EKS-Konsole **Cluster** ausgewählt haben, können Sie den Zustand und die Details des Clusters anzeigen, indem Sie den Namen Ihres Clusters und die Registerkarte **Beobachtbarkeit** auswählen. Informationen zu vorhandenen Kubernetes-Ressourcen, die in Ihrem Cluster bereitgestellt werden, finden Sie unter [Kubernetes-Ressourcen anzeigen in der AWS-Managementkonsole](view-kubernetes-resources.md).
Die Überwachung ist ein wichtiger Bestandteil der Aufrechterhaltung der Zuverlässigkeit, Verfügbarkeit und Leistung von Amazon EKS und Ihren AWS Lösungen. Wir empfehlen Ihnen, Überwachungsdaten aus allen Teilen Ihrer AWS Lösung zu sammeln. Auf diese Weise können Sie Ausfälle, die sich über mehrere Punkte erstrecken, leichter debuggen. Bevor Sie mit der Überwachung von Amazon EKS beginnen, sollten Sie sicherstellen, dass für Ihren Überwachungsplan folgende Fragen beantwortet sind.
+ Was sind Ihre Ziele? Benötigen Sie Echtzeit-Benachrichtigungen, wenn Ihre Cluster drastisch skaliert werden?
+ Welche Ressourcen müssen beachtet werden?
+ Wie oft müssen Sie diese Ressourcen beobachten? Muss Ihr Unternehmen schnell auf Risiken reagieren?
+ Welche Tools möchten Sie verwenden? Wenn Sie AWS Fargate bereits als Teil Ihres Starts ausführen, können Sie den integrierten [Log-Router](fargate-logging.md) verwenden.
+ Wer soll die Überwachungsaufgaben ausführen?
+ An wen sollen Benachrichtigungen gesendet werden, wenn etwas schief geht?
## Überwachung und Protokollierung in Amazon EKS
Amazon EKS bietet integrierte Tools für die Überwachung und Protokollierung. Für unterstützte Versionen bietet das Dashboard zur Beobachtbarkeit Einblick in die Leistung Ihres Clusters. Es unterstützt Sie dabei, Probleme schnell zu erkennen, zu beheben und zu lösen. Zusätzlich zu den Überwachungsfeatures enthält es Listen, die auf den Audit-Protokollen der Steuerebene basieren. Die Kubernetes-Steuerebene stellt eine Reihe von Metriken zur Verfügung, die auch außerhalb der Konsole abgerufen werden können.
Die Protokollierung der Steuerebene zeichnet alle API-Aufrufe zu Ihren Clustern. Diese enthält Überwachungsinformationen darüber, welche Benutzer welche Aktionen an Ihren Clustern durchgeführt haben, sowie rollenbasierte Informationen. Weitere Informationen finden Sie unter [Protokollierung und Überwachung auf Amazon EKS](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/amazon-eks-logging-monitoring.html) in den * AWS präskriptiven Leitlinien*.
Die Protokollierung auf der Amazon EKS-Kontrollebene stellt Prüf- und Diagnoseprotokolle direkt von der Amazon EKS-Steuerebene zu den CloudWatch Protokollen in Ihrem Konto bereit. Diese Protokolle erleichtern Ihnen die Absicherung und Ausführung Ihrer Cluster. Sie können genau die Protokolltypen auswählen, die Sie benötigen, und die Protokolle werden als Protokollstreams an eine Gruppe für jeden Amazon EKS-Cluster gesendet CloudWatch. Weitere Informationen finden Sie unter [Protokolle der Kontrollebene an CloudWatch Logs senden](control-plane-logs.md).
**Anmerkung**
Wenn Sie die Amazon EKS-Authentifikatorprotokolle in Amazon überprüfen CloudWatch, werden die Einträge angezeigt, die Text enthalten, der dem folgenden Beispieltext ähnelt.
```
level=info msg="mapping IAM role" groups="[]" role="arn:aws: iam::111122223333:role/XXXXXXXXXXXXXXXXXX-NodeManagerRole-XXXXXXXX" username="eks:node-manager"
```
Einträge, die diesen Text enthalten, werden erwartet. Das `username` ist eine interne Amazon EKS-Servicerolle, die bestimmte Vorgänge für verwaltete Knotengruppen und Fargate ausführt.
Für eine detaillierte, anpassbare Protokollierung ist [Kubernetes-Protokollierung](https://kubernetes.io/docs/concepts/cluster-administration/logging/) verfügbar.
Amazon EKS ist in einen Service integriert AWS CloudTrail, der eine Aufzeichnung der Aktionen bereitstellt, die von einem Benutzer, einer Rolle oder einem AWS Service in Amazon EKS ausgeführt wurden. CloudTrail erfasst alle API-Aufrufe für Amazon EKS als Ereignisse. Zu den erfassten Aufrufen gehören Aufrufe von der Amazon-EKS-Konsole und Code-Aufrufe der Amazon-EKS-API-Operationen. Weitere Informationen finden Sie unter [API-Aufrufe als AWS-CloudTrail-Ereignisse protokollieren](logging-using-cloudtrail.md).
Der Kubernetes-API-Server stellt eine Reihe von Metriken zur Verfügung, die für die Überwachung und Analyse hilfreich sind. Weitere Informationen finden Sie unter [Überwachung Ihrer Cluster-Metriken mit Prometheus](prometheus.md).
Informationen zur Konfiguration von Fluent Bit für benutzerdefinierte CloudWatch Amazon-Protokolle finden Sie unter [Fluent Bit einrichten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html#Container-Insights-FluentBit-setup) im * CloudWatch Amazon-Benutzerhandbuch*.
## Überwachungs- und Protokollierungs-Tools für Amazon EKS
Amazon Web Services bietet verschiedene Tools, mit deren Hilfe Sie Amazon EKS überwachen können. Sie können einige Tools konfigurieren, um eine automatische Überwachung einzurichten, einige erfordern jedoch manuelle Anrufe. Wir empfehlen, dass Sie Überwachungsaufgaben so weit automatisieren, wie es Ihre Umgebung und Ihr vorhandenes Toolset zulassen.
Die folgende Tabelle beschreibt verschiedene Optionen für Überwachungs-Tools.
| Bereiche | Tool | Description | Einrichtung |
| --- | --- | --- | --- |
| Steuerebene | [Dashboard zur Beobachtbarkeit](observability-dashboard.md) | Für unterstützte Versionen bietet das Dashboard zur Beobachtbarkeit Einblick in die Leistung Ihres Clusters. Es unterstützt Sie dabei, Probleme schnell zu erkennen, zu beheben und zu lösen. | [Einrichtungsverfahren](observability-dashboard.md) |
| Anwendungen/Steuerebene | [Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) | Prometheus kann zur Überwachung von Metriken und Warnmeldungen für Anwendungen und die Steuerebene eingesetzt werden. | [Einrichtungsverfahren](prometheus.md) |
| Anwendungen | [CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) | CloudWatch Container Insights sammelt, aggregiert und fasst Metriken und Protokolle aus Ihren containerisierten Anwendungen und Microservices zusammen. | [Einrichtungsverfahren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) |
| Anwendungen | [AWS Distribution für (ADOT) OpenTelemetry ](https://aws-otel.github.io/docs/introduction) | ADOT kann korrelierte Metriken, Rückverfolgungsdaten und Metadaten sammeln und an AWS Überwachungsdienste oder Partner senden. Es kann über CloudWatch Container Insights eingerichtet werden. | [Einrichtungsverfahren](opentelemetry.md) |
| Anwendungen | [ DevOpsAmazon-Guru](https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-devops-guru-coverage-amazon-eks-metrics-cluster/) | Amazon DevOps Guru erkennt die Betriebsleistung und Verfügbarkeit auf Knotenebene. | [Einrichtungsverfahren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) |
| Anwendungen | [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) | AWS X-Ray empfängt Trace-Daten über Ihre Anwendung. Diese Trace-Daten enthalten ein- und ausgehende Anfragen und Metadaten zu diesen. Für Amazon EKS ist für die Implementierung das OpenTelemetry Add-on erforderlich. | [Einrichtungsverfahren](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html) |
| Anwendungen | [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) | CloudWatch stellt einige grundlegende Amazon EKS-Metriken in unterstützten Versionen kostenlos zur Verfügung. Sie können diese Funktionalität mit dem CloudWatch Observability Operator erweitern, um das Sammeln von Metriken, Protokollen und Trace-Daten zu verwalten. | [Einrichtungsverfahren](cloudwatch.md) |
Die folgende Tabelle beschreibt verschiedene Optionen für Protokollierungs-Tools.
| Bereiche | Tool | Description | Einrichtung |
| --- | --- | --- | --- |
| Steuerebene | [Dashboard zur Beobachtbarkeit](observability-dashboard.md) | Für unterstützte Versionen zeigt das Beobachtbarkeits-Dashboard Listen an, die auf den Audit-Protokollen der Steuerebene basieren. Es enthält auch Links zu Protokollen von Kontrollflugzeugen bei Amazon CloudWatch. | [Einrichtungsverfahren](observability-dashboard.md) |
| Anwendungen | [Einblicke in Amazon CloudWatch Container](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) | Amazon CloudWatch Container Insights sammelt, aggregiert und fasst Metriken und Protokolle aus Ihren containerisierten Anwendungen und Microservices zusammen. | [Einrichtungsverfahren](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-EKS-quickstart.html) |
| Steuerebene | [ CloudWatch Amazon-Protokolle](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) | Sie können Prüf- und Diagnoseprotokolle direkt von der Amazon EKS-Steuerebene an die CloudWatch Protokolle in Ihrem Konto senden. | [Einrichtungsverfahren](control-plane-logs.md) |
| Steuerebene | [AWS CloudTrail](logging-using-cloudtrail.md) | Protokolliert API-Aufrufe eines Benutzers, einer Rolle oder eines Service. | [Einrichtungsverfahren](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) |
| Mehrere Bereiche für AWS Fargate-Instanzen | [AWS Fargate-Protokollrouter](fargate-logging.md) | Bei AWS Fargate-Instances streamt der Log-Router Logs an AWS Dienste oder Partner-Tools. [Für Fluent Bit wird AWS](https://github.com/aws/aws-for-fluent-bit) verwendet. Protokolle können an andere AWS Dienste oder Partner-Tools gestreamt werden. | [Einrichtungsverfahren](fargate-logging.md) |
# Überwachen Ihres Clusters im Dashboard „Beobachtbarkeit“
Die Amazon-EKS-Konsole enthält ein Beobachtbarkeits-Dashboard, das Einblick in die Leistung Ihres Clusters bietet. Die darin enthaltenen Informationen helfen Ihnen, Probleme schnell zu erkennen, zu beheben und zu lösen. Sie können den entsprechenden Abschnitt des Beobachtbarkeits-Dashboards öffnen, indem Sie einen Eintrag in der Zusammenfassung zu **Zustand und Leistung** auswählen. Diese Zusammenfassung ist an mehreren Stellen enthalten, darunter auch auf der Registerkarte **Beobachtbarkeit**.
Das Dashboard zur Beobachtbarkeit ist in mehrere Registerkarten unterteilt.
## Zusammenfassung
In der **Zusammenfassung zu Integrität und Leistung** wird die Anzahl der Elemente in verschiedenen Kategorien aufgeführt. Jede Zahl dient als Hyperlink zu einer Stelle im Dashboard Beobachtbarkeit mit einer Liste für diese Kategorie.
## Cluster-Integrität
**Cluster-Integrität** liefert wichtige Benachrichtigungen, die Sie beachten sollten. Bei einigen davon müssen Sie möglicherweise so schnell wie möglich Maßnahmen ergreifen. In dieser Liste finden Sie Beschreibungen und die betroffenen Ressourcen. Cluster-Integrität besteht aus zwei Tabellen: **Integritätsprobleme** und **Konfigurationserkenntnisse**. Um den Status der **Integritätsprobleme** zu aktualisieren, klicken Sie auf die Schaltfläche „Aktualisieren“ ( ↻ ). **Konfigurationserkenntnisse** werden automatisch alle 24 Stunden aktualisiert und können nicht manuell aktualisiert werden
Weitere Informationen zu **Integritätsprobleme** finden Sie unter [FAQs Cluster-Integritäts- und Fehlercodes mit Lösungspfaden](troubleshooting.md#cluster-health-status). Weitere Informationen zu **Konfigurationserkenntnisse** finden Sie unter [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md).
## Überwachen der Steuerebene
Die Registerkarte **Überwachung der Steuerebene** ist in drei Abschnitte unterteilt, die Ihnen jeweils bei der Überwachung und Fehlerbehebung der Steuerebene Ihres Clusters behilflich sind.
### Metriken
Für Cluster mit Kubernetes-Version `1.28` und höher werden im Abschnitt „Metriken“ Diagramme mit verschiedenen **Metriken** angezeigt, die für verschiedene Komponenten der Steuerebene erfasst wurden.
Sie können den Zeitbereich für die X-Achse jedes Diagramms festlegen, indem Sie oben im Abschnitt eine Auswahl treffen. Mit der Schaltfläche „Aktualisieren“ (↻) können Sie die Daten aktualisieren. Für jedes einzelne Diagramm öffnet die Schaltfläche mit den vertikalen Ellipsen () ein Menü mit Optionen von CloudWatch.
Diese und weitere Metriken sind automatisch als grundlegende Überwachungsmetriken CloudWatch unter dem `AWS/EKS` Namespace verfügbar. Weitere Informationen finden Sie unter [Grundlegende Überwachung und detaillierte Überwachung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-basic-detailed.html) im * CloudWatch Amazon-Benutzerhandbuch*. Ausführlichere Metriken, Visualisierungen und Einblicke finden Sie unter [Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) im * CloudWatch Amazon-Benutzerhandbuch*. Wenn Sie eine Prometheus-basierte Überwachung bevorzugen, lesen Sie [Überwachung Ihrer Cluster-Metriken mit Prometheus](prometheus.md).
In der folgenden Tabelle werden die verfügbaren Metriken beschrieben.
| Metrik | Description |
| --- | --- |
| APIServer Anfragen | Die Anzahl der Anfragen pro Minute, die an den API-Server gestellt werden. |
| APIServer Gesamtzahl der Anfragen 4XX | Die Anzahl der API-Serveranfragen pro Minute, die HTTP-4XX-Antwortcodes (clientseitige Fehler) aufwiesen. |
| APIServer Gesamtzahl der Anfragen 5XX | Die Anzahl der API-Serveranfragen pro Minute, die HTTP-5XX-Antwortcodes (serverseitige Fehler) aufwiesen. |
| APIServer Gesamtzahl der Anfragen 429 | Die Anzahl der API-Serveranfragen pro Minute mit HTTP-429-Antwortcodes (zu viele Anfragen). |
| Speichergröße | Die Größe der Speicherdatenbank (`etcd`). |
| Scheduler-Versuche | Die Anzahl der Versuche, Pods zu planen, nach den Ergebnissen „nicht planbar“, „Fehler“ und „geplant“. |
| Ausstehende Pods | Die Anzahl der ausstehenden Pods nach Warteschlangentyp „aktiv“, „Backoff“, „nicht planbar“ und „gesperrt“. |
| Latenzzeit bei API-Serveranfragen | Die Latenzzeit für API-Serveranfragen. |
| Aktuelle laufende Anfragen an den API-Server | Die aktuellen laufenden Anfragen für den API-Server. |
| Webhook-Anfragen | Die Webhook-Anfragen pro Minute. |
| Abgelehnte Webhook-Anfragen | Die Anzahl der abgelehnten Webhook-Anfragen. |
| Latenzzeit bei Webhook-Anfragen P99 | Die 99. Perzentil-Latenzzeit von externen Webhook-Anfragen von Drittanbietern. |
### CloudWatch Einblicke protokollieren
Im Abschnitt **CloudWatch Log Insights** werden verschiedene Listen angezeigt, die auf den Auditprotokollen der Kontrollebene basieren. Die Amazon EKS-Steuerebenenprotokolle müssen aktiviert sein, um diese Funktion nutzen zu können. Dies können Sie **im CloudWatch Abschnitt Kontrollebenenprotokolle anzeigen im** tun.
Sobald ausreichend Zeit für die Datenerfassung vergangen ist, können Sie **Alle Abfragen ausführen** oder die Option **Abfrage für eine einzelne Liste ausführen** wählen. Jedes Mal, CloudWatch wenn Sie Abfragen ausführen, fallen zusätzliche Kosten an. Wählen Sie oben in diesem Abschnitt den Zeitraum aus, für den Sie die Ergebnisse anzeigen möchten. Wenn Sie eine erweiterte Steuerung für eine Abfrage wünschen, können Sie „**Anzeigen in CloudWatch**“ wählen. Auf diese Weise können Sie eine Abfrage CloudWatch an Ihre Bedürfnisse anpassen.
Weitere Informationen finden Sie unter [Analysieren von Protokolldaten mit CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) im Amazon CloudWatch Logs-Benutzerhandbuch.
### Logs auf der Kontrollebene anzeigen CloudWatch
Wählen Sie **Protokollierung verwalten**, um die verfügbaren Protokolltypen zu aktualisieren. Nachdem Sie die Protokollierung aktiviert haben, dauert es einige Minuten, bis die CloudWatch Protokolle in den Protokollen angezeigt werden. Wenn ausreichend Zeit verstrichen ist, wählen Sie einen der Links **Anzeigen** in diesem Abschnitt, um zum entsprechenden Protokoll zu navigieren.
Weitere Informationen finden Sie unter [Protokolle der Kontrollebene an CloudWatch Logs senden](control-plane-logs.md).
## Cluster-Erkenntnisse
Die Tabelle **Upgrade-Erkenntnisse** zeigt sowohl Probleme auf und empfiehlt Korrekturmaßnahmen, wodurch der Validierungsprozess für das Upgrade auf neue Kubernetes-Versionen beschleunigt wird. Amazon EKS scannt Cluster automatisch anhand einer Liste potenzieller Probleme, die sich auf das Upgrade der Kubernetes-Version auswirken könnten. Die Tabelle **Upgrade-Erkenntnisse** listet die von Amazon EKS für diesen Cluster durchgeführten Erkenntnisprüfungen zusammen mit den zugehörigen Statusmeldungen auf.
Amazon EKS verwaltet und aktualisiert regelmäßig die Liste der Prüfungen, die auf der Grundlage von Bewertungen der Änderungen im Kubernetes-Projekt sowie der Amazon-EKS-Serviceänderungen im Zusammenhang mit neuen Versionen durchgeführt werden müssen. Die Amazon-EKS-Konsole aktualisiert automatisch den Status jeder Erkenntnis, der in der Spalte „Letzte Aktualisierungszeit“ angezeigt wird.
Weitere Informationen finden Sie unter [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md).
## Probleme mit dem Zustand des Knotens
Der Amazon-EKS-Knotenüberwachungsagent liest automatisch Knotenprotokolle, um Zustandsprobleme zu erkennen. Unabhängig von der Einstellung für die automatische Reparatur werden alle Probleme mit der Knoten-Integrität gemeldet, sodass Sie diese bei Bedarf untersuchen können. Wenn ein Problemtyp ohne Beschreibung aufgeführt ist, finden Sie die Beschreibung in dem zugehörigen Popover-Element.
Wenn Sie die Seite aktualisieren, werden alle gelösten Probleme aus der Liste entfernt. Wenn die automatische Reparatur aktiviert ist, können vorübergehend einige Integritätsprobleme gemeldet werden, die ohne Ihr Eingreifen behoben werden. Probleme, die von der automatischen Reparatur nicht unterstützt werden, erfordern je nach Art möglicherweise manuelles Eingreifen.
Damit Probleme mit der Knotenintegrität gemeldet werden, muss Ihr Cluster Amazon EKS Auto Mode verwenden oder über das Add-On für den Knoten-Überwachungsagenten verfügen. Weitere Informationen finden Sie unter [Erkennen Sie Probleme mit dem Knotenstatus und aktivieren Sie die automatische Knotenreparatur](node-health.md).
## EKS-Funktionen
Im Abschnitt **Capabilities** werden der Status und der Zustand Ihrer EKS-Capability-Ressourcen im Cluster angezeigt. Integritäts- und Statusbenachrichtigungen für beide Funktionen und ihre verwalteten Kubernetes-Ressourcen in Ihrem Cluster können hier überwacht werden. Wenn Sie die Seite aktualisieren, werden alle gelösten Probleme aus der Liste entfernt.
Weitere Informationen finden Sie unter [Mit Capability-Ressourcen arbeiten](working-with-capabilities.md).
# Überwachen Sie den Kubernetes-Workload-Traffic mit Container Network Observability
Amazon EKS bietet erweiterte Funktionen zur Netzwerkbeobachtbarkeit, die tiefere Einblicke in Ihre Container-Netzwerkumgebung bieten. Diese Funktionen helfen Ihnen dabei, Ihre Kubernetes-Netzwerklandschaft in besser zu verstehen, zu überwachen und Fehler zu beheben. AWS Dank der verbesserten Beobachtbarkeit von Container-Netzwerken können Sie detaillierte, netzwerkbezogene Metriken für eine bessere proaktive Erkennung von Anomalien im Cluster-Traffic, AZ-übergreifenden Flows und Diensten nutzen. AWS Mithilfe dieser Metriken können Sie die Systemleistung messen und die zugrunde liegenden Metriken mithilfe Ihres bevorzugten Observability-Stacks visualisieren.
Darüber hinaus bietet Amazon EKS jetzt Netzwerküberwachungsvisualisierungen in der AWS Konsole, die die präzise Fehlerbehebung beschleunigen und verbessern und so eine schnellere Ursachenanalyse ermöglichen. Sie können diese visuellen Funktionen auch nutzen, um Top-Talker und Netzwerkflüsse zu identifizieren, die zu erneuten Übertragungen und Timeouts bei der erneuten Übertragung führen, wodurch blinde Flecken bei Vorfällen beseitigt werden.
Diese Funktionen werden von [Amazon CloudWatch Network Flow Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor.html) aktiviert.
## Anwendungsfälle
### Messen Sie die Netzwerkleistung, um Anomalien zu erkennen
Mehrere Teams verwenden standardmäßig einen Observability-Stack, der es ihnen ermöglicht, die Leistung ihres Systems zu messen, Systemmetriken zu visualisieren und bei Überschreitung eines bestimmten Schwellenwerts alarmiert zu werden. Die Beobachtbarkeit von Containernetzwerken in EKS passt genau darauf an, indem wichtige Systemmetriken offengelegt werden, die Sie auswerten können, um die Beobachtbarkeit der Netzwerkleistung Ihres Systems auf Pod- und Worker-Node-Ebene zu erweitern.
### Nutzen Sie Konsolenvisualisierungen für eine genauere Fehlerbehebung
Falls Ihr Überwachungssystem einen Alarm ausgibt, sollten Sie sich auf den Cluster und die Arbeitslast konzentrieren, von denen das Problem herrührt. Um dies zu unterstützen, können Sie Visualisierungen in der EKS-Konsole nutzen, um den Untersuchungsumfang auf Clusterebene einzugrenzen und die Offenlegung der Netzwerkflüsse zu beschleunigen, die für die meisten Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und das übertragene Datenvolumen verantwortlich sind.
### Verfolgen Sie Top-Talker in Ihrer Amazon EKS-Umgebung
Viele Teams verwenden EKS als Grundlage für ihre Plattformen und machen es somit zum Mittelpunkt der Netzwerkaktivitäten einer Anwendungsumgebung. Mithilfe der Netzwerküberwachungsfunktionen in dieser Funktion können Sie nachverfolgen, welche Workloads für den meisten Datenverkehr (gemessen am Datenvolumen) innerhalb des Clusters AZs, über und für den Verkehr zu externen Zielen innerhalb AWS (DynamoDB und S3) und außerhalb der AWS Cloud (Internet oder lokal) verantwortlich sind. Darüber hinaus können Sie die Leistung jedes dieser Datenflüsse anhand von Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und übertragenen Daten überwachen.
## Features
1. Leistungsmetriken — Mit dieser Funktion können Sie netzwerkbezogene Systemmetriken für Pods und Worker-Knoten direkt aus dem Network Flow Monitor (NFM) -Agenten abrufen, der in Ihrem EKS-Cluster ausgeführt wird.
1. Service Map — Diese Funktion visualisiert dynamisch die Interkommunikation zwischen Workloads im Cluster, sodass Sie wichtige Kennzahlen (Retransmissions — RT, Retransmission Timeouts — RTO und übertragene Daten — DT) im Zusammenhang mit Netzwerkströmen zwischen kommunizierenden Pods schnell offenlegen können.
1. Flow-Tabelle — Mit dieser Tabelle können Sie die Top-Talker der Kubernetes-Workloads in Ihrem Cluster aus drei verschiedenen Blickwinkeln überwachen: Serviceansicht, Clusteransicht und externe Ansicht. AWS Für jede Ansicht können Sie die erneuten Übertragungen, die Timeouts für die erneute Übertragung und die zwischen dem Quell-Pod und seinem Ziel übertragenen Daten sehen.
+ AWS Serviceansicht: Zeigt die Top-Talker zu AWS Diensten an (DynamoDB und S3)
+ Cluster-Ansicht: Zeigt die Top-Talker innerhalb des Clusters an (von Ost ← nach → West)
+ Externe Ansicht: Zeigt die Top-Talker zu clusterexternen Zielen außerhalb AWS
## Erste Schritte
Aktivieren Sie zunächst Container Network Observability in der EKS-Konsole für einen neuen oder vorhandenen Cluster. Dadurch wird die Erstellung von Network Flow Monitor (NFM) -Abhängigkeiten ([Scope](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateScope.html) - und [Monitor-Ressourcen](https://docs.aws.amazon.com/networkflowmonitor/2.0/APIReference/API_CreateMonitor.html)) automatisiert. Darüber hinaus müssen Sie das [Network Flow Monitor Agent-Add-on](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-agents-kubernetes-eks.html) installieren. Alternativ können Sie diese Abhängigkeiten mithilfe von [EKS APIs](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html) (für das ` AWS CLI` Add-On), [NFM APIs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-API-operations.html) oder Infrastructure as Code (wie [Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/networkflowmonitor_monitor)) installieren. Sobald diese Abhängigkeiten eingerichtet sind, können Sie Ihr bevorzugtes Überwachungstool so konfigurieren, dass Netzwerkleistungskennzahlen für Pods und Worker-Knoten vom NFM-Agenten abgerufen werden. Um die Netzwerkaktivität und Leistung Ihrer Workloads zu visualisieren, können Sie im Observability-Dashboard des Clusters unter der Registerkarte „Netzwerk“ zur EKS-Konsole navigieren.
Wenn Sie Network Flow Monitor in EKS verwenden, können Sie Ihren bestehenden Observability-Workflow und Ihren Technologie-Stack beibehalten und gleichzeitig eine Reihe zusätzlicher Funktionen nutzen, die es Ihnen ermöglichen, die Netzwerkschicht Ihrer EKS-Umgebung besser zu verstehen und zu optimieren. Weitere Informationen zu den [Preisen von Network Flow Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor.pricing.html) finden Sie hier.
## Voraussetzungen und wichtige Hinweise
1. Wie oben erwähnt, werden die zugrunde liegenden NFM-Ressourcenabhängigkeiten (Scope und Monitor) automatisch in Ihrem Namen erstellt, wenn Sie Container Network Observability von der EKS-Konsole aus aktivieren, und Sie werden durch den Installationsprozess des EKS-Add-ons für NFM geführt.
1. Wenn Sie diese Funktion mithilfe von Infrastructure as Code (IaC) wie Terraform aktivieren möchten, müssen Sie die folgenden Abhängigkeiten in Ihrem IaC definieren: NFM Scope, NFM Monitor, EKS-Add-on für NFM. Darüber hinaus müssen Sie dem EKS-Add-On mithilfe von [Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) - oder [IAM-Rollen](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) für Dienstkonten (IRSA) die [entsprechenden Berechtigungen](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) gewähren.
1. Sie müssen eine Mindestversion von 1.1.0 für das EKS-Add-on des NFM-Agenten ausführen.
1. Sie müssen Version 6.21.0 oder höher des [Terraform AWS Providers verwenden, um die Network Flow Monitor-Ressourcen](https://github.com/hashicorp/terraform-provider-aws) zu unterstützen.
### Erforderliche IAM-Berechtigungen
#### EKS-Add-on für den NFM-Agenten
Sie können die `CloudWatchNetworkFlowMonitorAgentPublishPolicy` [AWS verwaltete Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchNetworkFlowMonitorAgentPublishPolicy.html) mit Pod Identity verwenden. Diese Richtlinie enthält Berechtigungen für den NFM-Agenten, Telemetrieberichte (Metriken) an einen Network Flow Monitor-Endpunkt zu senden.
```
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"networkflowmonitor:Publish"
],
"Resource" : "*"
}
]
}
```
#### Container-Netzwerk-Observability in der EKS-Konsole
Die folgenden Berechtigungen sind erforderlich, um die Funktion zu aktivieren und die Service-Map und die Flow-Tabelle in der Konsole zu visualisieren.
```
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect": "Allow",
"Action": [
"networkflowmonitor:ListScopes",
"networkflowmonitor:ListMonitors",
"networkflowmonitor:GetScope",
"networkflowmonitor:GetMonitor",
"networkflowmonitor:CreateScope",
"networkflowmonitor:CreateMonitor",
"networkflowmonitor:TagResource",
"networkflowmonitor:StartQueryMonitorTopContributors",
"networkflowmonitor:StopQueryMonitorTopContributors",
"networkflowmonitor:GetQueryStatusMonitorTopContributors",
"networkflowmonitor:GetQueryResultsMonitorTopContributors"
],
"Resource": "*"
}
]
}
```
## Verwenden von AWS CLI, EKS-API und NFM-API
```
#!/bin/bash
# Script to create required Network Flow Monitor resources
set -e
CLUSTER_NAME="my-eks-cluster"
CLUSTER_ARN="arn:aws:eks:{Region}:{Account}:cluster/{ClusterName}"
REGION="us-west-2"
AGENT_NAMESPACE="amazon-network-flow-monitor"
echo "Creating Network Flow Monitor resources..."
# Check if Network Flow Monitor agent is running in the cluster
echo "Checking for Network Flow Monitor agent in cluster..."
if kubectl get pods -n "$AGENT_NAMESPACE" --no-headers 2>/dev/null | grep -q "Running"; then
echo "Network Flow Monitor agent exists and is running in the cluster"
else
echo "Network Flow Monitor agent not found. Installing as EKS addon..."
aws eks create-addon \
--cluster-name "$CLUSTER_NAME" \
--addon-name "$AGENT_NAMESPACE" \
--region "$REGION"
echo "Network Flow Monitor addon installation initiated"
fi
# Get Account ID
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
echo "Cluster ARN: $CLUSTER_ARN"
echo "Account ID: $ACCOUNT_ID"
# Check for existing scope
echo "Checking for existing Network Flow Monitor Scope..."
EXISTING_SCOPE=$(aws networkflowmonitor list-scopes --region $REGION --query 'scopes[0].scopeArn' --output text 2>/dev/null || echo "None")
if [ "$EXISTING_SCOPE" != "None" ] && [ "$EXISTING_SCOPE" != "null" ]; then
echo "Using existing scope: $EXISTING_SCOPE"
SCOPE_ARN=$EXISTING_SCOPE
else
echo "Creating new Network Flow Monitor Scope..."
SCOPE_RESPONSE=$(aws networkflowmonitor create-scope \
--targets "[{\"targetIdentifier\":{\"targetId\":{\"accountId\":\"${ACCOUNT_ID}\"},\"targetType\":\"ACCOUNT\"},\"region\":\"${REGION}\"}]" \
--region $REGION \
--output json)
SCOPE_ARN=$(echo $SCOPE_RESPONSE | jq -r '.scopeArn')
echo "Scope created: $SCOPE_ARN"
fi
# Create Network Flow Monitor with EKS Cluster as local resource
echo "Creating Network Flow Monitor..."
MONITOR_RESPONSE=$(aws networkflowmonitor create-monitor \
--monitor-name "${CLUSTER_NAME}-monitor" \
--local-resources "type=AWS::EKS::Cluster,identifier=${CLUSTER_ARN}" \
--scope-arn "$SCOPE_ARN" \
--region $REGION \
--output json)
MONITOR_ARN=$(echo $MONITOR_RESPONSE | jq -r '.monitorArn')
echo "Monitor created: $MONITOR_ARN"
echo "Network Flow Monitor setup complete!"
echo "Monitor ARN: $MONITOR_ARN"
echo "Scope ARN: $SCOPE_ARN"
echo "Local Resource: AWS::EKS::Cluster (${CLUSTER_ARN})"
```
## Verwendung von Infrastruktur als Code (IaC)
### Terraform
Wenn Sie Terraform zur Verwaltung Ihrer AWS Cloud-Infrastruktur verwenden, können Sie die folgenden Ressourcenkonfigurationen einbeziehen, um Container Network Observability für Ihren Cluster zu aktivieren.
#### NFM-Geltungsbereich
```
data "aws_caller_identity" "current" {}
resource "aws_networkflowmonitor_scope" "example" {
target {
region = "us-east-1"
target_identifier {
target_type = "ACCOUNT"
target_id {
account_id = data.aws_caller_identity.current.account_id
}
}
}
tags = {
Name = "example"
}
}
```
#### NFM-Monitor
```
resource "aws_networkflowmonitor_monitor" "example" {
monitor_name = "eks-cluster-name-monitor"
scope_arn = aws_networkflowmonitor_scope.example.scope_arn
local_resource {
type = "AWS::EKS::Cluster"
identifier = aws_eks_cluster.example.arn
}
remote_resource {
type = "AWS::Region"
identifier = "us-east-1" # this must be the same region that the cluster is in
}
tags = {
Name = "example"
}
}
```
#### EKS-Add-on für NFM
```
resource "aws_eks_addon" "example" {
cluster_name = aws_eks_cluster.example.name
addon_name = "aws-network-flow-monitoring-agent"
}
```
## Funktionsweise
### Leistungsmetriken
#### Systemmetriken
Wenn Sie Drittanbieter-Tools (3P) zur Überwachung Ihrer EKS-Umgebung (wie Prometheus und Grafana) verwenden, können Sie die unterstützten Systemmetriken direkt vom Network Flow Monitor-Agenten abrufen. Diese Metriken können an Ihren Monitoring-Stack gesendet werden, um die Messung der Netzwerkleistung Ihres Systems auf Pod- und Worker-Node-Ebene zu erweitern. Die verfügbaren Metriken sind in der Tabelle unter Unterstützte Systemmetriken aufgeführt.
![\[Veranschaulichung der Systemmetriken\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/nfm-eks-metrics-workflow.png)
Um diese Metriken zu aktivieren, überschreiben Sie während des Installationsvorgangs die folgenden Umgebungsvariablen mithilfe der Konfigurationsvariablen (siehe: https://aws.amazon.com/blogs/ amazon-eks-add-ons containers/ -advanced-configuration/):
```
OPEN_METRICS:
Enable or disable open metrics. Disabled if not supplied
Type: String
Values: [“on”, “off”]
OPEN_METRICS_ADDRESS:
Listening IP address for open metrics endpoint. Defaults to 127.0.0.1 if not supplied
Type: String
OPEN_METRICS_PORT:
Listening port for open metrics endpoint. Defaults to 80 if not supplied
Type: Integer
Range: [0..65535]
```
#### Metriken auf Flussebene
Darüber hinaus erfasst Network Flow Monitor Netzwerkflussdaten zusammen mit Metriken auf Flussebene: Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und übertragene Daten. Diese Daten werden von Network Flow Monitor verarbeitet und in der EKS-Konsole visualisiert, um den Datenverkehr in der Umgebung Ihres Clusters zu ermitteln und anhand dieser Metriken auf Flussebene zu ermitteln, wie er abschneidet.
Das folgende Diagramm zeigt einen Workflow, in dem beide Arten von Metriken (System- und Flow-Ebene) genutzt werden können, um mehr betriebliche Informationen zu gewinnen.
![\[Veranschaulichung des Workflows mit unterschiedlichen Leistungskennzahlen\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/nfm-eks-metrics-types-workflow.png)
1. Das Plattformteam kann Systemmetriken in seinem Monitoring-Stack sammeln und visualisieren. Wenn Warnmeldungen vorhanden sind, können sie mithilfe der Systemmetriken des NFM-Agenten Netzwerkanomalien oder Probleme erkennen, die sich auf Pods oder Worker-Knoten auswirken.
1. Als nächsten Schritt können Plattformteams die nativen Visualisierungen in der EKS-Konsole nutzen, um den Untersuchungsbereich weiter einzugrenzen und die Fehlerbehebung auf der Grundlage von Ablaufdarstellungen und den zugehörigen Metriken zu beschleunigen.
Wichtiger Hinweis: Das Scraping von Systemmetriken aus dem NFM-Agenten und der Prozess, bei dem der NFM-Agent Metriken auf Flow-Ebene an das NFM-Backend überträgt, sind unabhängige Prozesse.
##### Unterstützte Systemmetriken
Wichtiger Hinweis: Systemmetriken werden im [OpenMetrics](https://openmetrics.io/)Format exportiert.
| Metrikname | Typ | Dimensionen | Description |
| --- | --- | --- | --- |
| ingress\$1flow | Messinstrument | instance\$1id, iface, pod, namespace, node | Anzahl eingehender TCP-Datenflüsse () TcpPassiveOpens |
| Ausgangsfluss | Messinstrument | instance\$1id, iface, pod, namespace, node | Anzahl der ausgehenden TCP-Datenflüsse () TcpActiveOpens |
| Eingangspakete | Messinstrument | instance\$1id, iface, pod, namespace, node | Anzahl eingehender Pakete (Delta) |
| ausgehende Pakete | Messinstrument | instance\$1id, iface, pod, namespace, node | Anzahl der ausgehenden Pakete (Delta) |
| Ingress\$1Bytes | Messinstrument | instance\$1id, iface, pod, namespace, node | Anzahl der eingehenden Byte (Delta) |
| Ausgangsbytes | Messinstrument | instance\$1id, iface, pod, namespace, node | Anzahl der ausgehenden Byte (Delta) |
| bw\$1in\$1allowance\$1exceeded | Messinstrument | instance\$1id, eni, Knoten | Pakete queued/dropped aufgrund der Bandbreitenbeschränkung für eingehende Nachrichten |
| bw\$1out\$1allowance\$1exceeded | Messinstrument | instance\$1id, eni, Knoten | Pakete queued/dropped aufgrund der Bandbreitenbeschränkung für ausgehende Nachrichten |
| pps\$1allowance\$1exceeded | Messinstrument | instance\$1id, eni, Knoten | Pakete queued/dropped aufgrund des bidirektionalen PPS-Limits |
| conntrack\$1allowance\$1exceeded | Messinstrument | instance\$1id, eni, Knoten | Pakete wurden aufgrund des Limits für die Verbindungsverfolgung verworfen |
| linklocal\$1allowance\$1exceeded | Messinstrument | instance\$1id, eni, Knoten | Pakete wurden aufgrund des PPS-Limits für den lokalen Proxydienst verworfen |
##### Unterstützte Metriken auf Flussebene
| Metrikname | Typ | Description |
| --- | --- | --- |
| TCP-Neuübertragungen | Zähler | Gibt an, wie oft ein Absender ein Paket erneut sendet, das während der Übertragung verloren gegangen oder beschädigt wurde. |
| Timeouts bei der TCP-Neuübertragung | Zähler | Gibt an, wie oft ein Absender eine Wartezeit eingeleitet hat, um festzustellen, ob ein Paket während der Übertragung verloren gegangen ist. |
| Übertragene Daten (Byte) | Zähler | Datenmenge, die für einen bestimmten Datenfluss zwischen einer Quelle und einem Ziel übertragen wird. |
### Servicekarte und Datenflusstabelle
![\[Veranschaulichung der Funktionsweise von NFM mit EKS\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/nfm-eks-workflow.png)
1. Nach der Installation wird der Network Flow Monitor-Agent DaemonSet auf jedem Worker-Node ausgeführt und erfasst alle 30 Sekunden die 500 wichtigsten Netzwerkflüsse (basierend auf dem übertragenen Datenvolumen).
1. Diese Netzwerkflüsse sind in die folgenden Kategorien unterteilt: Intra AZ, Inter AZ, EC2 → S3, EC2 → DynamoDB (DDB) und Unclassified. Jedem Datenfluss sind drei Metriken zugeordnet: Neuübertragungen, Zeitüberschreitungen bei der erneuten Übertragung und übertragene Daten (in Byte).
+ Intra AZ — Netzwerkflüsse zwischen Pods in derselben AZ
+ Inter AZ — Netzwerkflüsse zwischen Pods in verschiedenen AZs
+ EC2 → S3 - Netzwerkflüsse von Pods zu S3
+ EC2 → DDB — Netzwerkflüsse von Pods zu DDB
+ Nicht klassifiziert — Netzwerkflüsse von Pods ins Internet oder vor Ort
1. Netzwerkflüsse aus der Network Flow Monitor Top Contributors API werden verwendet, um die folgenden Funktionen in der EKS-Konsole bereitzustellen:
+ Service-Map: Visualisierung der Netzwerkflüsse innerhalb des Clusters (Intra AZ und Inter AZ).
+ Flow-Tabelle: Tabellarische Darstellung der Netzwerkflüsse innerhalb des Clusters (Intra AZ und Inter AZ), von Pods zu AWS Diensten (EC2 → S3 und EC2 → DDB) und von Pods zu externen Zielen (nicht klassifiziert).
Die von der Top Contributors API abgerufenen Netzwerkflüsse sind auf einen Zeitraum von 1 Stunde begrenzt und können bis zu 500 Datenflüsse aus jeder Kategorie umfassen. Für die Service Map bedeutet dies, dass bis zu 1000 Datenflüsse aus den Datenflusskategorien Intra AZ und Inter AZ über einen Zeitraum von 1 Stunde abgerufen und dargestellt werden können. Für die Flow-Tabelle bedeutet dies, dass bis zu 3000 Netzwerkflüsse aus allen 6 Netzwerkflusskategorien über einen Zeitraum von 2 Stunden abgerufen und dargestellt werden können.
#### Beispiel: Serviceübersicht
*Bereitstellungsansicht*
![\[Abbildung der Servicekarte mit E-Commerce-App in der Bereitstellungsansicht\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/ecommerce-deployment.png)
*Pod-Ansicht*
![\[Abbildung der Servicekarte mit E-Commerce-App in der Pod-Ansicht\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/ecommerce-pod.png)
*Bereitstellungsansicht*
![\[Abbildung der Servicekarte mit der Fotogalerie-App in der Bereitstellungsansicht\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/photo-gallery-deployment.png)
*Pod-Ansicht*
![\[Abbildung der Servicekarte mit Fotogalerie-App in der Pod-Ansicht\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/photo-gallery-pod.png)
#### Beispiel: Flow-Tabelle
* AWS Serviceansicht*
![\[Abbildung der Flow-Tabellenansicht\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/aws-service-view.png)
*Cluster-Ansicht*
![\[Abbildung der Flow-Tabelle in der Clusteransicht\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/cluster-view.png)
## Überlegungen und Einschränkungen
+ Container Network Observability in EKS ist nur in Regionen verfügbar, in denen [Network Flow Monitor unterstützt wird](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-Regions.html).
+ Unterstützte Systemmetriken sind OpenMetrics formatiert und können direkt vom Network Flow Monitor (NFM) -Agenten abgerufen werden.
+ Um Container Network Observability in EKS mithilfe von Infrastructure as Code (IaC) wie [Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/networkflowmonitor_monitor) zu aktivieren, müssen Sie die folgenden Abhängigkeiten in Ihren Konfigurationen definiert und erstellt haben: NFM-Bereich, NFM-Monitor und NFM-Agent.
+ Network Flow Monitor unterstützt bis zu etwa 5 Millionen Datenflüsse pro Minute. Das sind ungefähr 5.000 EC2 Instanzen (EKS-Worker-Knoten), auf denen der Network Flow Monitor-Agent installiert ist. Die Installation von Agenten auf mehr als 5000 Instanzen kann die Überwachungsleistung beeinträchtigen, bis zusätzliche Kapazität verfügbar ist.
+ Sie müssen eine Mindestversion von 1.1.0 für das EKS-Add-on des NFM-Agenten ausführen.
+ Sie müssen Version 6.21.0 oder höher des [Terraform AWS Providers verwenden, um die Network Flow Monitor-Ressourcen](https://github.com/hashicorp/terraform-provider-aws) zu unterstützen.
+ Um die Netzwerkflüsse mit Pod-Metadaten anzureichern, sollten Ihre Pods in ihrem eigenen isolierten Netzwerk-Namespace ausgeführt werden, nicht im Host-Netzwerk-Namespace.
# Überwachung Ihrer Cluster-Metriken mit Prometheus
[Prometheus](https://prometheus.io/) ist eine Überwachungs- und Zeitreihendatenbank, die Endpunkte durchsucht. Sie bietet die Möglichkeit, gesammelte Daten abzufragen, zu aggregieren und zu speichern. Sie können sie auch für Warnungen und für die Aggregation von Warnungen verwenden. In diesem Thema wird erläutert, wie Sie Prometheus entweder als verwaltete oder als Open-Source-Option einrichten. Die Überwachung der Metriken der Amazon-EKS-Steuerebene ist ein häufiger Anwendungsfall.
Amazon Managed Service for Prometheus ist ein Prometheus-kompatibler Überwachungs- und Warndienst, der es einfach macht, containerisierte Anwendungen und Infrastruktur im großen Maßstab zu überwachen. Es ist ein vollständig verwalteter Service, der die Aufnahme, Speicherung, Abfrage und Warnung Ihrer Metriken automatisch skaliert. Es lässt sich auch in AWS-Sicherheits-Services integrieren, um einen schnellen und sicheren Zugriff auf Ihre Daten zu ermöglichen. Sie können die Open-Source-PromQL-Abfragesprache verwenden, um Ihre Metriken abzufragen und darauf zu warnen. Außerdem können Sie den Alarmmanager im Amazon Managed Service für Prometheus verwenden, um Warnregeln für kritische Alarme einzurichten. Diese kritischen Warnmeldungen können Sie dann als Benachrichtigungen an ein Amazon-SNS-Thema senden.
Es gibt mehrere verschiedene Möglichkeiten, Prometheus mit Amazon EKS zu verwenden:
+ Sie können die Prometheus-Metriken beim erstmaligen Erstellen eines Amazon-EKS-Clusters aktivieren oder einen eigenen Prometheus-Scraper für vorhandene Cluster erstellen. Beide Optionen werden in diesem Thema behandelt.
+ Sie können Prometheus mithilfe von Helm bereitstellen. Weitere Informationen finden Sie unter [Prometheus mithilfe von Helm bereitstellen](deploy-prometheus.md).
+ Sie können die Rohdaten der Steuerebene im Prometheus-Format anzeigen. Weitere Informationen finden Sie unter [Rohmetriken der Steuerebene im Prometheus-Format abrufen](view-raw-metrics.md).
## Schritt 1: Prometheus-Metriken aktivieren
**Wichtig**
Amazon Managed Service für Prometheus-Ressourcen liegen außerhalb des Cluster-Lebenszyklus und müssen unabhängig vom Cluster verwaltet werden. Wenn Sie Ihren Cluster löschen, löschen Sie auch alle relevanten Scraper, um damit verbundenen Kosten zu vermeiden. Weitere Informationen finden Sie unter [Suchen und Löschen eine Scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
Prometheus entdeckt und erfasst Metriken aus Ihrem Cluster mithilfe eines Abruf-basierten Modells, das als Scraping bezeichnet wird. Scraper sind dafür eingerichtet, Daten aus Ihrer Cluster-Infrastruktur und containerisierten Anwendungen zu sammeln. Wenn Sie die Option zum Senden von Prometheus-Metriken aktivieren, stellt Amazon Managed Service for Prometheus einen vollständig verwalteten, agentenlosen Scraper zur Verfügung.
Falls Sie den Cluster noch nicht erstellt haben, können Sie die Option zum Senden von Metriken an Prometheus bei der erstmaligen Erstellung des Clusters aktivieren. In der Amazon-EKS-Konsole finden Sie diese Option im Schritt **Beobachtbarkeit konfigurieren** bei der Erstellung eines neuen Clusters. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md).
Wenn Sie bereits über einen vorhandenen Cluster verfügen, können Sie Ihren eigenen Prometheus-Scraper erstellen. Navigieren Sie dazu in der Amazon-EKS-Konsole zur Registerkarte **Beobachtbarkeit** Ihres Clusters und wählen Sie die Schaltfläche **Scraper hinzufügen**. Wenn Sie dies lieber mit der AWS-API oder AWS CLI tun möchten, finden Sie weitere Informationen unter [Erstellen eines Scrapers](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) im *Benutzerhandbuch für Amazon Managed Service für Prometheus*.
Beim Erstellen des Scrapers mit der Amazon-EKS-Konsole stehen die folgenden Optionen zur Verfügung.
**Scraper-Alias**
(Optional) Geben Sie einen eindeutigen Alias für den Scraper ein.
**Zieladresse**
Wählen Sie einen Workspace für Amazon Managed Service für Prometheus aus. Ein Workspace ist ein logischer Bereich, der der Speicherung und Abfrage von Prometheus-Metriken gewidmet ist. Mit diesem Arbeitsbereich können Sie Prometheus-Metriken für alle Konten anzeigen, die darauf zugreifen können. Die Option **Neuen Workspace erstellen** weist Amazon EKS an, unter Verwendung des von Ihnen angegebenen **Workspace-Alias** einen Workspace in Ihrem Namen zu erstellen. Mit der Option **Bestehenden Workspace auswählen** können Sie einen vorhandenen Workspace aus einer Dropdown-Liste auswählen. Weitere Informationen zu Workspaces finden Sie unter [Workspaces verwalten](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-manage-ingest-query.html) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
**Service-Zugriff**
Dieser Abschnitt fasst die Berechtigungen zusammen, die Sie beim Senden von Prometheus-Metriken gewähren:
+ Zulassen, dass Amazon Managed Service für Prometheus den gescrapten Amazon-EKS-Cluster beschreibt
+ Schreiben aus der Ferne in den Amazon-Managed-Prometheus-Arbeitsbereich zulassen
Wenn `AmazonManagedScraperRole` bereits vorhanden ist, verwendet der Scraper diese Rolle. Wählen Sie den `AmazonManagedScraperRole`-Link aus, um die **Berechtigungsdetails** anzuzeigen. Wenn `AmazonManagedScraperRole` noch nicht vorhanden ist, wählen Sie den Link **Berechtigungsdetails anzeigen**, um die spezifischen Berechtigungen anzuzeigen, die Sie durch das Senden von Prometheus-Metriken gewähren.
**Subnets**
Ändern Sie die Subnetze, die der Scraper übernehmen soll, nach Bedarf. Wenn Sie eine ausgegraute Subnetzoption hinzufügen müssen, kehren Sie zum Schritt der Cluster-Erstellung unter **Netzwerk angeben** zurück.
**Scraper-Konfiguration**
Ändern Sie die Scraper-Konfiguration nach Bedarf im YAML-Format. Verwenden Sie dazu das Formular oder laden Sie eine YAML-Ersatzdatei hoch. Weitere Informationen finden Sie unter [Scraper-Konfiguration](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-configuration) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
Amazon Managed Service für Prometheus bezieht sich auf den agentenlosen Scraper, der zusammen mit dem Cluster als verwalteter AWS-Sammler erstellt wird. Weitere Informationen zu von AWS verwalteten Kollektoren finden Sie unter [Erfassen von Metriken mit von AWS verwalteten Kollektoren](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector.html) im *Benutzerhandbuch zu Amazon Managed Service für Prometheus*.
**Wichtig**
Wenn Sie einen Prometheus-Scraper mithilfe der AWS CLI oder AWS-API erstellen, müssen Sie seine Konfiguration anpassen, um dem Scraper Berechtigungen im Cluster zu gewähren. Weitere Informationen finden Sie unter [Konfigurieren Ihres Amazon-EKS-Clusters](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-setup) im *Benutzerhandbuch von Amazon Managed Service für Prometheus*.
Wenn Sie einen Prometheus-Scraper haben, der vor dem 11. November 2024 erstellt wurde und `aws-auth` `ConfigMap` anstelle von Zugriffseinträgen verwendet, müssen Sie ihn aktualisieren, um auf zusätzliche Metriken aus der Amazon-EKS-Cluster-Steuerebene zugreifen zu können. Informationen zur aktualisierten Konfiguration finden Sie unter [Manuelle Konfiguration von Amazon EKS für Scraper-Zugriff](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-eks-manual-setup) im *Benutzerhandbuch zu Amazon Managed Service für Prometheus*.
## Schritt 2: Prometheus-Metriken verwenden
Weitere Informationen zur Verwendung der Prometheus-Metriken, nachdem Sie sie für Ihren Cluster aktiviert haben, finden Sie im [Benutzerhandbuch für Amazon Managed Service für Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html).
## Schritt 3: Prometheus-Scraper verwalten
Wählen Sie zur Verwaltung von Scrapern in der Amazon-EKS-Konsole die Registerkarte **Beobachtbarkeit** aus. Eine Tabelle zeigt eine Liste der Scraper für den Cluster, einschließlich Informationen wie Scraper-ID, Alias, Status und Erstellungsdatum. Sie können weitere Scraper hinzufügen, Scraper bearbeiten, Scraper löschen oder weitere Informationen zu den aktuellen Scrapern anzeigen.
Um weitere Details zu einem Scraper anzuzeigen, wählen Sie den Scraper-ID-Link. Sie können beispielsweise ARN, Umgebung, Arbeitsbereichs-ID, IAM-Rolle, Konfiguration und Netzwerkinformationen anzeigen. Sie können die Scraper-ID als Eingabe für Operationen in der Amazon-Managed-Service-für-Prometheus-API wie [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DescribeScraper.html), [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_UpdateScraper.html) und [https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html](https://docs.aws.amazon.com/prometheus/latest/APIReference/API_DeleteScraper.html) verwenden. Weitere Informationen zur Verwendung der Prometheus-API finden Sie in der [API-Referenz zu Amazon Managed Service für Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-APIReference.html).
# Prometheus mithilfe von Helm bereitstellen
Als Alternative zur Verwendung von Amazon Managed Service für Prometheus können Sie Prometheus mit Helm in Ihrem Cluster bereitstellen. Wenn Sie Helm bereits installiert haben, können Sie Ihre Version mit dem `helm version`-Befehl überprüfen. Helm ist ein Paket-Manager für Kubernetes-Cluster. Weitere Informationen zu Helm und zur Installation finden Sie unter [Bereitstellung von Anwendungen mit Helm in Amazon EKS](helm.md).
Nachdem Sie Helm für Ihren Amazon-EKS-Cluster konfiguriert haben, können Sie damit die folgenden Schritte ausführen, um Prometheus bereitzustellen.
1. Erstellen Sie einen Prometheus-Namespace.
```
kubectl create namespace prometheus
```
1. Fügen Sie das `prometheus-community`-Diagramm-Repository hinzu.
```
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
```
1. Stellen Sie Prometheus bereit.
```
helm upgrade -i prometheus prometheus-community/prometheus \
--namespace prometheus \
--set alertmanager.persistence.storageClass="gp2" \
--set server.persistentVolume.storageClass="gp2"
```
**Anmerkung**
Wenn Sie bei der Ausführung dieses Befehls die Fehlermeldung `Error: failed to download "stable/prometheus" (hint: running helm repo update may help)` erhalten, führen Sie `helm repo update prometheus-community` aus, und versuchen Sie dann erneut, den Befehl aus Schritt 2 auszuführen.
Wenn Sie die Fehlermeldung `Error: rendered manifests contain a resource that already exists` erhalten, führen Sie `helm uninstall your-release-name -n namespace ` aus, und versuchen Sie dann, den Befehl aus Schritt 3 erneut auszuführen.
1. Stellen Sie sicher, dass alle Pods im `prometheus`-Namespace den Status `READY` haben.
```
kubectl get pods -n prometheus
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME READY STATUS RESTARTS AGE
prometheus-alertmanager-59b4c8c744-r7bgp 1/2 Running 0 48s
prometheus-kube-state-metrics-7cfd87cf99-jkz2f 1/1 Running 0 48s
prometheus-node-exporter-jcjqz 1/1 Running 0 48s
prometheus-node-exporter-jxv2h 1/1 Running 0 48s
prometheus-node-exporter-vbdks 1/1 Running 0 48s
prometheus-pushgateway-76c444b68c-82tnw 1/1 Running 0 48s
prometheus-server-775957f748-mmht9 1/2 Running 0 48s
```
1. Verwenden Sie `kubectl`, um die Prometheus-Konsole auf Ihren lokalen Computer weiterzuleiten.
```
kubectl --namespace=prometheus port-forward deploy/prometheus-server 9090
```
1. Richten Sie einen Web-Browser auf `http://localhost:9090`, um die Prometheus-Konsole anzuzeigen.
1. Wählen Sie eine Metrik aus dem Menü **- insert metric at cursor** (Metrik bei Cursor eingeben) und danach **Execute** (Ausführen). Wählen Sie die Registerkarte **Graph** (Diagramm) aus, um die Metrik im Zeitverlauf anzuzeigen. Das folgende Image zeigt `container_memory_usage_bytes` im Zeitverlauf.
![\[Prometheus-Metriken\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/prometheus-metric.png)
1. Wählen Sie in der oberen Navigationsleiste **Status**, dann **Targets** (Ziele).
![\[Prometheus-Konsole\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/prometheus.png)
Es werden alle Kubernetes-Endpunkte angezeigt, die über die Service-Erkennung mit Prometheus verbunden sind.
# Rohmetriken der Steuerebene im Prometheus-Format abrufen
Die Kubernetes-Steuerebene stellt eine Reihe von Metriken bereit, die im [Prometheus-Format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) dargestellt werden. Diese Metriken sind für die Überwachung und Analyse hilfreich. Sie werden intern über Metrik-Endpunkte bereitgestellt und können ohne vollständige Bereitstellung von Prometheus abgerufen werden. Die Bereitstellung von Prometheus vereinfacht jedoch die Analyse von Metriken im Zeitverlauf.
Um die Rohdaten der Metriken anzuzeigen, ersetzen Sie `endpoint` und führen Sie den folgenden Befehl aus.
```
kubectl get --raw endpoint
```
Mit diesem Befehl können Sie einen beliebigen Endpunktpfad übergeben und erhalten die Rohdaten als Antwort zurück. Die Ausgabe listet zeilenweise verschiedene Metriken auf, wobei jede Zeile einen Metriknamen, Tags und einen Wert enthält.
```
metric_name{tag="value"[,...]} value
```
## Metriken vom API-Server abrufen
Der allgemeine API-Server-Endpunkt wird in der Amazon-EKS-Steuerebene bereitgestellt. Dieser Endpunkt ist vor allem nützlich, wenn Sie eine bestimmte Metrik betrachten möchten.
```
kubectl get --raw /metrics
```
Eine Beispielausgabe sieht wie folgt aus.
```
[...]
# HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host.
# TYPE rest_client_requests_total counter
rest_client_requests_total{code="200",host="127.0.0.1:21362",method="POST"} 4994
rest_client_requests_total{code="200",host="127.0.0.1:443",method="DELETE"} 1
rest_client_requests_total{code="200",host="127.0.0.1:443",method="GET"} 1.326086e+06
rest_client_requests_total{code="200",host="127.0.0.1:443",method="PUT"} 862173
rest_client_requests_total{code="404",host="127.0.0.1:443",method="GET"} 2
rest_client_requests_total{code="409",host="127.0.0.1:443",method="POST"} 3
rest_client_requests_total{code="409",host="127.0.0.1:443",method="PUT"} 8
# HELP ssh_tunnel_open_count Counter of ssh tunnel total open attempts
# TYPE ssh_tunnel_open_count counter
ssh_tunnel_open_count 0
# HELP ssh_tunnel_open_fail_count Counter of ssh tunnel failed open attempts
# TYPE ssh_tunnel_open_fail_count counter
ssh_tunnel_open_fail_count 0
```
Diese Rohausgabe zeigt exakt das, was der API-Server bereitstellt.
## Metriken der Steuerebene mit `metrics.eks.amazonaws.com` abrufen
Für Cluster mit Kubernetes-Version `1.28` und höher stellt Amazon EKS auch Metriken unter der API-Gruppe `metrics.eks.amazonaws.com` bereit. Diese Metriken umfassen Steuerebenen-Komponenten wie `kube-scheduler` und `kube-controller-manager`.
**Anmerkung**
Wenn Sie über eine Webhook-Konfiguration verfügen, welche die Erstellung der neuen `APIService`-Ressource `v1.metrics.eks.amazonaws.com` in Ihrem Cluster blockieren könnte, ist das Feature des Metrik-Endpunkts möglicherweise nicht verfügbar. Sie können dies im Überwachungsprotokoll `kube-apiserver` überprüfen, indem Sie nach dem Schlüsselwort `v1.metrics.eks.amazonaws.com` suchen.
### `kube-scheduler`-Metriken abrufen
Verwenden Sie zum Abrufen von `kube-scheduler`-Metriken den folgenden Befehl.
```
kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics"
```
Eine Beispielausgabe sieht wie folgt aus.
```
# TYPE scheduler_pending_pods gauge
scheduler_pending_pods{queue="active"} 0
scheduler_pending_pods{queue="backoff"} 0
scheduler_pending_pods{queue="gated"} 0
scheduler_pending_pods{queue="unschedulable"} 18
# HELP scheduler_pod_scheduling_attempts [STABLE] Number of attempts to successfully schedule a pod.
# TYPE scheduler_pod_scheduling_attempts histogram
scheduler_pod_scheduling_attempts_bucket{le="1"} 79
scheduler_pod_scheduling_attempts_bucket{le="2"} 79
scheduler_pod_scheduling_attempts_bucket{le="4"} 79
scheduler_pod_scheduling_attempts_bucket{le="8"} 79
scheduler_pod_scheduling_attempts_bucket{le="16"} 79
scheduler_pod_scheduling_attempts_bucket{le="+Inf"} 81
[...]
```
### `kube-controller-manager`-Metriken abrufen
Verwenden Sie zum Abrufen von `kube-controller-manager`-Metriken den folgenden Befehl.
```
kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics"
```
Eine Beispielausgabe sieht wie folgt aus.
```
[...]
workqueue_work_duration_seconds_sum{name="pvprotection"} 0
workqueue_work_duration_seconds_count{name="pvprotection"} 0
workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-08"} 0
workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-07"} 0
workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-06"} 0
workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-06"} 0
workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-05"} 19
workqueue_work_duration_seconds_bucket{name="replicaset",le="0.001"} 109
workqueue_work_duration_seconds_bucket{name="replicaset",le="0.01"} 139
workqueue_work_duration_seconds_bucket{name="replicaset",le="0.1"} 181
workqueue_work_duration_seconds_bucket{name="replicaset",le="1"} 191
workqueue_work_duration_seconds_bucket{name="replicaset",le="10"} 191
workqueue_work_duration_seconds_bucket{name="replicaset",le="+Inf"} 191
workqueue_work_duration_seconds_sum{name="replicaset"} 4.265655885000002
[...]
```
### Metriken des Schedulers und des Controller-Managers verstehen
In der folgenden Tabelle werden die Scheduler- und Controller-Manager-Metriken beschrieben, die für das Scraping im Prometheus-Stil verfügbar gemacht werden. eitere Informationen zu diesen Metriken finden Sie in der [Kubernetes-Metriken-Referenz](https://kubernetes.io/docs/reference/instrumentation/metrics/) in der Kubernetes-Dokumentation.
| Metrik | Komponente der Steuerebene | Beschreibung |
| --- | --- | --- |
| scheduler\$1pending\$1pods | Scheduler | Die Anzahl der Pods, die darauf warten, zur Ausführung in einen Knoten geplant zu werden. |
| scheduler\$1schedule\$1attempts\$1total | Scheduler | Die Anzahl der Versuche, Pods zu planen. |
| scheduler\$1preemption\$1attempts\$1total | Scheduler | Die Anzahl der Versuche des Schedulers, Pods mit höherer Priorität zu planen, indem Pods mit niedrigerer Priorität entfernt werden. |
| scheduler\$1preemption\$1victims | Scheduler | Die Anzahl der Pods, die zur Bereinigung ausgewählt wurden, um Platz für Pods mit höherer Priorität zu schaffen. |
| scheduler\$1pod\$1scheduling\$1attempts | Scheduler | Die Anzahl der Versuche, einen Pod erfolgreich zu planen. |
| scheduler\$1scheduling\$1attempt\$1duration\$1seconds | Scheduler | Gibt an, wie schnell oder langsam der Scheduler in der Lage ist, einen geeigneten Ausführungsort für einen Pod zu finden, basierend auf verschiedenen Faktoren wie Ressourcenverfügbarkeit und Planungsregeln. |
| scheduler\$1pod\$1scheduling\$1sli\$1duration\$1seconds | Scheduler | Die durchgängige Latenz für einen Pod, der geplant wird, ab dem Zeitpunkt, an dem der Pod in die Planungswarteschlange aufgenommen wird. Dies kann mehrere Planungsversuche umfassen. |
| cronjob\$1controller\$1job\$1creation\$1skew\$1duration\$1seconds | controller manager | Der Zeitraum zwischen der geplanten Ausführung eines Cronjobs und der Erstellung des entsprechenden Auftrags. |
| workqueue\$1depth | controller manager | Die aktuelle Ebene der Warteschlange. |
| workqueue\$1adds\$1total | controller manager | Die Gesamtzahl der von der Arbeitswarteschlange bearbeiteten Einträge. |
| workqueue\$1queue\$1duration\$1seconds | controller manager | Die Zeit in Sekunden, die ein Element in der Arbeitswarteschlange verbleibt, bevor es angefordert wird. |
| workqueue\$1work\$1duration\$1seconds | controller manager | Die Zeit in Sekunden, die für die Bearbeitung eines Elements aus der Arbeitswarteschlange benötigt wird. |
## Prometheus-Scraper einsetzen, um Metriken konsistent zu scrapen
Um einen Prometheus-Scraper einzusetzen, der die Metriken konsistent scrapt, verwenden Sie die folgende Konfiguration:
```
---
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-conf
data:
prometheus.yml: |-
global:
scrape_interval: 30s
scrape_configs:
# apiserver metrics
- job_name: apiserver-metrics
kubernetes_sd_configs:
- role: endpoints
scheme: https
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
relabel_configs:
- source_labels:
[
__meta_kubernetes_namespace,
__meta_kubernetes_service_name,
__meta_kubernetes_endpoint_port_name,
]
action: keep
regex: default;kubernetes;https
# Scheduler metrics
- job_name: 'ksh-metrics'
kubernetes_sd_configs:
- role: endpoints
metrics_path: /apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics
scheme: https
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
relabel_configs:
- source_labels:
[
__meta_kubernetes_namespace,
__meta_kubernetes_service_name,
__meta_kubernetes_endpoint_port_name,
]
action: keep
regex: default;kubernetes;https
# Controller Manager metrics
- job_name: 'kcm-metrics'
kubernetes_sd_configs:
- role: endpoints
metrics_path: /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics
scheme: https
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
relabel_configs:
- source_labels:
[
__meta_kubernetes_namespace,
__meta_kubernetes_service_name,
__meta_kubernetes_endpoint_port_name,
]
action: keep
regex: default;kubernetes;https
---
apiVersion: v1
kind: Pod
metadata:
name: prom-pod
spec:
containers:
- name: prom-container
image: prom/prometheus
ports:
- containerPort: 9090
volumeMounts:
- name: config-volume
mountPath: /etc/prometheus/
volumes:
- name: config-volume
configMap:
name: prometheus-conf
```
Die folgende Berechtigung ist erforderlich, damit der Pod auf den neuen Metrik-Endpunkt zugreifen kann.
```
{
"effect": "allow",
"apiGroups": [
"metrics.eks.amazonaws.com"
],
"resources": [
"kcm/metrics",
"ksh/metrics"
],
"verbs": [
"get"
] },
```
Um die verwendete Rolle zu patchen, können Sie den folgenden Befehl verwenden.
```
kubectl patch clusterrole --type=json -p='[
{
"op": "add",
"path": "/rules/-",
"value": {
"verbs": ["get"],
"apiGroups": ["metrics.eks.amazonaws.com"],
"resources": ["kcm/metrics", "ksh/metrics"]
}
}
]'
```
Anschließend können Sie das Prometheus-Dashboard anzeigen, indem Sie den Port des Prometheus-Scrapers auf Ihren lokalen Port umstellen.
```
kubectl port-forward pods/prom-pod 9090:9090
```
Für Ihren Amazon-EKS-Cluster werden die Kernmetriken der Kubernetes-Steuerebene auch unter dem `AWS/EKS`-Namespace in Amazon CloudWatch-Metriken aufgenommen. Um sie anzuzeigen, öffnen Sie die [CloudWatch-Konsole](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) und wählen Sie im linken Navigationsbereich **Alle Metriken** aus. Wählen Sie auf der Auswahlseite **Metriken** den `AWS/EKS`-Namespace und eine Metrikdimension für Ihren Cluster aus.
# Überwachen Sie Clusterdaten mit Amazon CloudWatch
Amazon CloudWatch ist ein Überwachungsdienst, der Metriken und Protokolle aus Ihren Cloud-Ressourcen sammelt. CloudWatch stellt einige grundlegende Amazon EKS-Metriken kostenlos zur Verfügung, wenn Sie einen neuen Cluster der Version `1.28` und höher verwenden. Wenn Sie den CloudWatch Observability Operator jedoch als Amazon EKS-Add-on verwenden, können Sie erweiterte Observability-Funktionen nutzen.
## Grundlegende Metriken in Amazon CloudWatch
Für Cluster der Kubernetes-Version `1.28` und höher erhalten Sie CloudWatch Metriken kostenlos im Namespace. `AWS/EKS` Die folgende Tabelle enthält eine Liste der grundlegenden Metriken, die für die unterstützten Versionen verfügbar sind. Jede aufgeführte Metrik hat eine Frequenz von einer Minute.
| Metrikname | Description |
| --- | --- |
| `apiserver_flowcontrol_current_executing_seats` | Die Anzahl der Sitze, die derzeit für die Ausführung von API-Anfragen verwendet werden. [Die Sitzplatzzuweisung wird durch die Konfiguration priority\$1level und flow\$1schema in der Kubernetes-API-Funktion Priority and Fairness bestimmt.](https://kubernetes.io/docs/concepts/cluster-administration/flow-control/) **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_schedule_attempts_total` | Die Gesamtzahl der Versuche des Schedulers, Pods im Cluster für einen bestimmten Zeitraum zu planen. Diese Metrik unterstützt die Überwachung der Workload des Schedulers und kann auf Planungsdruck oder potenzielle Probleme bei der Pod-Platzierung hinweisen. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_schedule_attempts_SCHEDULED` | Die Anzahl der erfolgreichen Versuche des Schedulers, Pods für einen bestimmten Zeitraum auf Knoten im Cluster zu planen. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_schedule_attempts_UNSCHEDULABLE` | Die Anzahl der Versuche, Pods zu planen, die für einen bestimmten Zeitraum aufgrund gültiger Einschränkungen, wie z. B. unzureichender CPU oder Speicher auf einem Knoten, nicht planbar waren. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_schedule_attempts_ERROR` | Die Anzahl der Versuche, Pods zu planen, die für einen bestimmten Zeitraum aufgrund eines internen Problems mit dem Planer selbst, wie z. B. Verbindungsproblemen des API-Servers, fehlgeschlagen sind. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_pending_pods` | Die Gesamtzahl der ausstehenden Pods, die vom Scheduler im Cluster für einen bestimmten Zeitraum geplant werden sollen. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_pending_pods_ACTIVEQ` | Die Anzahl der ausstehenden Pods in ActiveQ, die darauf warten, für einen bestimmten Zeitraum im Cluster geplant zu werden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_pending_pods_UNSCHEDULABLE` | Die Anzahl der ausstehenden Pods, die der Planer zu planen versucht hat, bei denen dies jedoch fehlgeschlagen ist, und die für einen erneuten Versuch in einem nicht planbaren Zustand gehalten werden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_pending_pods_BACKOFF` | Die Anzahl der ausstehenden Pods in `backoffQ` im Backoff-Zustand, die auf den Ablauf ihrer Backoff-Periode warten. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `scheduler_pending_pods_GATED` | Die Anzahl der ausstehenden Pods, die derzeit in einem gesperrten Zustand warten, da sie erst geplant werden können, wenn sie die erforderlichen Bedingungen erfüllen. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_request_total` | Die Anzahl der HTTP-Anfragen, die über alle API-Server im Cluster gestellt wurden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_request_total_4XX` | Die Anzahl der HTTP-Anfragen an alle API-Server im Cluster, die zu `4XX`-Statuscodes (clientseitige Fehler) führten. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_request_total_429` | Die Anzahl der HTTP-Anfragen an alle API-Server im Cluster, die zu `429`Statuscodes geführt haben, die auftreten, wenn Clients die Schwellenwerte für die Ratenbegrenzung überschreiten. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_request_total_5XX` | Die Anzahl der HTTP-Anfragen an alle API-Server im Cluster, die zu `5XX`-Statuscodes (Serverfehler) führten. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_request_total_LIST_PODS` | Die Anzahl der `LIST`-Pods-Anfragen an alle API-Server im Cluster. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_request_duration_seconds_PUT_P99` | Das 99. Perzentil der Latenz für `PUT`-Anfragen, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller `PUT`-Anfragen abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_request_duration_seconds_PATCH_P99` | Das 99. Perzentil der Latenz für `PATCH`-Anfragen, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller `PATCH`-Anfragen abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_request_duration_seconds_POST_P99` | Das 99. Perzentil der Latenz für `POST`-Anfragen, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller `POST`-Anfragen abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_request_duration_seconds_GET_P99` | Das 99. Perzentil der Latenz für `GET`-Anfragen, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller `GET`-Anfragen abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_request_duration_seconds_LIST_P99` | Das 99. Perzentil der Latenz für `LIST`-Anfragen, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller `LIST`-Anfragen abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_request_duration_seconds_DELETE_P99` | Das 99. Perzentil der Latenz für `DELETE`-Anfragen, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller `DELETE`-Anfragen abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_current_inflight_requests_MUTATING` | Die Anzahl der mutierenden Anfragen (`POST`, `PUT`, `DELETE`, `PATCH`), die derzeit auf allen API-Servern im Cluster verarbeitet werden. Diese Metrik stellt Anfragen dar, die sich in der Bearbeitung befinden und deren Verarbeitung noch nicht abgeschlossen ist **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_current_inflight_requests_READONLY` | Die Anzahl der schreibgeschützten Anfragen (`GET`, `LIST`), die derzeit auf allen API-Servern im Cluster verarbeitet werden. Diese Metrik stellt Anfragen dar, die sich in der Bearbeitung befinden und deren Verarbeitung noch nicht abgeschlossen ist **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_request_total` | Die Anzahl der Zulassungs-Webhook-Anfragen, die über alle API-Server im Cluster gestellt wurden **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_request_total_ADMIT` | Die Anzahl der mutierenden Zulassungs-Webhook-Anfragen, die über alle API-Server im Cluster gestellt wurden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_request_total_VALIDATING` | Die Anzahl der validierenden Zulassungs-Webhook-Anfragen, die über alle API-Server im Cluster gestellt wurden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_rejection_count` | Die Anzahl der Zulassungs-Webhook-Anfragen, die über alle API-Server im Cluster gestellt und abgelehnt wurden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_rejection_count_ADMIT` | Die Anzahl der abgelehnten mutierenden Zulassungs-Webhook-Anfragen über alle API-Server im Cluster. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_rejection_count_VALIDATING` | Die Anzahl der Webhook-Anfragen zur Validierung der Zulassung, die über alle API-Server im Cluster gestellt und abgelehnt wurden. **Einheiten:** Anzahl **Gültige Statistiken:** Summe |
| `apiserver_admission_webhook_admission_duration_seconds` | Das 99. Perzentil der Latenz für Zulassungs-Webhook-Anfragen von Drittanbietern, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller Zulassungs-Webhook-Anfragen von Drittanbietern abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_admission_webhook_admission_duration_seconds_ADMIT_P99` | Das 99. Perzentil der Latenz für mutierende Zulassungs-Webhook-Anfragen von Drittanbietern, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller mutierenden Zulassungs-Webhook-Anfragen von Drittanbietern abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_admission_webhook_admission_duration_seconds_VALIDATING_P99` | Das 99. Perzentil der Latenz für Webhook-Anfragen zur Validierung von Zulassungen durch Dritte, berechnet aus allen Anfragen aller API-Server im Cluster. Stellt die Antwortzeit dar, unter der 99 % aller Webhook-Anfragen von Drittanbietern zur Validierung der Zulassung abgeschlossen werden. **Einheiten:** Sekunden **Gültige Statistiken:** Durchschnitt |
| `apiserver_storage_size_bytes` | Die physische Größe in Bytes der etcd-Speicher-Datenbankdatei, die von den API-Servern im Cluster verwendet wird. Diese Metrik stellt den tatsächlich für den Speicher zugewiesenen Speicherplatz dar. **Einheiten:** Byte **Gültige Statistiken:** Maximum |
## Amazon CloudWatch Observability-Betreiber
Amazon CloudWatch Observability sammelt Protokolle, Metriken und Trace-Daten in Echtzeit. Es sendet sie an [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) und [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html). Sie können dieses Add-on installieren, um sowohl CloudWatch Application Signals als auch CloudWatch Container Insights mit verbesserter Observability für Amazon EKS zu aktivieren. Dies hilft Ihnen, den Zustand und die Leistung Ihrer Infrastruktur und containerisierten Anwendungen zu überwachen. Der Amazon CloudWatch Observability Operator ist für die Installation und Konfiguration der erforderlichen Komponenten konzipiert.
Amazon EKS unterstützt den CloudWatch Observability Operator als [Amazon EKS-Add-on](eks-add-ons.md). Das Add-On ermöglicht den Einsatz von Container Insights sowohl auf Linux- als auch auf Windows-Worker-Knoten im Cluster. Um Container Insights unter Windows zu aktivieren, muss die Amazon-EKS-Add-On-Version mindestens `1.5.0` sein. Derzeit wird CloudWatch Application Signals auf Amazon EKS Windows nicht unterstützt.
In den folgenden Themen werden die ersten Schritte mit der Verwendung von CloudWatch Observability Operator für Ihren Amazon EKS-Cluster beschrieben.
+ Anweisungen zur Installation dieses Add-ons finden [Sie unter Installieren des CloudWatch Agenten mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Diagramm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html) im * CloudWatch Amazon-Benutzerhandbuch*.
+ Weitere Informationen zu CloudWatch Application Signals finden Sie unter [Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html) im * CloudWatch Amazon-Benutzerhandbuch*.
+ Weitere Informationen zu Container Insights finden Sie unter [Using Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) im * CloudWatch Amazon-Benutzerhandbuch*.
# Protokolle der Kontrollebene an CloudWatch Logs senden
Die Protokollierung auf der Amazon EKS-Kontrollebene stellt Prüf- und Diagnoseprotokolle direkt von der Amazon EKS-Steuerebene zu den CloudWatch Protokollen in Ihrem Konto bereit. Diese Protokolle erleichtern Ihnen die Absicherung und Ausführung Ihrer Cluster. Sie können genau die Protokolltypen auswählen, die Sie benötigen, und die Protokolle werden als Protokollstreams an eine Gruppe für jeden Amazon EKS-Cluster gesendet CloudWatch. Sie können CloudWatch Abonnementfilter verwenden, um die Protokolle in Echtzeit zu analysieren oder sie an andere Dienste weiterzuleiten (die Protokolle werden Base64-codiert und im GZIP-Format komprimiert). Weitere Informationen finden Sie unter [ CloudWatch Amazon-Protokollierung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
**Anmerkung**
Die Protokolle der Amazon EKS-Kontrollebene werden innerhalb weniger Minuten an CloudWatch Logs übermittelt. Die Protokollzustellung ist jedoch der beste Weg.
Sie können mit der Protokollierung der Amazon-EKS-Steuerebene beginnen, indem Sie die für jeden neuen oder bestehenden Amazon-EKS-Cluster zu aktivierenden Protokolltypen auswählen. Sie können jeden Protokolltyp auf Clusterbasis mit der AWS-Managementkonsole AWS CLI (Version `1.16.139` oder höher) oder über die Amazon EKS-API aktivieren oder deaktivieren. Wenn diese Option aktiviert ist, werden Protokolle automatisch vom Amazon EKS-Cluster an CloudWatch Logs im selben Konto gesendet.
Wenn Sie die Protokollierung der Amazon-EKS-Steuerebene verwenden, werden Ihnen für jeden betriebenen Cluster die Amazon-EKS-Standardpreise berechnet. Für alle Logs, die aus Ihren Clustern an CloudWatch Logs gesendet werden, werden Ihnen die standardmäßigen Kosten für die Aufnahme und Speicherung von CloudWatch Logs-Daten in Rechnung gestellt. Ihnen werden auch alle AWS Ressourcen, wie Amazon EC2-Instances oder Amazon EBS-Volumes, in Rechnung gestellt, die Sie als Teil Ihres Clusters bereitstellen.
Die folgenden Protokolltypen der Cluster-Steuerungsebene sind verfügbar. Jeder Protokolltyp entspricht einer Komponente der Kubernetes-Steuerebene. Um mehr über diese Komponenten zu erfahren, lesen Sie [Kubernetes-Komponenten](https://kubernetes.io/docs/concepts/overview/components/) in der Kubernetes-Dokumentation.
**API-Server`api` (**)
Der API-Server Ihres Clusters ist die Steuerebenen-Komponente, welche die Kubernetes-API bereitstellt. Wenn Sie API-Serverprotokolle beim Starten des Clusters oder kurz danach aktivieren, enthalten die Protokolle API-Server-Markierungen, die zum Starten des API-Servers verwendet wurden. Weitere Informationen finden Sie unter [kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) und in der [Prüfungsrichtlinie](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh#L1129-L1255) in der Kubernetes-Dokumentation.
**Prüfung`audit` (**)
Kubernetes-Auditprotokolle bieten eine Aufzeichnung der einzelnen Benutzer, Administratoren oder Systemkomponenten, die Ihren Cluster beeinflusst haben. Weitere Informationen finden Sie unter [Prüfung](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/) in der Kubernetes-Dokumentation.
**Authenticator`authenticator` (**)
Authenticator-Protokolle sind eindeutig für Amazon EKS. Diese Protokolle stellen die Steuerebenenkomponente dar, die Amazon EKS für die Kubernetes-Authentifizierung per [rollenbasierter Zugriffssteuerung](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) mit IAM-Anmeldeinformationen verwendet. Weitere Informationen finden Sie unter [Organisieren und Überwachen von Cluster-Ressourcen](eks-managing.md).
**Controller-Manager`controllerManager` (**)
Der Controller-Manager verwaltet die zentralen Regelkreise, die mit Kubernetes ausgeliefert werden. Weitere Informationen finden Sie unter [kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) in der Kubernetes-Dokumentation.
**Scheduler`scheduler` (**)
Die Planer-Komponente verwaltet, wann und wo Pods in Ihrem Cluster ausgeführt werden. Weitere Informationen finden Sie unter [kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) in der Kubernetes-Dokumentation.
## Aktivierung oder Deaktivierung der Steuerebenen-Protokolle
Standardmäßig werden Protokolle der Cluster-Steuerungsebene nicht an CloudWatch Logs gesendet. Sie müssen jeden Protokolltyp einzeln aktivieren, um Protokolle für Ihren Cluster zu senden. CloudWatch Die Raten für die Aufnahme von Protokollen, die Archivierung und das Scannen von Daten gelten für aktivierte Protokolle auf der Kontrollebene. Weitere Informationen finden Sie unter [CloudWatch Preise](https://aws.amazon.com/cloudwatch/pricing/).
Um die Protokollierungskonfiguration der Steuerebene zu aktualisieren, benötigt Amazon EKS bis zu fünf verfügbare IP-Adressen in jedem Subnetz. Wenn Sie einen Protokolltyp aktivieren, werden die Protokolle mit der Protokollausführungsstufe `2` gesendet.
Sie können Steuerebenen-Protokolle entweder mit [AWS-Managementkonsole](#control-plane-console) oder der [AWS -CLI](#control-plane-cli) aktivieren oder deaktivieren.
### AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, um Ihre Cluster-Informationen anzuzeigen.
1. Wählen Sie den Registerkarte **Beobachtbarkeit**.
1. Wählen Sie im Abschnitt **Steuerebenen-Protokollierung** die Option **Protokollierung verwalten** aus.
1. Wählen Sie für jeden Protokolltyp aus, ob er aktiviert oder deaktiviert sein soll. Standardmäßig sind alle Protokollierungstypen deaktiviert.
1. Wählen Sie **Änderungen speichern**, um den Vorgang abzuschließen.
### AWS CLI
1. Überprüfen Sie Ihre AWS CLI-Version mit dem folgenden Befehl.
```
aws --version
```
Wenn Ihre AWS CLI-Version älter als ist`1.16.139`, müssen Sie zuerst auf die neueste Version aktualisieren. Informationen zur Installation oder zum Upgrade der AWS CLI finden Sie unter [Installation der AWS Befehlszeilenschnittstelle](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*.
1. Aktualisieren Sie die Protokoll-Exportkonfiguration der Steuerungsebene Ihres Clusters mit dem folgenden AWS CLI-Befehl. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters und geben Sie die gewünschten Endpunkt-Zugriffswerte ein.
**Anmerkung**
Mit dem folgenden Befehl werden alle verfügbaren Protokolltypen an CloudWatch Logs gesendet.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "883405c8-65c6-4758-8cee-2a7c1340a6d9",
"status": "InProgress",
"type": "LoggingUpdate",
"params": [
{
"type": "ClusterLogging",
"value": "{\"clusterLogging\":[{\"types\":[\"api\",\"audit\",\"authenticator\",\"controllerManager\",\"scheduler\"],\"enabled\":true}]}"
}
],
"createdAt": 1553271814.684,
"errors": []
}
}
```
1. Überwachen Sie den Status Ihres Protokoll-Konfigurationsupdates mit dem folgenden Befehl unter Verwendung des Cluster-Namens und der Update-ID, die vom vorherigen Befehl zurückgegeben wurden. Ihre Aktualisierung ist abgeschlossen, wenn als Status `Successful` angezeigt wird.
```
aws eks describe-update \
--region region-code\
--name my-cluster \
--update-id 883405c8-65c6-4758-8cee-2a7c1340a6d9
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"update": {
"id": "883405c8-65c6-4758-8cee-2a7c1340a6d9",
"status": "Successful",
"type": "LoggingUpdate",
"params": [
{
"type": "ClusterLogging",
"value": "{\"clusterLogging\":[{\"types\":[\"api\",\"audit\",\"authenticator\",\"controllerManager\",\"scheduler\"],\"enabled\":true}]}"
}
],
"createdAt": 1553271814.684,
"errors": []
}
}
```
## Cluster-Steuerebenen-Protokolle anzeigen
Nachdem Sie einen der Protokolltypen der Kontrollebene für Ihren Amazon EKS-Cluster aktiviert haben, können Sie ihn auf der CloudWatch Konsole anzeigen.
Weitere Informationen zum Anzeigen, Analysieren und Verwalten von Logs in CloudWatch Amazon Logs finden Sie im [Amazon CloudWatch Logs-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
1. Öffnen Sie die [CloudWatch -Konsole](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks). Der Link öffnet die Konsole und zeigt Ihre aktuell verfügbaren Protokollgruppen an und filtert sie mit dem `/aws/eks`-Präfix.
1. Wählen Sie den Cluster aus, für den Sie die Protokolle anzeigen möchten. Das Format für den Namen der Protokollgruppen lautet `/aws/eks/my-cluster/cluster`.
1. Wählen Sie den anzuzeigenden Protokollstream aus. Die folgende Liste beschreibt das Namensformat des Protokollstreams der einzelnen Protokolltypen.
**Anmerkung**
Wenn die Daten des Protokollstreams ansteigen, werden die Namen des Protokollstreams rotiert. Wenn mehrere Protokollstreams für einen bestimmten Protokolltyp vorhanden sind, können Sie den neuesten Protokollstream anzeigen, indem Sie nach dem Namen des Protokollstreams mit der letzten **Last event time** (Uhrzeit des letzten Ereignisses) suchen.
+ **Kubernetes-API-Server-Komponentenprotokolle (`api`)** – `kube-apiserver-1234567890abcdef01234567890abcde `
+ **Prüfung (`audit`)** – `kube-apiserver-audit-1234567890abcdef01234567890abcde `
+ **Authentifikator (`authenticator`)** – `authenticator-1234567890abcdef01234567890abcde `
+ **Controller-Manager (`controllerManager`)** – `kube-controller-manager-1234567890abcdef01234567890abcde `
+ **Scheduler (`scheduler`)** – `kube-scheduler-1234567890abcdef01234567890abcde `
1. Sehen Sie sich die Ereignisse des Protokollstreams an.
Sie sollten beispielsweise die anfänglichen API-Server-Flags für den Cluster sehen, wenn Sie den oberen Teil von `kube-apiserver-1234567890abcdef01234567890abcde ` anzeigen.
**Anmerkung**
Wenn die API-Serverprotokolle am Anfang des Protokollstreams nicht angezeigt werden, ist es wahrscheinlich, dass die API-Serverprotokolldatei auf dem Server rotiert wurde, bevor Sie die API-Serverprotokollierung auf dem Server aktiviert haben. Protokolldateien, die rotiert wurden, bevor die API-Serverprotokollierung aktiviert wurde, können nicht exportiert werden CloudWatch.
Sie können jedoch einen neuen Cluster mit derselben Kubernetes-Version erstellen und beim Erstellen des Clusters die API-Serverprotokollierung aktivieren. Für Cluster mit derselben Plattformversion sind dieselben Flags aktiviert, daher sollten Ihre Flags mit den Flags des neuen Clusters übereinstimmen. Wenn Sie die Anzeige der Flags für den neuen Cluster in abgeschlossen haben CloudWatch, können Sie den neuen Cluster löschen.
# API-Aufrufe als AWS-CloudTrail-Ereignisse protokollieren
Amazon EKS ist in AWS CloudTrail integriert. CloudTrail ist ein Service, der eine Aufzeichnung der Aktionen eines Benutzers, einer Rolle oder eines AWS-Services in Amazon EKS bereitstellt. CloudTrail erfasst alle API-Aufrufe für Amazon EKS als Ereignisse. Dazu gehören Aufrufe von der Amazon-EKS-Konsole und von Code-Aufrufen der Amazon-EKS-API-Operationen.
Wenn Sie einen Trail erstellen, können Sie die kontinuierliche Bereitstellung von CloudTrail-Ereignissen an einen Amazon S3-Bucket aktivieren. Dies umfasst Ereignisse von Amazon EKS. Wenn Sie keinen Verlauf konfigurieren, können Sie die neuesten Ereignisse in der CloudTrail-Konsole trotzdem in **Ereignisverlauf** anzeigen. Anhand der Informationen, die CloudTrail sammelt, können Sie mehrere Details zu einer Anfrage ermitteln. Sie können zum Beispiel ermitteln, wann eine Anfrage an Amazon EKS gestellt wurde, von welcher IP-Adresse aus die Anfrage gestellt wurde und wer die Anfrage gestellt hat.
Weitere Informationen zu CloudTrail finden Sie im [AWS-CloudTrail-Benutzerhandbuch](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
**Topics**
+ [Hilfreiche Referenzen für AWS CloudTrail anzeigen](service-name-info-in-cloudtrail.md)
+ [Analyse von AWS-CloudTrail-Protokolldateieinträgen](understanding-service-name-entries.md)
+ [Anzeigen von Metriken für Amazon-EC2-Auto-Scaling-Gruppen](enable-asg-metrics.md)
# Hilfreiche Referenzen für AWS CloudTrail anzeigen
Wenn Sie Ihr AWS-Konto erstellen, wird CloudTrail ebenfalls in Ihrem AWS-Konto aktiviert. Wenn in Amazon EKS eine Aktivität auftritt, wird sie in einem CloudTrail-Ereignis zusammen mit anderen AWS-Service-Ereignissen im **Ereignisverlauf** aufgezeichnet. Sie können die neusten Ereignisse in Ihr AWS-Konto herunterladen und dort suchen und anzeigen. Weitere Informationen finden Sie unter [Anzeigen von Ereignissen mit dem CloudTrail-API-Ereignisverlauf](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Für eine fortlaufende Aufzeichnung der Ereignisse in Ihrem AWS-Konto, darunter Ereignisse für Amazon EKS, können Sie einen Pfad (Trail) erstellen. Ein *Trail* ermöglicht es CloudTrail, Protokolldateien in einem Amazon-S3-Bucket bereitzustellen. Wenn Sie einen Trail in der Konsole anlegen, gilt dieser für alle AWS-Regionen. Der Trail protokolliert Ereignisse aus allen AWS-Regionen in der AWS-Partition und stellt die Protokolldateien in dem Amazon-S3-Bucket bereit, den Sie angeben. Darüber hinaus können Sie andere AWS-Services konfigurieren, um die in den CloudTrail-Protokollen erfassten Ereignisdaten weiter zu analysieren und entsprechend zu handeln. Weitere Informationen finden Sie in den folgenden Ressourcen.
+ [Übersicht zum Erstellen eines Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [In CloudTrail unterstützte Services und Integrationen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Konfigurieren von Amazon SNS-Benachrichtigungen für CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Empfangen von CloudTrail-Protokolldateien aus mehreren Regionen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) und [Empfangen von CloudTrail-Protokolldateien von mehreren Konten](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html).
Alle Amazon EKS-Aktionen werden von CloudTrail protokolliert und sind in der [Amazon EKS-API-Referenz](https://docs.aws.amazon.com/eks/latest/APIReference/) dokumentiert. Beispielsweise generieren das Aufrufen der Abschnitte [CreateCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), [ListClusters](https://docs.aws.amazon.com/eks/latest/APIReference/API_ListClusters.html) und [DeleteCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DeleteCluster.html) Einträge in den CloudTrail-Protokolldateien.
Jeder Ereignis- oder Protokolleintrag enthält Informationen über die Art der für die Abfrage genutzten IAM-Identität und dazu, welche Anmeldeinformationen verwendet wurden. Wenn temporäre Anmeldeinformationen verwendet wurden, zeigt der Eintrag, wie die Anmeldeinformationen bezogen wurden.
Weitere Informationen finden Sie unter [CloudTrail-Element userIdentity](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
# Analyse von AWS-CloudTrail-Protokolldateieinträgen
Ein Trail ist eine Konfiguration, durch die Ereignisse als Protokolldateien an den von Ihnen angegebenen Amazon-S3-Bucket übermittelt werden. CloudTrail-Protokolldateien können einen oder mehrere Einträge enthalten. Ein Ereignis stellt eine einzelne Anfrage aus einer beliebigen Quelle dar und enthält unter anderem Informationen über die angeforderte Aktion. Dazu gehören Informationen zu Datum und Uhrzeit der Aktion sowie zu den verwendeten Anfrageparameter. CloudTrail-Protokolldateien sind keine geordnete Stack-Verfolgung der öffentlichen API-Aufrufe und werden daher nicht in einer bestimmten Reihenfolge angezeigt.
Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag, der die Aktion [https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html) demonstriert.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "AKIAIOSFODNN7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/username",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "username"
},
"eventTime": "2018-05-28T19:16:43Z",
"eventSource": "eks.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "region-code",
"sourceIPAddress": "205.251.233.178",
"userAgent": "PostmanRuntime/6.4.0",
"requestParameters": {
"resourcesVpcConfig": {
"subnetIds": [
"subnet-a670c2df",
"subnet-4f8c5004"
]
},
"roleArn": "arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonEKS-CAC1G1VH3ZKZ",
"clusterName": "test"
},
"responseElements": {
"cluster": {
"clusterName": "test",
"status": "CREATING",
"createdAt": 1527535003.208,
"certificateAuthority": {},
"arn": "arn:aws:eks:region-code:111122223333:cluster/test",
"roleArn": "arn:aws:iam::111122223333:role/AWSServiceRoleForAmazonEKS-CAC1G1VH3ZKZ",
"version": "1.10",
"resourcesVpcConfig": {
"securityGroupIds": [],
"vpcId": "vpc-21277358",
"subnetIds": [
"subnet-a670c2df",
"subnet-4f8c5004"
]
}
}
},
"requestID": "a7a0735d-62ab-11e8-9f79-81ce5b2b7d37",
"eventID": "eab22523-174a-499c-9dd6-91e7be3ff8e3",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
## Protokolleinträge für serviceverknüpfte Amazon-EKS-Rollen
Die serviceverknüpften Amazon EKS-Rollen führen API-Aufrufe an AWS-Ressourcen aus. CloudTrail-Protokolleinträge mit `username: AWSServiceRoleForAmazonEKS` und `username: AWSServiceRoleForAmazonEKSNodegroup` werden für Aufrufe angezeigt, die von den serviceverknüpften Amazon-EKS-Rollen ausgeführt werden. Weitere Informationen zu Amazon EKS und serviceverknüpften Rollen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon EKS](using-service-linked-roles.md).
Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag, der eine [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html)-Aktion der serviceverknüpften Rolle `AWSServiceRoleForAmazonEKSNodegroup` veranschaulicht, die im `sessionContext` vermerkt ist.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA3WHGPEZ7SJ2CW55C5:EKS",
"arn": "arn:aws:sts::111122223333:assumed-role/AWSServiceRoleForAmazonEKSNodegroup/EKS",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA3WHGPEZ7SJ2CW55C5",
"arn": "arn:aws:iam::111122223333:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup",
"accountId": "111122223333",
"userName": "AWSServiceRoleForAmazonEKSNodegroup"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2020-02-26T00:56:33Z"
}
},
"invokedBy": "eks-nodegroup.amazonaws.com"
},
"eventTime": "2020-02-26T00:56:34Z",
"eventSource": "iam.amazonaws.com",
"eventName": "DeleteInstanceProfile",
"awsRegion": "region-code",
"sourceIPAddress": "eks-nodegroup.amazonaws.com",
"userAgent": "eks-nodegroup.amazonaws.com",
"requestParameters": {
"instanceProfileName": "eks-11111111-2222-3333-4444-abcdef123456"
},
"responseElements": null,
"requestID": "11111111-2222-3333-4444-abcdef123456",
"eventID": "11111111-2222-3333-4444-abcdef123456",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
# Anzeigen von Metriken für Amazon-EC2-Auto-Scaling-Gruppen
Bei von Amazon EKS verwalteten Knotengruppen sind Gruppenmetriken von Amazon EC2 Auto Scaling standardmäßig und ohne zusätzliche Kosten aktiviert. Die Auto-Scaling-Gruppe übermittelt jede Minute Stichprobendaten an Amazon CloudWatch. Diese Metriken können nach dem Namen der Auto-Scaling-Gruppen verfeinert werden. Sie bieten Ihnen kontinuierliche Transparenz hinsichtlich des Verlaufs der Auto-Scaling-Gruppe, die Ihre verwalteten Knotengruppen unterstützt, beispielsweise hinsichtlich Änderungen der Gruppengröße im Laufe der Zeit. Die Metriken der Auto-Scaling-Gruppe sind in [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) oder in der Auto-Scaling-Konsole verfügbar. Weitere Informationen finden Sie unter [Überwachung von CloudWatch-Metriken für Ihre Auto-Scaling-Gruppen und -Instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html).
Mit der Erfassung von Auto-Scaling-Gruppenmetriken können Sie die Skalierung von verwalteten Knotengruppen überwachen. Die Auto-Scaling-Gruppenmetriken zeigen die minimale, maximale und gewünschte Größe einer Auto-Scaling-Gruppe an. Sie können eine Warnung auslösen, wenn die Anzahl der Knoten in einer Knotengruppe unter die Mindestgröße fällt, was auf eine fehlerhafte Knotengruppe hindeuten würde. Die Nachverfolgung der Knotengruppengröße ist auch nützlich, um die maximale Anzahl anzupassen, damit Ihre Datenebene nicht an Kapazität verliert.
Wenn Sie diese Messwerte nicht erfassen lassen möchten, können Sie alle oder nur einige davon deaktivieren. So können Sie beispielsweise Störungen in Ihren CloudWatch-Dashboards vermeiden. Weitere Informationen finden Sie unter [Amazon-CloudWatch-Metriken für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html).
# Senden von Metrik- und Nachverfolgungsdaten mit ADOT Operator
Amazon EKS unterstützt die Verwendung der AWS-Managementkonsole, AWS-CLI sowie der Amazon-EKS-API zur Installation und Verwaltung von [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/)-Operator. Dadurch wird es einfacher, Ihre auf Amazon EKS ausgeführten Anwendungen zu aktivieren, um Metrik- und Nachverfolgungsdaten an mehrere Überwachungsservices wie [Amazon CloudWatch](https://console.aws.amazon.com/cloudwatch), [Prometheus](https://console.aws.amazon.com/prometheus) und [X-Ray](https://console.aws.amazon.com/xray) zu senden.
Weitere Informationen finden Sie unter [Erste Schritte mit AWS Distro für OpenTelemetry unter Verwendung von EKS-Add-Ons](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on) in der Dokumentation zu AWS Distro for OpenTelemetry.
# Anzeigen aggregierter Daten zu Cluster-Ressourcen mit dem EKS-Dashboard
## Was ist das Amazon-EKS-Dashboard?
Das Amazon EKS-Dashboard bietet konsolidierten Einblick in Ihre Kubernetes-Cluster in mehreren AWS Regionen und AWS Konten. Mit diesem Dashboard können Sie:
+ Verfolgen Sie Cluster, für die innerhalb der nächsten 90 Tage end-of-support automatische Upgrades geplant sind.
+ Die Kosten für die EKS-Steuerebene für Cluster mit erweitertem Support ermitteln.
+ Cluster mit Erkenntnissen überprüfen, die vor einem Upgrade beachtet werden sollten.
+ Verwaltete Knotengruppen identifizieren, auf denen bestimmte AMI-Versionen ausgeführt werden.
+ Die Verteilung der Cluster-Support-Typen (Standard-Support im Vergleich zu erweitertem Support) überwachen.
Das EKS-Dashboard ist in EKS Cluster Insights integriert, um Probleme mit Ihren Clustern aufzudecken, wie z. B. die Verwendung von veraltetem Kubernetes. APIs Weitere Informationen finden Sie unter [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md).
**Anmerkung**
Das EKS-Dashboard ist nicht in Echtzeit verfügbar und wird alle 12 Stunden aktualisiert. Informationen zur Echtzeit-Cluster-Überwachung finden Sie unter [Überwachung der Cluster-Leistung und Anzeige von Protokollen](eks-observe.md)
## Wie verwendet das Dashboard AWS Organizations?
Für die Funktionalität des Amazon EKS-Dashboards ist die Integration von AWS Organizations erforderlich. Es nutzt AWS Organizations, um Clusterinformationen auf sichere Weise kontenübergreifend zu sammeln. Diese Integration ermöglicht eine zentrale Verwaltung und Steuerung, wenn Ihre AWS Infrastruktur skaliert.
Wenn AWS Organizations für Ihre Infrastruktur nicht aktiviert ist, finden Sie Anweisungen zur Einrichtung im AWS [Organizations-Benutzerhandbuch](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html).
### Regions- und kontoübergreifender Zugriff
Das EKS-Dashboard kann Clusterressourcen in jedem Konto anzeigen, das Mitglied der AWS Organisation ist. Informationen zum Generieren einer Liste der AWS Konten in Ihrer Organisation finden Sie unter [Exportieren von Details für alle Konten in einer Organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_export.html).
Die AWS Region us-east-1 generiert das Dashboard. Sie müssen sich in dieser Region anmelden, um das Dashboard anzuzeigen. Das Dashboard aggregiert Daten über AWS Regionen hinweg, beinhaltet jedoch keine Regionen in China. `GovCloud`
### Wichtige Begriffe
+ ** AWS Organisation**: Eine einheitliche Verwaltungsstruktur für mehrere AWS Konten.
+ **Verwaltungskonto**: Das Hauptkonto, das die AWS Organisation kontrolliert.
+ **Mitgliedskonto**: Jedes Konto innerhalb der Organisation mit Ausnahme des Verwaltungskontos.
+ **Delegierter Administrator**: Ein Mitgliedskonto, dem bestimmte kontoübergreifende Administratorrechte gewährt wurden. Innerhalb des Verwaltungskontos können Sie pro AWS Dienst ein delegiertes Administratorkonto auswählen.
+ **Vertrauenswürdiger Zugriff**: Berechtigung für das EKS-Dashboard, auf Cluster-Informationen über Organisationskonten hinweg zuzugreifen.
+ **Serviceverknüpfte Rolle (SLRs)**: Eine einzigartige Art von IAM-Rolle, die direkt mit einem Dienst verknüpft ist. AWS Das EKS-Dashboard verwendet eine SLR, um Informationen zu Ihren Konten und Organisationen zu lesen.
+ Weitere Informationen finden Sie unter [Terminologie und Konzepte](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) im AWS Organizations User Guide.
### Allgemeine Übersicht
1. Greifen Sie auf das Verwaltungskonto Ihrer AWS Organisation zu.
+ Die Schritte für den Zugriff auf das Verwaltungskonto hängen davon ab, wie Sie Ihre AWS Organisation konfiguriert haben. Sie können beispielsweise über AWS [Identity Center](https://aws.amazon.com/iam/identity-center/) oder [Okta](https://www.okta.com/partners/aws/) auf das Verwaltungskonto zugreifen.
1. Aktivieren Sie den vertrauenswürdigen Zugriff über die EKS-Konsole.
1. Weisen Sie anhand seiner AWS Konto-ID einen delegierten Administrator zu.
1. Wechseln Sie zum Konto des delegierten Administrators.
1. Greifen Sie auf die erweiterte EKS-Konsole mit organisationsweiter Sichtbarkeit zu.
## Aktivieren Sie das EKS-Dashboard über die AWS Konsole
**Wichtig**
Sie müssen mit dem Verwaltungskonto Ihrer AWS Organisation angemeldet sein, um das EKS-Dashboard zu aktivieren.
### Zugriff auf EKS-Dashboard-Einstellungen
1. Überprüfen Sie Folgendes:
1. Sie haben AWS Organizations aktiviert und konfiguriert.
1. Sie sind beim Verwaltungskonto der Organisation angemeldet.
1. Sie sehen die AWS Management Console in der Region US-East-1.
1. Navigieren Sie zur EKS-Konsole.
1. Öffnen Sie in der linken Seitenleiste die Dashboard-Einstellungen.
### Einrichtung des Zugriffs auf das Amazon-EKS-Dashboard
1. Suchen Sie die AWS Konto-ID des AWS Kontos, dem Sie die Anzeige des EKS-Dashboards ermöglichen möchten.
1. Dieser Schritt ist optional, wird jedoch empfohlen. Wenn Sie dies nicht tun, können Sie nur über das Verwaltungskonto auf das Dashboard zugreifen. Als bewährte Methode sollten Sie den Zugriff auf das Verwaltungskonto beschränken.
1. Klicken Sie auf **Vertrauenswürdigen Zugriff aktivieren**.
1. Sie können das Dashboard nun über das Verwaltungskonto anzeigen.
1. Klicken Sie auf **Delegierten Administrator registrieren** und geben Sie die Konto-ID des AWS Kontos ein, mit dem Sie das Dashboard aufrufen möchten.
1. Sie können das Dashboard nun über das Konto des delegierten Administrators oder das Verwaltungskonto anzeigen.
Informationen zu den für die Aktivierung des Dashboards erforderlichen Berechtigungen finden Sie unter [Erforderliche Mindest-IAM-Richtlinien](cluster-dashboard-orgs.md#dashboard-iam-policy).
## EKS-Dashboard anzeigen
1. Melden Sie sich beim delegierten Administratorkonto (empfohlen) oder beim Verwaltungskonto an.
1. Melden Sie sich in der Region us-east-1 an.
1. Wechseln Sie zum EKS-Service und wählen Sie in der linken Seitenleiste „Dashboard“ aus.
**Anmerkung**
[Überprüfen Sie die zum Anzeigen des EKS-Dashboards erforderlichen IAM-Berechtigungen.](cluster-dashboard-orgs.md#eks-dashboard-view-policy)
## Dashboard konfigurieren
Sie können die Ansicht des Dashboards konfigurieren und Ressourcen filtern.
### Verfügbare Ressourcen
+ **Clusters**: Zeigen Sie aggregierte Informationen zum Status und Standort von EKS-Clustern an.
+ Cluster mit Integritätsproblemen
+ Cluster mit erweitertem EKS-Support.
+ Aufschlüsselung der Cluster nach Kubernetes-Version.
+ **Verwaltete Knotengruppen**: Sehen Sie sich die verwalteten Knotengruppen und EC2 Instanzen an.
+ Knotengruppen nach AMI-Typ, wie beispielsweise Amazon Linux oder Bottlerocket.
+ Probleme mit der Integrität der Knotengruppe.
+ Instance-Typ-Verteilung
+ **Add-Ons**: Erfahren Sie, welche Amazon-EKS-Add-Ons Sie installiert haben und welchen Status sie haben.
+ Anzahl der Installationen pro Add-On.
+ Add-Ons mit Integritätsproblemen.
+ Versionsverteilung pro Add-On.
### Verfügbare Ansichten
+ **Diagrammansicht**
+ Eine anpassbare Widget-Ansicht, die Diagramme und Visualisierungen der ausgewählten Ressource anzeigt.
+ Änderungen an der Diagrammansicht, wie beispielsweise das Entfernen eines Widgets, sind für alle Benutzer des EKS-Dashboards sichtbar.
+ **Ressourcenansicht**
+ Eine Listenansicht der ausgewählten Ressource, die Filter unterstützt.
+ **Kartenansicht**
+ Zeigen Sie die geografische Verteilung der ausgewählten Ressource an.
### EKS-Dashboard filtern
Sie können das EKS-Dashboard nach folgenden Kriterien filtern:
+ AWS Konto
+ Organisationseinheit, definiert durch AWS Organizations
+ AWS Region
## Deaktivieren Sie das EKS-Dashboard über die AWS Konsole
1. Überprüfen Sie Folgendes:
1. Sie haben AWS Organizations aktiviert und konfiguriert.
1. Sie sind beim Verwaltungskonto der Organisation angemeldet.
1. Sie sehen die AWS Management Console in der Region US-East-1.
1. Navigieren Sie zur EKS-Konsole.
1. Öffnen Sie in der linken Seitenleiste die Dashboard-Einstellungen.
1. Klicken Sie auf **Vertrauenswürdigen Zugriff deaktivieren**.
## Fehlerbehebung im EKS-Dashboard
### Problem beim Aktivieren des EKS-Dashboards
+ Sie müssen mit dem Verwaltungskonto einer AWS Organisation angemeldet sein.
+ Wenn Sie noch keine AWS Organisation haben, erstellen Sie eine. Erfahren Sie, wie Sie eine [Organisation erstellen und konfigurieren](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_tutorials_basic.html).
+ Wenn Ihr AWS Konto bereits Mitglied einer AWS Organisation ist, identifizieren Sie den Administrator der Organisation.
+ Sie müssen mit dem AWS Konto angemeldet sein und über ausreichende IAM-Berechtigungen verfügen, um AWS Organisationsressourcen erstellen und aktualisieren zu können.
### Problem beim Anzeigen des EKS-Dashboards
+ Sie müssen bei einem der folgenden AWS Konten angemeldet sein:
+ Das Verwaltungskonto der AWS Organisation
+ Ein delegiertes Administratorkonto, das in den EKS-Dashboard-Einstellungen des Verwaltungskontos angegeben ist.
+ Wenn Sie das EKS-Dashboard erst kürzlich aktiviert haben, beachten Sie, dass die anfängliche Dateneingabe bis zu 12 Stunden dauern kann.
+ [Versuchen Sie, das Dashboard mithilfe der CLI erneut zu aktivieren](cluster-dashboard-orgs.md#dashboard-enable-cli), einschließlich der Erstellung der serviceverknüpften Rolle.
### Dashboard-Widgets verschieben sich unerwartet
+ Das EKS-Dashboard speichert die konfigurierbare Widget-Ansicht auf AWS Kontoebene. Wenn Sie die Widget-Ansicht ändern, können andere Personen, die dasselbe AWS Konto verwenden, die Änderungen sehen.
# Konfiguration der EKS-Dashboard-Integration mit AWS Organizations
Dieser Abschnitt enthält step-by-step Anweisungen zur Konfiguration der Integration des EKS-Dashboards mit AWS Organizations. Sie erfahren, wie Sie den vertrauenswürdigen Zugriff zwischen Services aktivieren und deaktivieren sowie delegierte Administratorkonten registrieren und deregistrieren können. Jede Konfigurationsaufgabe kann entweder über die AWS Konsole oder die AWS CLI ausgeführt werden.
## Den vertrauenswürdigen Zugriff aktivieren
Durch vertrauenswürdigen Zugriff wird das EKS-Dashboard autorisiert, sicher auf Cluster-Informationen aller Konten in Ihrem Unternehmen zuzugreifen.
### Mithilfe der AWS Konsole
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Navigieren Sie zur EKS-Konsole in der Region us-east-1.
1. Wählen Sie in der linken Seitenleiste „Dashboard-Einstellungen“ aus.
1. Klicken Sie auf **Vertrauenswürdigen Zugriff aktivieren**.
**Anmerkung**
Wenn Sie den vertrauenswürdigen Zugriff über die EKS-Konsole aktivieren, erstellt das System automatisch die serviceverknüpfte `AWSServiceRoleForAmazonEKSDashboard`-Rolle. Diese automatische Erstellung erfolgt nicht, wenn Sie den vertrauenswürdigen Zugriff über die AWS CLI oder die AWS Organisationskonsole aktivieren.
### Verwenden der AWS CLI
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Führen Sie die folgenden Befehle aus:
```
aws iam create-service-linked-role --aws-service-name dashboard.eks.amazonaws.com
aws organizations enable-aws-service-access --service-principal eks.amazonaws.com
```
## So deaktivieren Sie den vertrauenswürdigen Zugriff
Durch die Deaktivierung des vertrauenswürdigen Zugriffs wird dem EKS-Dashboard die Berechtigung zum Zugriff auf Cluster-Informationen über die Konten Ihrer Organisation hinweg entzogen.
### Verwenden der AWS Konsole
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Navigieren Sie zur EKS-Konsole in der Region us-east-1.
1. Wählen Sie in der linken Seitenleiste „Dashboard-Einstellungen“ aus.
1. Klicken Sie auf **Vertrauenswürdigen Zugriff deaktivieren**.
### Verwenden der AWS CLI
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Führen Sie den folgenden Befehl aus:
```
aws organizations disable-aws-service-access --service-principal eks.amazonaws.com
```
## Aktivieren eines delegierten Administrators
Ein delegierter Administrator ist ein Benutzerkonto, dem die Berechtigung zum Zugriff auf das EKS-Dashboard gewährt wurde.
### Verwenden der AWS Konsole
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Navigieren Sie zur EKS-Konsole in der Region us-east-1.
1. Wählen Sie in der linken Seitenleiste „Dashboard-Einstellungen“ aus.
1. Klicken Sie auf **Delegierten Administrator registrieren**.
1. Geben Sie die Konto-ID des AWS Kontos ein, das Sie als delegierten Administrator auswählen möchten.
1. Bestätigen Sie die Registrierung.
### Verwenden der AWS CLI
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Führen Sie den folgenden Befehl aus und ersetzen Sie `123456789012` durch Ihre Konto-ID:
```
aws organizations register-delegated-administrator --account-id 123456789012 --service-principal eks.amazonaws.com
```
## Deaktivierung eines delegierten Administratorkontos
Durch die Deaktivierung eines delegierten Administrators wird die Berechtigung des Kontos für den Zugriff auf das EKS-Dashboard entfernt.
### Verwenden der AWS Konsole
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Navigieren Sie zur EKS-Konsole in der Region us-east-1.
1. Wählen Sie in der linken Seitenleiste „Dashboard-Einstellungen“ aus.
1. Suchen Sie den delegierten Administrator in der Liste.
1. Klicken Sie neben dem Konto, das Sie als delegierten Administrator entfernen möchten, auf **Abmelden**.
### Verwenden der AWS CLI
1. Melden Sie sich beim Verwaltungskonto Ihrer AWS Organisation an.
1. Führen Sie den folgenden Befehl aus und ersetzen Sie dabei `123456789012` durch die Konto-ID des delegierten Administrators:
```
aws organizations deregister-delegated-administrator --account-id 123456789012 --service-principal eks.amazonaws.com
```
## Erforderliche Mindestanforderungen an IAM-Richtlinien
In diesem Abschnitt werden die IAM-Mindestrichtlinien beschrieben, die erforderlich sind, um vertrauenswürdigen Zugriff zu ermöglichen und einen Administrator für die EKS-Dashboard-Integration mit AWS Organizations zu delegieren.
### Richtlinie für die Gewährung vertrauenswürdigen Zugriffs
Um den vertrauenswürdigen Zugriff zwischen EKS Dashboard und AWS Organizations zu aktivieren, benötigen Sie die folgenden Berechtigungen:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:EnableAWSServiceAccess",
"organizations:DescribeOrganization",
"organizations:ListAWSServiceAccessForOrganization"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/dashboard.eks.amazonaws.com/AWSServiceRoleForAmazonEKSDashboard"
}
]
}
```
### Richtlinie zur Übertragung von Administratorrechten
Um einen delegierten Administrator für das EKS-Dashboard zu registrieren oder zu deregistrieren, benötigen Sie die folgenden Berechtigungen:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:RegisterDelegatedAdministrator",
"organizations:DeregisterDelegatedAdministrator",
"organizations:ListDelegatedAdministrators"
],
"Resource": "*"
}
]
}
```
### Richtlinie zum Anzeigen des EKS-Dashboards
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSDashboardReadOnly",
"Effect": "Allow",
"Action": [
"eks:ListDashboardData",
"eks:ListDashboardResources",
"eks:DescribeClusterVersions"
],
"Resource": "*"
},
{
"Sid": "AmazonOrganizationsReadOnly",
"Effect": "Allow",
"Action": [
"organizations:DescribeOrganization",
"organizations:ListAWSServiceAccessForOrganization",
"organizations:ListRoots",
"organizations:ListAccountsForParent",
"organizations:ListOrganizationalUnitsForParent"
],
"Resource": "*"
},
{
"Sid": "AmazonOrganizationsDelegatedAdmin",
"Effect": "Allow",
"Action": [
"organizations:ListDelegatedAdministrators"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"organizations:ServicePrincipal": "eks.amazonaws.com"
}
}
}
]
}
```
**Anmerkung**
Diese Richtlinien müssen dem IAM-Prinzipal (Benutzer oder Rolle) im Verwaltungskonto Ihrer AWS Organisation zugeordnet sein. Mitgliedskonten können keinen vertrauenswürdigen Zugriff aktivieren oder Administratoren delegieren.