Installieren Sie den CloudWatch Agenten mit dem Amazon CloudWatch EKS Observability-Add-on oder dem Helm-Diagramm - Amazon CloudWatch
Option 1: Installation mit IAM Berechtigungen auf Worker-Knoten Option 2: Installation mithilfe der IAM Dienstkonto-Rolle (gilt nur für die Verwendung des Add-ons)(Optional) Zusätzliche KonfigurationFehlerbehebung

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.

Installieren Sie den CloudWatch Agenten mit dem Amazon CloudWatch EKS Observability-Add-on oder dem Helm-Diagramm

Sie können entweder das Amazon CloudWatch EKS Observability-Add-on oder das Amazon CloudWatch Observability Helm-Diagramm verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem Amazon-Cluster zu installieren. EKS Sie können das Helm-Diagramm auch verwenden, um den CloudWatch Agenten und den Fluent-Bit-Agenten auf einem Kubernetes-Cluster zu installieren, der nicht bei Amazon gehostet wird. EKS

Die Verwendung einer der beiden Methoden in einem EKS Amazon-Cluster ermöglicht standardmäßig sowohl Container Insights mit verbesserter Observability für Amazon EKS als auch CloudWatch Application Signals. Beide Funktionen helfen Ihnen bei der Erfassung von Infrastrukturmetriken, Telemetrie zur Anwendungsleistung und Container-Logs aus dem Cluster.

Bei Container Insights mit verbesserter Observability für Amazon werden Container Insights-Metriken pro Beobachtung berechnetEKS, 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 Service Level Objective (). SLO Jede eingehende Anfrage generiert ein Anwendungssignal, und jede ausgehende Anfrage generiert ein Anwendungssignal. Jedes SLO erzeugt zwei Anwendungssignale pro Messzeitraum. Weitere Informationen zur CloudWatch Preisgestaltung finden Sie unter CloudWatch Amazon-Preise.

Beide Methoden ermöglichen Container Insights sowohl auf Linux- als auch auf Windows-Worker-Knoten im EKS Amazon-Cluster. Um Container Insights unter Windows zu aktivieren, müssen Sie Version 1.5.0 oder höher des EKS Amazon-Add-ons oder das Helm-Diagramm verwenden. Derzeit wird Application Signals unter Windows in EKS Amazon-Clustern nicht unterstützt.

Das Amazon CloudWatch EKS Observability-Add-on wird auf EKS Amazon-Clustern unterstützt, die mit Kubernetes Version 1.23 oder höher ausgeführt werden.

Wenn Sie das Add-on oder das Helm-Diagramm installieren, müssen Sie dem CloudWatch Agenten auch IAM Berechtigungen erteilen, damit er Metriken, Logs und Traces senden kann. CloudWatch Es gibt zwei Möglichkeiten dafür:

  • Fügen Sie der IAM Rolle Ihrer Worker Nodes eine Richtlinie hinzu. Diese Option gewährt Worker-Knoten die Erlaubnis, Telemetrie an sie zu CloudWatch senden.

  • Verwenden Sie eine IAM Rolle für Dienstkonten für die Agenten-Pods und fügen Sie die Richtlinie dieser Rolle hinzu. Dies funktioniert nur für EKS Amazon-Cluster. Diese Option gewährt nur CloudWatch Zugriff auf die entsprechenden Agenten-Pods.

Option 1: Installation mit IAM Berechtigungen auf Worker-Knoten

Um diese Methode zu verwenden, fügen Sie zunächst die CloudWatchAgentServerPolicyIAMRichtlinie Ihren Worker-Knoten hinzu, 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-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Installieren Sie anschließend das Amazon CloudWatch EKS Observability-Add-on. Um das Add-on zu installieren, können Sie die AWS CLI, die Konsole oder AWS CloudFormation Terraform verwenden.

AWS CLI
AWS CLI Um das Amazon CloudWatch EKS Observability-Add-on zu installieren

Geben Sie den folgenden Befehl ein. Ersetzen Sie my-cluster-name mit dem Namen Ihres Clusters.

aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
Amazon EKS console
So verwenden Sie die EKS Amazon-Konsole, um das Amazon CloudWatch EKS Observability-Add-on hinzuzufügen

  1. Öffnen Sie die EKS Amazon-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

  2. Wählen Sie im linken Navigationsbereich die Option Cluster aus.

  3. Wählen Sie den Namen des Clusters, für den Sie das Amazon CloudWatch EKS Observability-Add-on konfigurieren möchten.

  4. Wählen Sie die Registerkarte Add-ons.

  5. Wählen Sie Weitere Add-Ons erhalten.

  6. Führen Sie auf der Seite Add-Ons auswählen die folgenden Schritte aus:

    1. Aktivieren Sie im Bereich Amazon EKS -Addons das Kontrollkästchen Amazon CloudWatch Observability.

    2. Wählen Sie Weiter.

  7. Gehen Sie auf der Seite Konfigurieren ausgewählter Add-Ons-Einstellungen wie folgt vor:

    1. Wählen Sie die Version aus, die Sie verwenden möchten.

    2. Wählen Sie für IAM Rolle auswählen die Option Von Knoten erben

    3. (Optional) Sie können Optionale Konfigurationseinstellungen erweitern. Wenn Sie Override für die Konfliktlösungsmethode auswählen, können eine oder mehrere Einstellungen für das bestehende Add-on mit den EKS Amazon-Add-On-Einstellungen überschrieben werden. Wenn Sie diese Option nicht aktivieren und ein Konflikt mit Ihren vorhandenen Einstellungen vorliegt, schlägt der Vorgang fehl. Sie können die sich daraus ergebende Fehlermeldung heranziehen, um den Konflikt zu beheben. Bevor Sie diese Option auswählen, stellen Sie sicher, dass das EKS Amazon-Add-on keine Einstellungen verwaltet, die Sie selbst verwalten müssen.

    4. Wählen Sie Weiter.

  8. Wählen Sie auf der Seite Überprüfen und hinzufügen die Option Erstellen aus. Nachdem die Installation der Add-Ons abgeschlossen ist, wird Ihr installiertes Add-On angezeigt.

AWS CloudFormation
AWS CloudFormation Zur Installation des Amazon CloudWatch EKS Observability-Zusatzmoduls

Ersetzen Sie my-cluster-name mit dem Namen Ihres Clusters. Weitere Informationen finden Sie unter AWS::EKS::Addon.

{
    "Resources": {
        "EKSAddOn": {
            "Type": "AWS::EKS::Addon",
            "Properties": {
                "AddonName": "amazon-cloudwatch-observability",
                "ClusterName": "my-cluster-name"
            }
        }
    }
}
Helm chart
Um das amazon-cloudwatch-observability Helm-Diagramm zu verwenden

  1. Sie müssen Helm installiert haben, um dieses Diagramm verwenden zu können. Weitere Informationen zur Installation von Helm finden Sie in der Helm-Dokumentation.

  2. Nachdem Sie Helm installiert haben, geben Sie die folgenden Befehle ein. Ersetzen my-cluster-name mit dem Namen Ihres Clusters und ersetzen my-cluster-region mit der Region, in der der Cluster läuft.

    helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region
Terraform
Um Terraform zur Installation des Amazon CloudWatch Observability-Add-ons zu verwenden EKS

Ersetzen Sie my-cluster-name mit dem Namen Ihres Clusters. Weitere Informationen finden Sie unter Resource: aws_eks_addon.

resource "aws_eks_addon" "example" {
  addon_name   = "amazon-cloudwatch-observability"
  cluster_name = "my-cluster-name"
}

Option 2: Installation mithilfe der IAM Dienstkonto-Rolle (gilt nur für die Verwendung des Add-ons)

Diese Methode ist nur gültig, wenn Sie das Amazon CloudWatch EKS Observability-Add-on verwenden. Vor dem Verwenden dieser Methode, überprüfen Sie die folgenden Voraussetzungen:

  • Sie haben einen funktionierenden EKS Amazon-Cluster mit Knoten, die an einen angehängt sind AWS-Regionen , der Container Insights unterstützt. Eine Liste der unterstützten Regionen finden Sie unter Container Insights.

  • Sie haben kubectl für den Cluster installiert und konfiguriert. Weitere Informationen finden Sie unter Installation kubectl im EKSAmazon-Benutzerhandbuch.

  • Sie haben eksctl installiert. Weitere Informationen finden Sie unter Installation oder Aktualisierung eksctl im EKSAmazon-Benutzerhandbuch.

So installieren Sie das Amazon CloudWatch EKS Observability-Add-on mithilfe der IAM Dienstkonto-Rolle

  1. Geben Sie den folgenden Befehl ein, um einen OpenID Connect (OIDC) -Anbieter zu erstellen, falls der Cluster noch keinen hat. Weitere Informationen finden Sie unter Konfiguration eines Kubernetes-Servicekontos für die Übernahme einer IAM Rolle im EKSAmazon-Benutzerhandbuch.

    eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve

  2. Geben Sie den folgenden Befehl ein, um die IAM Rolle mit der angehängten CloudWatchAgentServerPolicyRichtlinie zu erstellen, und konfigurieren Sie das Agent-Servicekonto so, dass es diese Rolle übernimmt. OIDC Ersetzen my-cluster-name mit dem Namen Ihres Clusters und ersetzen Sie my-service-account-role mit dem Namen der Rolle, der Sie das Dienstkonto zuordnen möchten. Wenn diese Rolle noch nicht vorhanden ist, erstellt eksctl sie für Sie. 

    eksctl create iamserviceaccount \
  --name cloudwatch-agent \
  --namespace amazon-cloudwatch --cluster my-cluster-name \
  --role-name my-service-account-role \
  --attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
  --role-only \
  --approve

  3. Installieren Sie das Add-On indem Sie den folgenden Befehl eingeben. Ersetzen my-cluster-name durch den Namen Ihres Clusters ersetzen 111122223333 durch Ihre Konto-ID und ersetzen my-service-account-role mit der IAM Rolle, die im vorherigen Schritt erstellt wurde.

    aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role

(Optional) Zusätzliche Konfiguration

Deaktivieren Sie das Sammeln von Container-Protokollen

Standardmäßig verwendet das Add-on Fluent Bit, um Container-Logs von allen Pods zu sammeln und sendet die Logs 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-Diagramm 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-Diagramm installieren. Um Ihr bestehendes Setup beizubehalten und zu verhindern, dass das Add-on oder das Helm-Diagramm Fluent Bit ebenfalls installieren, können Sie Fluent Bit alternativ deaktivieren, indem Sie den Anweisungen in diesem Abschnitt folgen.

Um die Erfassung von Container-Logs zu deaktivieren, wenn Sie das Amazon CloudWatch EKS Observability-Add-on verwenden, geben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option an:

--configuration-values '{ "containerLogs": { "enabled": false } }'

Um die Erfassung von Container-Logs zu deaktivieren, wenn Sie das Helm-Diagramm verwenden, geben Sie bei der Erstellung oder Aktualisierung des Add-ons die folgende Option an:

--set containerLogs.enabled=false

Verwenden Sie eine benutzerdefinierte Fluent Bit-Konfiguration

Ab Version 1.7.0 des Amazon CloudWatch EKS Observability-Add-ons können Sie die Fluent Bit-Konfiguration ändern, wenn Sie das Add-on oder das Helm-Diagramm 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-Diagramm an. In diesem Abschnitt geben Sie die benutzerdefinierte Fluent-Bit-Konfiguration im config Abschnitt (für Linux) oder configWindows Abschnitt (für Windows) an. Der config ist weiter in die folgenden Unterabschnitte unterteilt:

  • service— Dieser Abschnitt stellt die SERVICE Konfiguration zur Definition des globalen Verhaltens der Fluent Bit-Engine dar.

  • customParsers— Dieser Abschnitt stellt alle globalen PARSER s dar, 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 conf Fluent-Bit-Dateien hinzuzufügen. Standardmäßig sind die folgenden 3 conf Dateien enthalten:.

    • application-log.conf— Eine conf Datei zum Senden von Anwendungsprotokollen von Ihrem Cluster an die Protokollgruppe /aws/containerinsights/my-cluster-name/application in CloudWatch Logs.

    • dataplane-log.conf— Eine conf Datei zum Senden von Protokollen, die den Datenebenenkomponenten Ihres Clusters entsprechen, einschließlich der CRI Protokolle, Kubelet-Logs, Kube-Proxy-Logs und Amazon-Logs, an die Protokollgruppe in VPC CNI Logs. /aws/containerinsights/my-cluster-name/dataplane CloudWatch

    • host-log.conf— A conf zum Senden von Protokollen von /var/log/dmesg/var/log/messages, und /var/log/secure unter Linux und System unter Windows winlogs an die Protokollgruppe in. /aws/containerinsights/my-cluster-name/host CloudWatch

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 entsprechend 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 EKS Amazon-Add-on ändern oder wenn Sie Wertüberschreibungen für das Helm-Diagramm angeben.

Den config Abschnitt für Ihren Cluster finden Sie unter aws-observability /helm-charts. Dort finden Sie die Version, die der Version des Add-ons oder Helm-Charts entspricht, die Sie installieren. GitHub Navigieren Sie dann /charts/amazon-cloudwatch-observability/values.yaml zu dem config Abschnitt (für Linux) und dem configWindows Abschnitt (für Windows) im Abschnitt unten. fluentBit containerLogs

Als Beispiel finden Sie hier die Standard-Fluent Bit-Konfiguration für Version 1.7.0.

Wir empfehlen, dass Sie das config AS angeben, YAML wenn Sie es mit der erweiterten Konfiguration des EKS Amazon-Add-ons angeben, oder wenn Sie es als Wertüberschreibungen für Ihre Helm-Installation angeben. Stellen Sie sicher, dass das der folgenden Struktur YAML entspricht.

containerLogs:
  fluentBit:
    config:
      service: |
        ...
      customParsers: |
        ...
      extraFiles:
        application-log.conf: |
          ...
        dataplane-log.conf: |
          ...
        host-log.conf: |
          ...

Im folgenden Beispiel wird die globale Einstellung für das Spülintervall auf 45 Sekunden config geändert. Auch wenn die einzige Änderung das Flush Feld 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-Datei. conf In diesem Beispiel fügen wir ein benutzerdefiniertes my-service.conf Unterverzeichnis extraFiles hinzu, das zusätzlich zu den drei extraFiles Standardwerten hinzugefügt wird.

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 entferntextraFiles. Dadurch wird die application-log.conf vollständig ausgeschlossen, indem sie mit einer leeren Zeichenfolge überschrieben wird. Das einfache Weglassen application-log.conf von extraFiles würde stattdessen bedeuten, die Standardeinstellung zu verwenden, was wir in diesem Beispiel nicht erreichen wollen. Das Gleiche gilt für das Entfernen von benutzerdefinierten conf Dateien, zu denen Sie möglicherweise zuvor etwas hinzugefügt haben. extraFiles

containerLogs:
  fluentBit:
    config:
      extraFiles:
        application-log.conf: ""

Verwalten Sie die Kubernetes-Toleranzen für die installierten Pod-Workloads

Ab Version 1.7.0 des Amazon CloudWatch Observability-Add-ons legen das EKS Add-on und das Helm-Diagramm standardmäßig Kubernetes-Toleranzen fest, um alle Fehler in den Pod-Workloads zu tolerieren, die durch das Add-on oder das Helm-Diagramm 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 Toleranzen und Taints finden Sie unter Taints and Tolerations in der Kubernetes-Dokumentation.

Die vom Add-on oder dem Helm-Diagramm festgelegten Standardtoleranzen lauten wie folgt:

tolerations:
- operator: Exists

Sie können die Standardtoleranzen überschreiben, indem Sie das tolerations Feld auf der Stammebene festlegen, wenn Sie die erweiterte Konfiguration des Add-ons verwenden oder wenn Sie das Helm-Diagramm mit Wertüberschreibungen installieren oder aktualisieren. Ein Beispiel würde wie folgt aussehen:

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

Um Toleranzen komplett wegzulassen, können Sie eine Konfiguration verwenden, die wie folgt aussieht:

tolerations: []

Alle Änderungen an den Toleranzen gelten für alle Pod-Workloads, die durch das Add-on oder das Helm-Diagramm installiert werden.

Deaktivieren Sie die beschleunigte Erfassung von Rechenmetriken

Standardmäßig erfasst Container Insights mit verbesserter Observability 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 () -Metriken. EFA

NVIDIAGPUMetriken aus EKS Amazon-Workloads werden standardmäßig erfasst, beginnend mit v1.3.0-eksbuild.1 der Version des EKS Add-ons oder des Helm-Diagramms und 1.300034.0 der Version des CloudWatch Agenten. Eine Liste der gesammelten Metriken und der Voraussetzungen finden Sie unterNVIDIAGPUMetriken.

AWS Neuronenmetriken für AWS Trainium- und AWS Inferentia-Beschleuniger werden standardmäßig erfasst, beginnend mit v1.5.0-eksbuild.1 der Version des EKS Add-ons oder des Helm-Diagramms und der Version des Agenten. 1.300036.0 CloudWatch Eine Liste der gesammelten Metriken und der Voraussetzungen finden Sie unter. AWS Neuronenmetriken für AWS Trainium und Inferentia AWS

AWS Elastic Fabric Adapter (EFA) -Metriken von Linux-Knoten auf EKS Amazon-Clustern werden standardmäßig erfasst, beginnend mit v1.5.2-eksbuild.1 der Version des EKS Add-ons oder des Helm-Diagramms und 1.300037.0 der Version des CloudWatch Agenten. Eine Liste der gesammelten Metriken und der Voraussetzungen finden Sie unterAWS Metriken für Elastic Fabric Adapter () EFA .

Sie können die Erfassung dieser Metriken deaktivieren, indem Sie das accelerated_compute_metrics Feld in der CloudWatch Agentenkonfigurationsdatei auf setzenfalse. Dieses Feld befindet sich im kubernetes Abschnitt des metrics_collected Abschnitts in der CloudWatch Konfigurationsdatei. Im Folgenden finden Sie ein Beispiel für eine Opt-Out-Konfiguration. Weitere Informationen zur Verwendung benutzerdefinierter CloudWatch Agentenkonfigurationen finden Sie im folgenden Abschnitt,Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration.

{
  "logs": {
    "metrics_collected": {
      "kubernetes": {
        "enhanced_container_insights": true,
        "accelerated_compute_metrics": false
      }
    }
  }
}

Verwenden Sie eine benutzerdefinierte CloudWatch Agentenkonfiguration

Um andere Metriken, Logs oder Traces mithilfe des 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 Agentenkonfigurationsdatei in den Konfigurationsschlüssel unter dem Agentenschlüssel der erweiterten Konfiguration ein, den Sie bei der Erstellung oder Aktualisierung des EKS Add-ons oder des Helm-Diagramms 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.

  • Für die 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": {}
        }
      }
    }
  
}'

  • Für die Verwendung des Helm-Diagramms

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

TLSWebhook-Zertifikate für die Zulassung verwalten

Das Amazon CloudWatch EKS Observability-Add-on und das Helm-Diagramm nutzen Kubernetes-Zulassungswebhooks zur Validierung und Mutation sowie Instrumentation benutzerdefinierte Ressourcenanfragen (CR) AmazonCloudWatchAgent und optional Kubernetes-Pod-Anfragen auf dem Cluster, wenn Application Signals aktiviert ist. CloudWatch In Kubernetes benötigen Webhooks ein TLS Zertifikat, dem der API Server so konfiguriert ist, dass es vertraut, um eine sichere Kommunikation zu gewährleisten.

Standardmäßig generieren das Amazon CloudWatch EKS Observability-Add-on und das Helm-Diagramm 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-Bundle und das Zertifikat jedes Mal neu generiert, wenn das Add-on oder das Helm-Diagramm 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 expiry-in-days mit Ihrer gewünschten Ablaufdauer in Tagen.

  • Verwenden Sie dies für das Amazon CloudWatch Observability-Add-on EKS

    --configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'

  • Verwenden Sie dies für das Helm-Diagramm

    --set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days

Für eine sicherere und funktionsreichere Zertifizierungsstellenlösung bietet das Add-on optionale Unterstützung für Cert-Manager, eine weit verbreitete Lösung für die TLS Zertifikatsverwaltung in Kubernetes, die den Prozess der Beschaffung, Erneuerung, Verwaltung und Verwendung dieser Zertifikate vereinfacht. Dies stellt sicher, dass Zertifikate gültig und aktuell sind, und versucht, Zertifikate zu einem konfigurierten Zeitpunkt vor Ablauf zu erneuern. cert-manager erleichtert auch die Ausstellung von Zertifikaten aus einer Vielzahl unterstützter Quellen, einschließlich AWS Certificate Manager Private Certificate Authority.

Wir empfehlen Ihnen, sich mit den bewährten Methoden für die Verwaltung von TLS Zertifikaten in 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, Cert-Manager für die Verwaltung der TLS Zulassungs-Webhook-Zertifikate zu aktivieren, cert-manager auf Ihrem EKS Amazon-Cluster vorinstallieren müssen, bevor Sie das Amazon Observability-Add-on oder das Helm-Diagramm installieren. CloudWatch EKS Weitere Informationen zu den verfügbaren Installationsoptionen finden Sie in der cert-manager-Dokumentation. Nach der Installation können Sie sich dafür entscheiden, cert-manager für die Verwaltung der TLS Webhook-Zugangszertifikate zu verwenden, indem Sie die folgende zusätzliche Konfiguration verwenden.

  • Wenn Sie das Amazon CloudWatch EKS Observability-Add-on verwenden

    --configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'

  • Wenn Sie das Helm-Diagramm verwenden

    --set admissionWebhooks.certManager.enabled=true
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'

Die in diesem Abschnitt beschriebene erweiterte Konfiguration verwendet standardmäßig einen SelfSignedEmittenten.

EBSAmazon-Volumen sammeln IDs

Wenn Sie das EBS Amazon-Volumen 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 IAMIdentitätsberechtigungen hinzufügen und entfernen.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeVolumes"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Fehlerbehebung beim Amazon CloudWatch EKS Observability-Add-on oder dem Helm-Diagramm

Verwenden Sie die folgenden Informationen, um Probleme mit dem Amazon CloudWatch EKS Observability-Add-on oder dem Helm-Diagramm zu beheben

Aktualisieren und Löschen des Amazon CloudWatch EKS Observability-Add-ons oder des Helm-Diagramms

Anweisungen zum Aktualisieren oder Löschen des Amazon CloudWatch EKS Observability-Add-ons finden Sie unter EKSAmazon-Add-ons verwalten. Verwenden Sie als amazon-cloudwatch-observability Name des Add-Ons.

Um das Helm-Diagramm in einem Cluster zu löschen, geben Sie den folgenden Befehl ein.

helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait

Überprüfen Sie die Version des CloudWatch Agenten, der vom Amazon CloudWatch EKS Observability-Add-on oder dem Helm-Diagramm verwendet wird

Das Amazon CloudWatch EKS Observability-Add-on und das Helm-Diagramm installieren eine benutzerdefinierte RessourceAmazonCloudWatchAgent, die das Verhalten des CloudWatch Agenten-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 die Version des Agenten überprüfen können. CloudWatch 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.

Umgang mit a ConfigurationConflict bei der Verwaltung des Add-ons oder des Helm-Charts

Wenn Sie bei der Installation oder Aktualisierung des Amazon CloudWatch EKS Observability-Add-ons oder des Helm-Diagramms einen Fehler feststellen, der durch vorhandene Ressourcen verursacht wird, liegt dies wahrscheinlich daran, dass Sie den CloudWatch Agenten und die zugehörigen Komponenten wie den ServiceAccount, den ClusterRole und den bereits auf dem Cluster ClusterRoleBinding 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-Diagramm angezeigte Fehler wird ähnlich sein wieError: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata..

Wenn das Add-on oder das Helm-Diagramm versucht, den CloudWatch Agenten und die zugehörigen Komponenten zu installieren und dabei eine Änderung des Inhalts feststellt, schlägt die Installation oder Aktualisierung standardmäßig fehl, um zu verhindern, dass der Status der Ressourcen im Cluster überschrieben wird.

Wenn Sie versuchen, das Amazon CloudWatch EKS Observability-Add-on zu integrieren und dieser Fehler auftritt, empfehlen wir, ein vorhandenes CloudWatch Agenten-Setup zu löschen, das Sie zuvor auf dem Cluster installiert hatten, und dann das EKS Add-on oder das Helm-Diagramm zu installieren. Stellen Sie sicher, dass Sie alle Anpassungen, die Sie möglicherweise am ursprünglichen CloudWatch Agenten-Setup vorgenommen haben, wie z. B. eine benutzerdefinierte Agentenkonfiguration, sichern und diese bei der nächsten Installation oder Aktualisierung in das Add-on oder das Helm-Diagramm übernehmen. Wenn Sie den CloudWatch Agenten für das Onboarding in Container Insights bereits installiert hatten, finden Sie Der CloudWatch Agent und Fluent Bit für Container Insights werden gelöscht weitere Informationen unter.

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 EKS Amazon-Konsole verwenden, finden Sie die Konfliktlösungsmethode, wenn Sie beim Erstellen oder Aktualisieren des Add-ons die optionalen Konfigurationseinstellungen auswählen. Wenn Sie die verwenden AWS CLI, können Sie die --resolve-conflicts OVERWRITE an Ihren Befehl übergeben, um das Add-on zu erstellen oder zu aktualisieren.