Installieren des CloudWatch-Agenten über das Add-On von Amazon CloudWatch Observability EKS oder das Helm-Chart
Anmerkung
Wir empfehlen die Nutzung von Amazon-Linux-2-Knoten, damit bei der Verwendung des Amazon-CloudWatch-Observability-Add-ons für vollständige Kompatibilität gesorgt ist. Bei Nutzung von Amazon-Linux-2023-Knoten sind die von Container Insights bereitgestellten Datenebenen- und Hostprotokolle aufgrund des in Amazon Linux 2023 geänderten Mechanismus zur Systemprotokollierung standardmäßig nicht verfügbar. Die Anwendungsprotokolle funktionieren weiterhin wie erwartet. Weitere Informationen zu den Änderungen in Amazon Linux 2023 finden Sie im Amazon-Linux-2023-Benutzerhandbuch.
Sie können entweder das Amazon CloudWatch Observability EKS-Add-on oder das Amazon CloudWatch Observability Helm-Chart verwenden, um den CloudWatch-Agenten und den Fluent-Bit-Agenten auf einem Amazon-EKS-Cluster zu installieren. Sie können das Helm-Chart auch verwenden, um den CloudWatch-Agenten und den Fluent-Bit-Agenten auf einem Kubernetes-Cluster zu installieren, der nicht auf Amazon EKS gehostet wird.
Die Verwendung einer der beiden Methoden auf einem Amazon-EKS-Cluster aktiviert standardmäßig sowohl Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS als auch CloudWatch Application Signals. Mit beiden Features können Sie Infrastrukturmetriken, Anwendungs-Leistungstelemetrie und Container-Protokolle aus dem Amazon-EKS-Cluster erfassen.
Bei Container Insights mit verbesserter Beobachtbarkeit für Amazon EKS werden die Container-Insights-Metriken pro Beobachtung abgerechnet, anstatt pro gespeicherter Metrik oder aufgenommenem Protokoll. Bei Application Signals basiert die Abrechnung auf eingehenden Anfragen an Ihre Anwendungen, ausgehenden Anfragen von Ihren Anwendungen und jedem konfigurierten Servicelevel-Ziel (SLO). Jede eingehende Anfrage generiert ein Anwendungssignal, und jede ausgehende Anfrage generiert ein Anwendungssignal. Jeder SLO erzeugt zwei Anwendungssignale pro Messzeitraum. Weitere Informationen zur Preisgestaltung von CloudWatch finden Sie unter Amazon CloudWatch – Preise
Beide Methoden aktivieren Container Insights sowohl auf Linux- als auch auf Windows-Worker-Knoten im Amazon-EKS-Cluster. Um Container Insights unter Windows zu aktivieren, müssen Sie Version 1.5.0 oder höher des Amazon-EKS-Add-ons oder das Helm-Chart verwenden. Application Signals wird unter Windows in Amazon-EKS-Clustern nicht unterstützt.
Das Add-On von Amazon CloudWatch Observability EKS wird auf Amazon-EKS-Clustern unterstützt, die mit Kubernetes Version 1.23 oder höher ausgeführt werden.
Wenn Sie das Add-on oder die Helm-Chart installieren, müssen Sie auch IAM-Berechtigungen erteilen, damit der CloudWatch-Agent Metriken, Protokolle und Ablaufverfolgungen an CloudWatch senden kann. Es gibt zwei Möglichkeiten dafür:
-
Fügen Sie eine Richtlinie an die IAM-Rolle Ihrer Worker-Knoten an. Diese Option gewährt Worker-Knoten die Erlaubnis, Telemetrie an CloudWatch zu senden.
-
Verwenden Sie eine IAM-Rolle für Servicekonten für die Agenten-Pods und fügen Sie die Richtlinie an diese Rolle an. Dies funktioniert nur für Amazon-EKS-Cluster. Diese Option gewährt CloudWatch nur Zugriff auf die entsprechenden Agenten-Pods.
Themen
Option 2: Installation mit IAM-Berechtigungen auf Worker-Knoten
Option 3: Installation mithilfe der IAM-Servicekonto-Rolle (gilt nur für die Verwendung des Add-ons)
Konfigurieren von Application Signals für Ihren Amazon-EKS-Cluster
Fehlerbehebung mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Chart
Option 1: Installation mithilfe von EKS Pod Identity
Bei Verwendung von Version 3.1.0 oder höher des Add-ons können Sie EKS Pod Identity nutzen, um dem Add-On die erforderlichen Berechtigungen zu erteilen. EKS Pod Identity ist die empfohlene Option und bietet Vorteile wie geringste Berechtigung, Rotation von Anmeldeinformationen und Überprüfbarkeit. Darüber hinaus ermöglicht Ihnen die Nutzung von EKS Pod Identity, das EKS-Add-on als Teil der Clustererstellung selbst zu installieren.
Zur Verwendung dieser Methode befolgen Sie die Schritte zur EKS-Pod-Identity-Zuordnung, um die IAM-Rolle zu erstellen und den EKS-Pod-Identity-Agenten einzurichten.
Installieren Sie anschließend das EKS-Add-On Amazon CloudWatch Observability. Um das Add-on zu installieren, können Sie AWS CLI, die Amazon-EKS-Konsole, CloudFormation oder Terraform verwenden.
Option 2: Installation mit IAM-Berechtigungen auf Worker-Knoten
Um diese Methode zu verwenden, fügen Sie zunächst die IAM-Richtlinie CloudWatchAgentServerPolicy an Ihre Worker-Knoten an, indem Sie den folgenden Befehl eingeben. Ersetzen Sie in diesem Befehl my-worker-node-role durch die IAM-Rolle, die von Ihren Kubernetes-Worker-Knoten verwendet wird.
aws iam attach-role-policy \ --role-namemy-worker-node-role\ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
Installieren Sie anschließend das EKS-Add-On Amazon CloudWatch Observability. Um das Add-on zu installieren, können Sie AWS CLI, die Konsole, CloudFormation oder Terraform verwenden.
Option 3: Installation mithilfe der IAM-Servicekonto-Rolle (gilt nur für die Verwendung des Add-ons)
Diese Methode ist nur verwendbar, wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden. Vor dem Verwenden dieser Methode, überprüfen Sie die folgenden Voraussetzungen:
-
Sie besitzen einen funktionsfähigen Amazon-EKS-Cluster mit angefügten Knoten in einer der AWS-Regionen, von denen Container Insights unterstützt wird. Eine Liste der unterstützten Regionen finden Sie unter Container Insights.
-
Sie haben
kubectlfür den Cluster installiert und konfiguriert. Weitere Informationen finden Sie unter Installieren vonkubectlim Amazon-EKS-Benutzerhandbuch. -
Sie haben
eksctlinstalliert. Weitere Informationen finden Sie unter Installieren oder Aktualisieren voneksctlim Amazon-EKS-Benutzerhandbuch.
Hinweise zu Amazon EKS Hybrid Nodes
Für Hybridknoten sind keine Metriken auf Knotenebene verfügbar, da Container Insights für Metriken auf Knotenebene von der Verfügbarkeit des EX2 Instance Metadata Service (IMDS) abhängt. Für Hybridknoten sind Metriken auf Cluster-, Workload-, Pod- und Container-Ebene verfügbar.
Nachdem Sie das Add-on gemäß den Schritten in den vorherigen Abschnitten installiert haben, müssen Sie das Add-on-Manifest aktualisieren, damit der Agent erfolgreich auf Hybridknoten ausgeführt werden kann. Bearbeiten Sie die amazoncloudwatchagents-Ressource im Cluster, um die Umgebungsvariable RUN_WITH_IRSA hinzuzufügen, die den folgenden Werten entspricht.
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
...
name: cloudwatch-agent
namespace: amazon-cloudwatch
...
spec:
...
env:
- name: RUN_WITH_IRSA # <-- Add this
value: "True" # <-- Add this
- name: K8S_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
...
(Optional) Zusätzliche Konfiguration
Themen
Die Erfassung von Container-Protokollen deaktivieren
Standardmäßig verwendet das Add-On Fluent Bit, um Container-Protokolle von allen Pods zu sammeln, und sendet die Protokolle dann an CloudWatch Logs. Informationen darüber, welche Protokolle gesammelt werden, finden Sie unter Einrichten von Fluent Bit.
Anmerkung
Weder das Add-on noch das Helm-Chart verwalten vorhandene Fluentd- oder Fluent Bit-Ressourcen in einem Cluster. Sie können die vorhandenen Fluentd- oder Fluent-Bit-Ressourcen löschen, bevor Sie das Add-on oder das Helm-Chart installieren. Alternativ können Sie Fluent Bit deaktivieren, indem Sie den Anweisungen in diesem Abschnitt folgen, um das vorhandene Setup beizubehalten und zu verhindern, dass das Add-on oder das Helm-Chart ebenfalls installiert werden.
Um die Erfassung von Container-Protokollen zu deaktivieren, wenn Sie das Amazon CloudWatch Observability EKS-Add-On verwenden, übergeben Sie beim Erstellen oder Aktualisieren des Add-Ons die folgende Option:
--configuration-values '{ "containerLogs": { "enabled": false } }'
Um die Erfassung von Container-Protokollen zu deaktivieren, wenn Sie das Helm-Chart verwenden, übergeben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option:
--set containerLogs.enabled=false
Eine benutzerdefinierte Fluent Bit-Konfiguration verwenden
Ab Version 1.7.0 des Amazon CloudWatch Observability EKS-Add-ons können Sie die Fluent Bit-Konfiguration ändern, wenn Sie das Add-on oder das Helm-Chart erstellen oder aktualisieren. Sie geben die benutzerdefinierte Fluent Bit-Konfiguration im Abschnitt auf containerLogs Stammebene der erweiterten Konfiguration des Add-ons oder die Wertüberschreibungen im Helm-Chart an. In diesem Abschnitt geben Sie die benutzerdefinierte Fluent-Bit-Konfiguration im Abschnitt config (für Linux) oder im Abschnitt configWindows (für Windows) an. Die config ist in die folgenden Unterabschnitte unterteilt:
-
service: Dieser Abschnitt stellt dieSERVICE-Konfiguration zur Definition des globalen Verhaltens der Fluent Bit-Engine dar. -
customParsers: Dieser Abschnitt stellt alle globalenPARSERdar, die Sie einbeziehen möchten und die in der Lage sind, unstrukturierte Protokolleinträge zu verarbeiten und ihnen eine Struktur zu geben, um sie einfacher zu verarbeiten und weiter zu filtern. -
extraFiles: Dieser Abschnitt kann verwendet werden, um zusätzliche Fluent-Bitconf-Dateien hinzuzufügen. Standardmäßig sind die folgenden 3conf-Dateien enthalten:-
application-log.conf: Eineconf-Datei zum Senden von Anwendungsprotokollen von Ihrem Cluster an die Protokollgruppe/aws/containerinsights/in CloudWatch Logs.my-cluster-name/application -
dataplane-log.conf: EineconfDatei zum Senden von Protokollen, die den Datenebenenkomponenten Ihres Clusters entsprechen, einschließlich CRI-Protokollen, Kubelet-Protokollen, Kube-Proxy-Protokollen und Amazon-VPC-CNI-Protokollen, an die Protokollgruppe/aws/containerinsights/in CloudWatch Logs.my-cluster-name/dataplane -
host-log.conf: Einconfzum Senden von Protokollen von/var/log/dmesg,/var/log/messagesund/var/log/secureunter Linux und Systemwinlogsunter Windows an die Protokollgruppe/aws/containerinsights/in CloudWatch.my-cluster-name/host
-
Anmerkung
Geben Sie die vollständige Konfiguration für jeden dieser einzelnen Abschnitte an, auch wenn Sie nur ein Feld innerhalb eines Unterabschnitts ändern. Wir empfehlen, die unten angegebene Standardkonfiguration als Grundlage zu verwenden und sie dann zu ändern, damit Sie die standardmäßig aktivierten Funktionen nicht deaktivieren. Sie können die folgende YAML-Konfiguration verwenden, wenn Sie die erweiterte Konfiguration für das Amazon-EKS-Add-on ändern oder wenn Sie Wertüberschreibungen für das Helm-Chart angeben.
Den Abschnitt config für Ihren Cluster finden Sie unter aws-observability / helm-charts/charts/amazon-cloudwatch-observability/values.yaml und zum Abschnitt config (für Linux) bzw. zum Abschnitt configWindows (für Windows) im Abschnitt fluentBit unter containerLogs.
Als Beispiel finden Sie hier
Wir empfehlen, dass Sie die config als YAML angeben, wenn Sie es mit der erweiterten Konfiguration des Amazon-EKS-Add-ons bereitstellen oder wenn Sie es als Wertüberschreibungen für Ihre Helm-Installation angeben. Stellen Sie sicher, dass das YAML die folgende Struktur hat.
containerLogs: fluentBit: config: service: | ... customParsers: | ... extraFiles: application-log.conf: | ... dataplane-log.conf: | ... host-log.conf: | ...
Im folgenden Beispiel config wird die globale Einstellung für das Bereinigungsintervall auf 45 Sekunden geändert. Auch wenn die einzige Änderung das Feld Flush betrifft, müssen Sie dennoch die vollständige SERVICE-Definition für den Service-Unterabschnitt angeben. Da in diesem Beispiel keine Überschreibungen für die anderen Unterabschnitte angegeben wurden, werden für sie die Standardwerte verwendet.
containerLogs: fluentBit: config: service: | [SERVICE] Flush 45 Grace 30 Log_Level error Daemon off Parsers_File parsers.conf storage.path /var/fluent-bit/state/flb-storage/ storage.sync normal storage.checksum off storage.backlog.mem_limit 5M
Die folgende Beispielkonfiguration beinhaltet eine zusätzliche Fluent-Bit conf-Datei. In diesem Beispiel fügen wir eine benutzerdefinierte my-service.conf unter extraFiles hinzu, zusätzlich zu den drei bestehenden standardmäßigen extraFiles.
containerLogs: fluentBit: config: extraFiles: my-service.conf: | [INPUT] Name tail Tag myservice.* Path /var/log/containers/*myservice*.log DB /var/fluent-bit/state/flb_myservice.db Mem_Buf_Limit 5MB Skip_Long_Lines On Ignore_Older 1d Refresh_Interval 10 [OUTPUT] Name cloudwatch_logs Match myservice.* region ${AWS_REGION} log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice log_stream_prefix ${HOST_NAME}- auto_create_group true
Im nächsten Beispiel wird eine bestehende conf-Datei vollständig von extraFiles entfernt. Die application-log.conf wird vollständig ausgeschlossen, indem sie mit einer leeren Zeichenfolge überschrieben wird. Würden Sie einfach application-log.conf in extraFiles weglassen, würde die Standardeinstellung verwendet, was wir in diesem Beispiel nicht wollen. Das Gleiche gilt für das Entfernen von benutzerdefinierten conf-Dateien, die Sie möglicherweise zuvor zu extraFiles hinzugefügt haben.
containerLogs: fluentBit: config: extraFiles: application-log.conf: ""
Verwalten von Kubernetes-Toleranzen für die installierten Pod-Workloads
Ab Version 1.7.0 des Amazon CloudWatch Observability EKS-Add-ons legen das Add-on und das Helm-Chart standardmäßig Kubernetes-Toleranzen fest, um alle Taints auf den Pod-Workloads zu tolerieren, die durch das Add-on oder das Helm-Chart installiert werden. Dadurch wird sichergestellt, dass Daemonsets wie der CloudWatch-Agent und Fluent Bit standardmäßig Pods auf allen Knoten in Ihrem Cluster planen können. Weitere Informationen zu Taints und Toleranzen finden Sie unter Taints und Toleranzen
Die vom Add-on oder dem Helm-Chart festgelegten Standardtoleranzen lauten wie folgt:
tolerations: - operator: Exists
Sie können die Standardtoleranzen überschreiben, indem Sie das Feld tolerations auf der Stammebene festlegen, wenn Sie die erweiterte Konfiguration des Add-ons verwenden oder wenn Sie das Helm-Chart mit Wertüberschreibungen installieren oder aktualisieren. Ein Beispiel könnte folgendermaßen aussehen:
tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"
Um Toleranzen vollständig auszulassen, können Sie eine Konfiguration verwenden, die wie die folgende aussieht:
tolerations: []
Alle Änderungen an den Toleranzen gelten für alle Pod-Workloads, die durch das Add-on oder das Helm-Chart installiert werden.
Deaktivieren der Erfassung von Accelerated Compute-Metriken
Standardmäßig erfasst Container Insights mit verbesserter Beobachtbarkeit Metriken für die Accelerated-Compute-Überwachung, darunter NVIDIA-GPU-Metriken, AWS Neuron-Metriken für AWS Trainium und AWS Inferentia sowie AWS Elastic Fabric Adapter (EFA)-Metriken.
NVIDIA-GPU-Metriken von Amazon-EKS-Workloads werden standardmäßig ab Version v1.3.0-eksbuild.1 des EKS-Add-ons oder des Helm-Charts und Version 1.300034.0 des CloudWatch-Agenten erfasst. Eine Liste der erfassten Metriken und der Voraussetzungen finden Sie unter NVIDIA-GPU-Metriken.
AWS Neuron-Metriken für AWS Trainium- und AWS Inferentia-Beschleuniger werden standardmäßig ab Version v1.5.0-eksbuild.1 des EKS-Add-ons oder des Helm-Charts sowie Version 1.300036.0 des CloudWatch-Agenten erfasst. Eine Liste der erfassten Metriken und der Voraussetzungen finden Sie unter AWS-Neuron-Metriken für AWS Trainium und AWS Inferentia .
AWS Elastic Fabric Adapter (EFA)-Metriken von Linux-Knoten auf Amazon-EKS-Clustern werden standardmäßig ab Version v1.5.2-eksbuild.1 des EKS-Add-ons oder des Helm-Charts und Version 1.300037.0 des CloudWatch-Agenten erfasst. Eine Liste der erfassten Metriken und der Voraussetzungen finden Sie unter AWS-Elastic-Fabric-Adapter-(EFA-)Metriken .
Sie können das Erfassen dieser Metriken deaktivieren, indem Sie das accelerated_compute_metrics-Feld in der Konfigurationsdatei des CloudWatch-Agenten auf false setzen. Dieses Feld befindet sich im Abschnitt kubernetes des Abschnitts metrics_collected in der CloudWatch-Konfigurationsdatei. Im Folgenden finden Sie eine Opt-out-Beispielkonfiguration. Weitere Informationen zur Verwendung benutzerdefinierter CloudWatch-Agentenkonfigurationen finden Sie im folgenden Abschnitt, Verwenden einer benutzerdefinierten CloudWatch-Agentenkonfiguration.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true, "accelerated_compute_metrics": false } } } }
Verwenden einer benutzerdefinierten CloudWatch-Agentenkonfiguration
Um andere Metriken, Protokolle oder Traces mit dem CloudWatch-Agenten zu erfassen, können Sie eine benutzerdefinierte Konfiguration angeben und gleichzeitig Container Insights und CloudWatch Application Signals aktiviert lassen. Betten Sie dazu die CloudWatch-Agenten-Konfigurationsdatei in den Konfigurationsschlüssel unter dem Agenten-Schlüssel der erweiterten Konfiguration ein, den Sie bei der Erstellung oder Aktualisierung des EKS-Add-ons oder Helm-Charts verwenden können. Im Folgenden wird die standardmäßige Agentenkonfiguration dargestellt, wenn Sie keine zusätzliche Konfiguration angeben.
Wichtig
Jede benutzerdefinierte Konfiguration, die Sie mithilfe zusätzlicher Konfigurationseinstellungen angeben, hat Vorrang vor der vom Agenten verwendeten Standardkonfiguration. Achten Sie darauf, standardmäßig aktivierte Funktionen wie Container Insights mit verbesserter Beobachtbarkeit und CloudWatch Application Signals nicht ungewollt zu deaktivieren. In dem Szenario, bei dem Sie eine benutzerdefinierte Agentenkonfiguration bereitstellen müssen, empfehlen wir, die folgende Standardkonfiguration als Basiskonfiguration zu verwenden und sie dann entsprechend zu ändern.
-
Zur Verwendung des Amazon CloudWatch Observability EKS-Add-ons
--configuration-values '{ "agent": { "config": { "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } } } }' -
Zur Verwendung des Helm-Charts
--set agent.config='{ "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } }'
Das folgende Beispiel zeigt die Standard-Agentenkonfiguration für den CloudWatch-Agenten unter Windows. Der CloudWatch-Agent unter Windows unterstützt keine benutzerdefinierte Konfiguration.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true }, } } }
Webhook-TLS-Zulassungszertifikate verwalten
Das Amazon CloudWatch Observability EKS-Add-on und das Helm-Chart nutzen Kubernetes-Zugangs-WebhooksAmazonCloudWatchAgent und Instrumentation und optional Kubernetes-Pod-Anfragen auf dem Cluster, wenn CloudWatch Application Signals aktiviert ist. In Kubernetes benötigen Webhooks ein TLS-Zertifikat, dem der API-Server vertraut, um die sichere Kommunikation zu gewährleisten.
Standardmäßig generieren das Amazon CloudWatch Observability EKS-Add-on und das Helm-Chart automatisch eine selbstsignierte CA und ein von dieser CA signiertes TLS-Zertifikat, um die Kommunikation zwischen dem API-Server und dem Webhook-Server zu sichern. Dieses automatisch generierte Zertifikat hat eine Standardablaufzeit von 10 Jahren und wird nach Ablauf nicht automatisch verlängert. Darüber hinaus werden das CA-Paket und das Zertifikat jedes Mal neu generiert, wenn das Add-on oder das Helm-Chart aktualisiert oder neu installiert wird, wodurch der Ablauf zurückgesetzt wird. Wenn Sie den Standardablauf des automatisch generierten Zertifikats ändern möchten, können Sie beim Erstellen oder Aktualisieren des Add-Ons die folgenden zusätzlichen Konfigurationen verwenden. Ersetzen Sie das expiry-in-days durch die gewünschte Ablaufdauer in Tagen.
-
Verwenden Sie dies für das Amazon CloudWatch Observability EKS-Add-on
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays":expiry-in-days} } }' -
Verwenden Sie dies für das Helm-Chart
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
Für eine sicherere und featurereichere Zertifizierungsstellen-Lösung bietet das Add-On optionale Unterstützung für cert-manager
Wir empfehlen Ihnen, sich mit den bewährten Methoden für die Verwaltung von TLS-Zertifikaten auf Ihren Clustern vertraut zu machen und sich für Produktionsumgebungen für cert-manager zu entscheiden. Beachten Sie, dass Sie, wenn Sie sich dafür entscheiden, den cert-manager für die Verwaltung der Webhook-TLS-Zulassungszertifikate zu aktivieren, cert-manager auf Ihrem Amazon-EKS-Cluster vorinstallieren müssen, bevor Sie das Amazon CloudWatch Observability EKS-Add-on oder das Helm-Chart installieren. Weitere Informationen zu den verfügbaren Installationsoptionen finden Sie in der cert-manager-Dokumentation
-
Wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }' -
Wenn Sie das Helm-Chart verwenden
--set admissionWebhooks.certManager.enabled=true
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
Die in diesem Abschnitt beschriebene erweiterte Konfiguration verwendet standardmäßig einen SelfSigned
Erfassung von Amazon-EBS-Volume-IDs
Wenn Sie Amazon-EBS-Volume-IDs in den Leistungsprotokollen erfassen möchten, müssen Sie der IAM-Rolle, die den Worker-Knoten oder dem Servicekonto zugeordnet ist, eine weitere Richtlinie hinzufügen. Fügen Sie Folgendes als eingebundenen Richtlinie hinzu. Weitere Informationen finden Sie unter Hinzufügen und Entfernen von IAM-Identitätsberechtigungen.
Erfassung von Java Management Extensions (JMX)-Metriken
Der CloudWatch-Agent unterstützt die Erfassung von Java Management Extensions (JMX)-Metriken auf Amazon EKS. Sie können damit zusätzliche Metriken von Java-Anwendungen erfassen, die auf Amazon-EKS-Clustern ausgeführt werden, und Einblicke in Leistung, Speicherverbrauch, Datenverkehr und andere wichtige Metriken erhalten. Weitere Informationen finden Sie unter Erfassung von Java Management Extensions (JMX)-Metriken.
Aktivieren von Kueue-Metriken
Ab der Version v2.4.0-eksbuild.1 des CloudWatch Observability EKS-Add-ons unterstützt Container Insights für Amazon EKS die Erfassung von Kueue-Metriken aus Amazon-EKS-Clustern. Weitere Informationen zu diesen Metriken finden Sie unter Kueue-Metriken .
Wenn Sie das Amazon SageMaker AI Hyperpod Task Governance EKS-Add-on verwenden, können Sie die Schritte im Abschnitt Voraussetzungen überspringen und einfach den Schritten unter Das Konfigurations-Flag aktivieren folgen.
Voraussetzungen
Bevor Sie Kueue in Ihrem Amazon-EKS-Cluster installieren, nehmen Sie die folgenden Aktualisierungen in der Manifestdatei vor:
-
Aktivieren Sie die optionalen Cluster-Warteschlangenressourcen-Metriken für Kueue. Ändern Sie dazu die Inline-
controller_manager_config.yamlin derkueue-system-ConfigMap. Fügen Sie im Abschnittmetricsdie ZeileenableClusterQueueResources: truehinzu oder entfernen Sie sie.apiVersion: v1 data: controller_manager_config.yaml: | apiVersion: config.kueue.x-k8s.io/v1beta1 kind: Configuration health: healthProbeBindAddress: :8081 metrics: bindAddress: :8080 enableClusterQueueResources: true<-- ADD/UNCOMMENT THIS LINE -
Standardmäßig sind alle
k8s-Services clusterweit verfügbar. Kueue erstellt den Servicekueue-controller-manager-metrics-servicezum Bereitstellen der Metriken. Um doppelte Beobachtungen für Metriken zu vermeiden, ändern Sie diesen Service so, dass nur der Zugriff auf den Metrik-Service von demselben Knoten aus möglich ist. Fügen Sie dazu die ZeileinternalTrafficPolicy: Localzur Definitionkueue-controller-manager-metrics-servicehinzu.apiVersion: v1 kind: Service metadata: labels: ... name: kueue-controller-manager-metrics-service namespace: kueue-system spec: ports: - name: https port: 8443 protocol: TCP targetPort: https internalTrafficPolicy: Local<-- ADD THIS LINEselector: control-plane: controller-manager -
Schließlich erstellt der Pod
kueue-controller-managereinen Containerkube-rbac-proxy. Dieser Container wird derzeit ausführlich protokolliert, was dazu führt, dass das Bearer-Token des Clusters von diesem Container erfasst wird, wenn der Metrik-Scraper aufkueue-controller-manager-metrics-servicezugreift. Es wird empfohlen, die Ausführlichkeit der Protokollierung zu verringern. Der Standardwert im von Kueue verteilten Manifest ist 10. Wir empfehlen, ihn auf 0 zu ändern.apiVersion: apps/v1 kind: Deployment metadata: labels: ... name: kueue-controller-manager namespace: kueue-system spec: ... template: ... spec: containers: ... - args: - --secure-listen-address=0.0.0.0:8443 - --upstream=http://127.0.0.1:8080/ - --logtostderr=true - --v=0<-- CHANGE v=10 TO v=0image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 name: kube-rbac-proxy ...
Das Konfigurations-Flag aktivieren
Um die Kueue-Metriken zu aktivieren, müssen Sie kueue_container_insights im Add-on aktivieren. Sie können dies entweder mit der AWS CLI zur Einrichtung des EKS Observability-Add-ons tun oder mit der Amazon-EKS-Konsole.
Nachdem Sie das EKS Observability-Add-on erfolgreich mit einer der folgenden Methoden installiert haben, können Sie Ihre Amazon-EKS-Cluster-Metriken auf der Registerkarte Dashboard der HyperPod-Konsole anzeigen.
Anhängen von OpenTelemetrie-Kollektor-Konfigurationsdateien
Der CloudWatch-Agent unterstützt neben seinen eigenen Konfigurationsdateien zusätzliche OpenTelemetrie-Kollektor-Konfigurationsdateien. Mit diesem Feature können Sie CloudWatch-Agentenfeatures wie CloudWatch Application Signals oder Container Insights über die CloudWatch-Agentenkonfiguration verwenden und Ihre bestehende OpenTelemetrie-Kollektor-Konfiguration mit einem einzigen Agenten integrieren.
Um Merge-Konflikte mit automatisch vom CloudWatch-Agenten erstellten Pipelines zu vermeiden, empfehlen wir, dass Sie jeder Komponente und Pipelines in Ihrer OpenTelemetrie-Kollektor-Konfiguration ein benutzerdefiniertes Suffix hinzufügen. Dadurch werden Komplikationen und Merge-Konflikte vermieden.
-
Wenn Sie das Amazon CloudWatch Observability EKS-Add-on verwenden
--configuration-values file://values.yamlor
--configuration-values ' agent: otelConfig: receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] ' -
Wenn Sie das Helm-Chart verwenden
--set agent.otelConfig=' receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Konfigurieren von Application Signals für Ihren Amazon-EKS-Cluster
Application Signals ist standardmäßig aktiviert, wenn entweder das CloudWatch Observability EKS-Add-on oder das Helm-Chart installiert wird. Sie können spezifische Einstellungen mithilfe der erweiterten Konfiguration für das Amazon-EKS-Add-on weiter anpassen oder indem Sie Werte mit dem Helm-Chart überschreiben.
Automatische Überwachung für Application Signals
Version 4.0.0 des CloudWatch Observability Amazon EKS-Add-ons und des Helm-Charts bietet neue Funktionen. Sie können Application Signals jetzt automatisch für alle oder bestimmte Service-Workloads in Ihrem EKS-Cluster über die Auto-Monitor-Konfiguration aktivieren. Die folgenden autoMonitor-Einstellungen können im Abschnitt applicationSignals unter dem Abschnitt manager der erweiterten Konfiguration angegeben werden.
-
monitorAllServices: Ein boolesches Flag, um die Überwachung aller Service-Workloads durch Auto Monitor zu aktivieren (true) oder zu deaktivieren (false). Standardwert "false". Durch die Aktivierung dieses Flags wird sichergestellt, dass alle Kubernetes-Workloads (Deployments, DaemonSets und StatefulSets) im Cluster, die einem Kubernetes-Service zugeordnet sind, für die automatische Aktivierung von Application Signals gelten, wenn sie zum ersten Mal aufgerufen werden (oder wenn sie für bestehende Workloads neu gestartet werden). Das System schließt standardmäßig Workloads in den Namespaces
kube-systemundamazon-cloudwatchaus. -
languages: Eine String-Liste, die angibt, mit welchen Sprachen Application Signals versuchen wird, Ihre Services automatisch zu instrumentieren, wenn
monitorAllServicesaktiviert ist. Standardmäßig werden alle unterstützten Sprachen verwendet. -
restartPods: Ein boolesches Flag steuert, ob Workloads nach Konfigurationsänderungen neu gestartet werden. Standardwert "false". Durch die Aktivierung dieses Flags mit
truewird gesteuert, ob Kubernetes-Workloads im Auto-Monitor-Bereich beim Speichern von Konfigurationsänderungen automatisch neu gestartet werden. Alle Einstellungen in Ihren Kubernetes-Workloads, die sich auf den Neustart der Pods auswirken, wieupdateStrategy, werden berücksichtigt. Bedenken Sie, dass ein Neustart zu Serviceausfällen führen kann. -
customSelector: Einstellungen zur Auswahl bestimmter Kubernetes-Namespaces oder Workloads für Auto-Monitor.
-
java: Geben Sie Workloads an, die automatisch mit Java instrumentiert werden sollen
-
python: Geben Sie Workloads an, die automatisch mit Python instrumentiert werden sollen
-
nodejs: Geben Sie Workloads an, die automatisch mit Node.js instrumentiert werden sollen
-
dotnet: Geben Sie Workloads an, die automatisch mit .NET instrumentiert werden sollen
Für jede der oben genannten Sprachen können die folgenden Felder konfiguriert werden.
-
namespaces: Eine String-Liste der Namespaces, die ausgewählt werden können. Standardmäßig ist die Liste leer, also []
-
deployment: Eine String-Liste der Bereitstellungen, die ausgewählt werden können. Im Format
namespace/deploymentangeben. Standardmäßig ist die Liste leer, also [] -
daemonsets: Eine String-Liste der daemonsets, die ausgewählt werden können. Im Format
namespace/daemonsetangeben. Standardmäßig ist die Liste leer, also [] -
statefulsets: Eine String-Liste der statefulsets, die ausgewählt werden können. Im Format
namespace/statefulsetangeben. Standardmäßig ist die Liste leer, also []
-
-
exclude: Einstellungen zum Ausschluss bestimmter Kubernetes-Namespaces oder Workloads von Auto-Monitor. Das Ausschließen eines Workloads hat Vorrang, wenn derselbe Workload auch im Geltungsbereich von
monitorAllServicesodercustomSelectorliegt.-
java: Geben Sie Workloads an, die nicht automatisch mit Java instrumentiert werden sollen
-
python: Geben Sie Workloads an, die nicht automatisch mit Python instrumentiert werden sollen
-
nodejs: Geben Sie Workloads an, die nicht automatisch mit Node.js instrumentiert werden sollen
-
dotnet: Geben Sie Workloads an, die nicht automatisch mit .NET instrumentiert werden sollen
Für jede der oben genannten Sprachen können die folgenden Felder konfiguriert werden.
-
namespaces: Eine String-Liste der Namespaces, die ausgeschlossen werden sollen. Standardmäßig ist die Liste leer, also []
-
deployment: Eine String-Liste der Bereitstellungen, die ausgeschlossen werden sollen. Im Format
namespace/deploymentangeben. Standardmäßig ist die Liste leer, also [] -
daemonsets: Eine String-Liste der daemonsets, die ausgeschlossen werden sollen. Im Format
namespace/daemonsetangeben. Standardmäßig ist die Liste leer, also [] -
statefulsets: Eine String-Liste der statefulsets, die ausgeschlossen werden sollen. Im Format
namespace/statefulsetangeben. Standardmäßig ist die Liste leer, also []
-
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals automatisch für alle vorhandenen und neuen Service-Workloads auf dem Cluster aktiviert.
manager: applicationSignals: autoMonitor: monitorAllServices: true restartPods: true
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals automatisch für jeden neuen Service-Workload aktiviert, der gestartet wird, und für jeden vorhandenen Service-Workload, der explizit auf dem Cluster neu gestartet wird.
manager: applicationSignals: autoMonitor: monitorAllServices: true
Die folgende Beispielkonfiguration aktiviert automatisch Application Signals mit Java für alle vorhandenen und neuen Pods, die einem Workload im Namespace pet-warehouse entsprechen.
manager: applicationSignals: autoMonitor: restartPods: true customSelector: java: namespaces: ["pet-warehouse"]
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals with Python automatisch für alle vorhandenen und neuen Service-Workloads im Cluster mit Ausnahme der Bereitstellung pet-clinic aktiviert.
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["python"] restartPods: true exclude: python: deployments: ["pet-warehouse/pet-clinic"]
Im Folgenden finden Sie eine Beispielkonfiguration, die Application Signals mit Java automatisch für alle Service-Workloads im Cluster mit Ausnahme der Workloads im Namespace python-apps aktiviert und außerdem Application Signals mit Python speziell für die Bereitstellung sample-python-app im Namespace python-apps aktiviert.
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["java"] restartPods: true customSelector: python: deployments: ["python-apps/sample-python-app"] exclude: java: namespaces: ["python-apps"]
Fehlerbehebung mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Chart
Verwenden Sie die folgenden Informationen für die Fehlerbehebung mit dem Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Chart.
Themen
Aktualisieren und Löschen des Amazon CloudWatch Observability EKS-Add-ons oder des Helm-Charts
Anweisungen zum Aktualisieren oder Löschen des Add-Ons von Amazon CloudWatch Observability EKS finden Sie unter Verwalten von Amazon-EKS-Add-Ons. Verwenden Sie als amazon-cloudwatch-observability Name des Add-Ons.
Geben Sie den folgenden Befehl ein, um das Helm-Chart in einem Cluster zu löschen:
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
Verifizieren der Version des CloudWatch-Agenten, die vom Amazon CloudWatch Observability EKS-Add-on oder dem Helm-Chart verwendet wird
Das Amazon CloudWatch Observability EKS-Add-on und das Helm-Chart installieren eine benutzerdefinierte Ressource des Typs AmazonCloudWatchAgent, welche das Verhalten des CloudWatch-Agent-Daemonsets auf dem Cluster steuert, einschließlich der Version des verwendeten CloudWatch-Agenten. Sie können eine Liste aller auf Ihrem Cluster installierten, benutzerdefinierten AmazonCloudWatchAgent-Ressourcen abrufen, indem Sie den folgenden Befehl eingeben:
kubectl get amazoncloudwatchagent -A
In der Ausgabe dieses Befehls sollten Sie in der Lage sein, die Version des CloudWatch-Agenten zu überprüfen. Alternativ können Sie auch die amazoncloudwatchagent-Ressource oder einen der cloudwatch-agent-*-Pods beschreiben, die auf Ihrem Cluster ausgeführt werden, um das verwendete Image zu überprüfen.
Umgehen mit einem ConfigurationConflict bei der Verwaltung des Add-ons oder des Helm-Charts
Wenn Sie bei der Installation oder Aktualisierung des Add-ons von Amazon CloudWatch Observability EKS oder des Helm-Charts einen Fehler feststellen, der durch bestehende Ressourcen verursacht wird, liegt das wahrscheinlich daran, dass Sie den CloudWatch-Agenten und die zugehörigen Komponenten wie ServiceAccount, ClusterRole und ClusterRoleBinding bereits auf dem Cluster installiert haben.
Der vom Add-on angezeigte Fehler beinhaltet: Conflicts found when
trying to apply. Will not continue due to resolve conflicts mode
Der im Helm-Chart angezeigte Fehler wird ähnlich sein wie Error:
INSTALLATION FAILED: Unable to continue with install and invalid ownership
metadata..
Wenn das Add-on oder das Helm-Chart versucht, den CloudWatch-Agenten und die zugehörigen Komponenten zu installieren und eine Änderung des Inhalts feststellt, schlägt die Installation oder Aktualisierung standardmäßig fehl, um zu verhindern, dass der Status der Ressourcen auf dem Cluster überschrieben wird.
Wenn Sie versuchen, das Add-on von Amazon CloudWatch Observability EKS zu integrieren und dieser Fehler auftritt, empfehlen wir, eine vorhandene CloudWatch-Agenten-Einrichtung zu löschen, die Sie möglicherweise zuvor auf dem Cluster installiert haben, und dann das EKS-Add-On bzw. das Helm-Chart zu installieren. Stellen Sie sicher, dass Sie alle Anpassungen, die Sie möglicherweise an der ursprünglichen CloudWatch-Agenten-Einrichtung vorgenommen haben, wie z. B. eine benutzerdefinierte Agentenkonfiguration, sichern und diese dem Add-on oder dem Helm-Chart zur Verfügung stellen, wenn Sie es das nächste Mal installieren oder aktualisieren. Wenn Sie zuvor den CloudWatch-Agenten für das Onboarding in Container Insights installiert haben, finden Sie weitere Informationen unter Löschen des CloudWatch-Agenten und Fluent Bid für Container Insights.
Alternativ unterstützt das Add-On eine Konfigurationsoption zur Konfliktlösung, die OVERWRITE spezifizieren kann. Sie können diese Option verwenden, um mit der Installation oder Aktualisierung des Add-Ons fortzufahren, indem Sie die Konflikte auf dem Cluster überschreiben. Wenn Sie die Amazon-EKS-Konsole verwenden, finden Sie die Methode zur Konfliktlösung, wenn Sie beim Erstellen oder Aktualisieren des Add-Ons die optionalen Konfigurationseinstellungen auswählen. Wenn Sie die AWS CLI verwenden, können Sie --resolve-conflicts OVERWRITE an Ihren Befehl übergeben, um das Add-On zu erstellen oder zu aktualisieren.