

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.

# Protokollierung für Amazon EKS
<a name="kubernetes-eks-logging"></a>

Die Kubernetes-Protokollierung kann in die Protokollierung der Kontrollebene, die Protokollierung von Knoten und die Protokollierung von Anwendungen unterteilt werden. Die [Kubernetes-Steuerebene](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) besteht aus einer Reihe von Komponenten, die Kubernetes-Cluster verwalten und Protokolle erstellen, die für Prüf- und Diagnosezwecke verwendet werden. Mit Amazon EKS können Sie [Protokolle für verschiedene Komponenten der Steuerungsebene aktivieren](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html) und an diese senden CloudWatch. 

Kubernetes führt auch Systemkomponenten wie `kubelet` und `kube-proxy` auf jedem Kubernetes-Knoten aus, auf dem Ihre Pods ausgeführt werden. Diese Komponenten schreiben Protokolle innerhalb jedes Knotens, und Sie können Container Insights so konfigurieren CloudWatch , dass diese Protokolle für jeden Amazon EKS-Knoten erfasst werden. 

Container sind als [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) innerhalb eines Kubernetes-Clusters gruppiert und für die Ausführung auf Ihren Kubernetes-Knoten geplant. Die meisten containerisierten Anwendungen schreiben auf Standardausgabe und Standardfehler, und die Container-Engine leitet die Ausgabe an einen Protokollierungstreiber weiter. In Kubernetes befinden sich die Container-Logs im `/var/log/pods` Verzeichnis auf einem Knoten. Sie können Container Insights so konfigurieren CloudWatch , dass diese Protokolle für jeden Ihrer Amazon EKS-Pods erfasst werden. 

## Amazon-EKS-Steuerebenen-Protokollierung
<a name="eks-control-plane-logging"></a>

Ein Amazon EKS-Cluster besteht aus einer hochverfügbaren Single-Tenant-Steuerebene für Ihren Kubernetes-Cluster und die Amazon EKS-Knoten, auf denen Ihre Container ausgeführt werden. Die Knoten der Kontrollebene werden in einem Konto ausgeführt, das von verwaltet wird. AWS Die Knoten der Amazon EKS-Cluster-Steuerebene sind integriert CloudWatch und Sie können die Protokollierung für bestimmte Komponenten der Steuerungsebene aktivieren.

Für jede Instanz der Kubernetes-Steuerebenenkomponente werden Protokolle bereitgestellt. AWS verwaltet den Zustand Ihrer Knoten auf der Kontrollebene und bietet ein [Service Level Agreement (SLA) für](https://aws.amazon.com//eks/sla/) den Kubernetes-Endpunkt.

## Amazon EKS Knoten- und Anwendungsprotokollierung
<a name="eks-node-application-logging"></a>

Wir empfehlen, [CloudWatchContainer Insights](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html) zur Erfassung von Protokollen und Metriken für Amazon EKS zu verwenden. Container Insights implementiert Metriken auf Cluster-, Knoten- und Pod-Ebene mit dem CloudWatch Agenten und Fluent Bit oder Fluentd für die Protokollerfassung. CloudWatch Container Insights bietet auch automatische Dashboards mit mehrschichtigen Ansichten Ihrer erfassten Metriken. CloudWatch Container Insights wird als CloudWatch DaemonSet Fluent Bit bereitgestellt DaemonSet , das auf jedem Amazon EKS-Knoten ausgeführt wird. Fargate-Knoten werden von Container Insights nicht unterstützt, da die Knoten von verwaltet werden AWS und dies nicht tun. DaemonSets Die Fargate-Protokollierung für Amazon EKS wird in diesem Handbuch separat behandelt. 

 Die folgende Tabelle zeigt die CloudWatch Protokollgruppen und Protokolle, die mit der [standardmäßigen Fluentd- oder Fluent Bit-Protokollerfassungskonfiguration](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html) für Amazon EKS erfasst wurden.


|  |  | 
| --- |--- |
| /aws/containerinsights/Cluster\$1Name/application | Alle Protokolldateien in. /var/log/containers Dieses Verzeichnis enthält symbolische Links zu allen Kubernetes-Container-Logs in der /var/log/pods Verzeichnisstruktur. Dadurch werden Ihre Anwendungscontainer-Logs erfasst, die in oder schreiben. stdout stderr Es umfasst auch Protokolle für Kubernetes-Systemcontainer wie aws-vpc-cni-initkube-proxy, und. coreDNS  | 
| /aws/containerinsights/Cluster\$1Name/host | Protokolle von /var/log/dmesg/var/log/secure, und. /var/log/messages | 
| /aws/containerinsights/Cluster\$1Name/dataplane | Die Protokolle in /var/log/journal für kubelet.service, kubeproxy.service und docker.service. | 

Wenn Sie Container Insights nicht mit Fluent Bit oder Fluentd für die Protokollierung verwenden möchten, können Sie Knoten- und Container-Protokolle mit dem auf Amazon EKS-Knoten installierten CloudWatch Agenten erfassen. Amazon EKS-Knoten sind EC2-Instances, was bedeutet, dass Sie sie in Ihren Standardansatz für die Protokollierung auf Systemebene für Amazon EC2 einbeziehen sollten. Wenn Sie den CloudWatch Agenten mithilfe von Distributor und State Manager installieren, sind Amazon EKS-Knoten auch in der Installation, Konfiguration und Aktualisierung des CloudWatch Agenten enthalten. 

Die folgende Tabelle zeigt Protokolle, die spezifisch für Kubernetes sind und die Sie erfassen müssen, wenn Sie Container Insights with Fluent Bit oder Fluentd nicht für die Protokollierung verwenden.


|  |  | 
| --- |--- |
| /var/log/containers | Dieses Verzeichnis enthält symbolische Links zu allen Kubernetes-Container-Logs unter der Verzeichnisstruktur. /var/log/pods Dadurch werden Ihre Anwendungscontainer-Logs effektiv erfasst, die in oder schreiben. stdout stderr Dazu gehören Protokolle für Kubernetes-Systemcontainer wie aws-vpc-cni-initkube-proxy, und. coreDNS Wichtig: Dies ist nicht erforderlich, wenn Sie Container Insights verwenden. | 
| var/log/aws-routed-eni/ipamd.log/var/log/aws-routed-eni/plugin.log | Die Logs für den L-IPAM-Daemon finden Sie hier | 

Sie müssen sicherstellen, dass Amazon EKS-Knoten den CloudWatch Agenten so installieren und konfigurieren, dass er entsprechende Protokolle und Metriken auf Systemebene sendet. Das für Amazon EKS optimierte AMI beinhaltet jedoch nicht den Systems Manager Manager-Agenten. Mithilfe von [Startvorlagen](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) können Sie die Installation des Systems Manager Manager-Agenten und eine CloudWatch Standardkonfiguration automatisieren, die wichtige Amazon EKS-spezifische Protokolle mit einem Startskript erfasst, das über den Benutzerdatenbereich implementiert wird. Amazon EKS-Knoten werden mithilfe einer Auto Scaling Scaling-Gruppe entweder als [verwaltete Knotengruppe](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-groups.html) oder als [selbstverwaltete Knoten](https://docs.aws.amazon.com//eks/latest/userguide/worker.html) bereitgestellt.

Bei verwalteten Knotengruppen stellen Sie eine [Startvorlage](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) bereit, die den Abschnitt mit den Benutzerdaten enthält, um die Installation und CloudWatch Konfiguration des Systems Manager Manager-Agenten zu automatisieren. Sie können die Vorlage [amazon\$1eks\$1managed\$1node\$1group\$1launch\$1config.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon_eks_managed_node_group_launch_config.yaml) anpassen und verwenden, um eine CloudFormation Startvorlage zu erstellen, die den Systems Manager Manager-Agenten und -Agenten installiert und dem Konfigurationsverzeichnis auch eine Amazon EKS-spezifische Protokollierungskonfiguration hinzufügt. CloudWatch CloudWatch Diese Vorlage kann verwendet werden, um Ihre Startvorlage für Amazon EKS-verwaltete Knotengruppen mit einem infrastructure-as-code (IaC) -Ansatz zu aktualisieren. Jede Aktualisierung der CloudFormation Vorlage stellt eine neue Version der Startvorlage bereit. Anschließend können Sie die Knotengruppe so aktualisieren, dass sie die neue Vorlagenversion verwendet, und Ihre Knoten im Rahmen des [verwalteten Lebenszyklusprozesses](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-update-behavior.html) ohne Ausfallzeiten aktualisieren lassen. Stellen Sie sicher, dass die auf Ihre verwaltete Knotengruppe angewendete IAM-Rolle `CloudWatchAgentServerPolicy` und das Instanzprofil die `AmazonSSMManagedInstanceCore` AWS verwalteten Richtlinien enthalten. 

Mit selbstverwalteten Knoten können Sie den Lebenszyklus und die Aktualisierungsstrategie für Ihre Amazon EKS-Knoten direkt bereitstellen und verwalten. [Selbstverwaltete Knoten ermöglichen es Ihnen, Windows-Knoten auf Ihrem Amazon EKS-Cluster und [Bottlerocket](https://aws.amazon.com//bottlerocket/) zusammen mit anderen Optionen auszuführen.](https://docs.aws.amazon.com//eks/latest/userguide/eks-compute.html) Sie können CloudFormation damit selbstverwaltete Knoten in Ihren Amazon EKS-Clustern bereitstellen, was bedeutet, dass Sie einen IaC- und Managed-Change-Ansatz für Ihre Amazon EKS-Cluster verwenden können. AWS stellt die CloudFormation Vorlage „[amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml)“ bereit, die Sie unverändert verwenden oder anpassen können. Die Vorlage stellt alle erforderlichen Ressourcen für Amazon EKS-Knoten in einem Cluster bereit (z. B. eine separate IAM-Rolle, Sicherheitsgruppe, Amazon EC2 Auto Scaling Scaling-Gruppe und eine Startvorlage). Bei der CloudFormation Vorlage [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) handelt es sich um eine aktualisierte Version, die den erforderlichen Systems Manager Manager-Agenten und CloudWatch -Agenten installiert und dem Konfigurationsverzeichnis außerdem eine Amazon EKS-spezifische CloudWatch Protokollierungskonfiguration hinzufügt.

## Protokollierung für Amazon EKS auf Fargate
<a name="eks-fargate-logging"></a>

Mit Amazon EKS on Fargate können Sie Pods bereitstellen, ohne Ihre Kubernetes-Knoten zuzuweisen oder zu verwalten. Dadurch entfällt die Notwendigkeit, Protokolle auf Systemebene für Ihre Kubernetes-Knoten zu erfassen. Um die Protokolle von Ihren Fargate-Pods zu erfassen, können Sie Fluent Bit verwenden, um die Protokolle direkt an weiterzuleiten. CloudWatch Auf diese Weise können Sie Protokolle CloudWatch ohne weitere Konfiguration automatisch an einen Sidecar-Container für Ihre Amazon EKS-Pods auf Fargate weiterleiten. Weitere Informationen dazu finden Sie unter [Fargate-Protokollierung](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) in der Amazon EKS-Dokumentation und unter [Fluent Bit for Amazon EKS](https://aws.amazon.com//blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/) im AWS Blog. Diese Lösung erfasst die `STDOUT` und `STDERR` input/output (I/O) -Streams aus Ihrem Container und sendet sie CloudWatch über Fluent Bit an, basierend auf der Fluent Bit-Konfiguration, die für den Amazon EKS-Cluster auf Fargate eingerichtet wurde. 