**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. # Vereinfachung der Rechenverwaltung mit AWS Fargate In diesem Thema wird die Verwendung von Amazon EKS zum Ausführen von Kubernetes-Pods in AWS Fargate erläutert. Fargate ist eine Technologie, die bedarfsgerechte On-Demand-Rechenkapazität für [Container](https://aws.amazon.com/what-are-containers) bereitstellt. Mit Fargate müssen Sie keine Gruppen virtueller Maschinen selbst bereitstellen, konfigurieren oder skalieren, um Container auszuführen. Sie müssen auch keine Servertypen auswählen, entscheiden, wann Sie Ihre Knotengruppen skalieren oder die Cluster-Zusammenstellung optimieren. Sie können steuern, welche Pods in Fargate starten und wie sie mit [Fargate-Profilen](fargate-profile.md) ausgeführt werden. Fargate-Profile werden als Teil Ihres Amazon-EKS-Clusters definiert. Amazon EKS wird in Kubernetes mit Fargate integriert, indem Controller verwendet werden, die von AWS mithilfe des Upstream-Erweiterungsmodells von Kubernetes erstellt werden. Diese Controller werden als Teil der von Amazon EKS verwalteten Kubernetes-Steuerebene ausgeführt und sind für die Planung nativer Kubernetes-Pods in Fargate verantwortlich. Die Fargate-Controller enthalten einen neuen Scheduler, der neben dem Standard-Kubernetes-Scheduler und zusätzlich zu mehreren mutierenden und validierenden Zugangscontrollern ausgeführt wird. Wenn Sie einen Pod starten, der die Kriterien für die Ausführung in Fargate erfüllt, erkennen die Fargate-Controller, die im Cluster ausgeführt werden den Pod, und aktualisieren und planen ihn in Fargate. In diesem Thema werden die verschiedenen Komponenten von Pods beschrieben, die in Fargate ausgeführt werden, und auf besondere Überlegungen für die Verwendung von Fargate mit Amazon EKS hingewiesen. ## Überlegungen zu AWS-Fargate Hier sind einige Dinge, die Sie bei der Verwendung von Fargate auf Amazon EKS beachten sollten. + Jeder Pod, der in Fargate ausgeführt wird, verfügt über eine eigene Rechengrenze. Sie teilen sich weder den zugrunde liegenden Kernel noch CPU-Ressourcen, Speicherressourcen oder elastische Netzwerkschnittstellen mit anderen Pods. + Network Load Balancer und Application Load Balancer (ALBs) können mit Fargate nur mit IP-Zielen verwendet werden. Weitere Informationen erhalten Sie unter [Erstellen eines Network Load Balancers](network-load-balancing.md#network-load-balancer) und [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md). + Fargate-exponierte Services werden nur im IP-Modus des Zieltyps und nicht im Knoten-IP-Modus ausgeführt. Die empfohlene Möglichkeit, die Konnektivität von einem Service zu überprüfen, der auf einem verwalteten Knoten ausgeführt wird, und einem Service, der auf Fargate ausgeführt wird, besteht darin, eine Verbindung über den Servicenamen herzustellen. + Pods müssen zu dem Zeitpunkt, zu dem sie in Fargate ausgeführt werden sollen, mit einem Fargate-Profil übereinstimmen. Pods, die nicht mit einem Fargate-Profil übereinstimmen, können als `Pending` hängen bleiben. Wenn ein übereinstimmendes Fargate-Profil vorhanden ist, können Sie ausstehende Pods, die Sie erstellt haben, löschen, um sie in Fargate neu zu planen. + Daemonsets werden von Fargate nicht unterstützt. Wenn Ihre Anwendung einen Daemon benötigt, konfigurieren Sie diesen Daemon neu, sodass er als Sidecar-Container in Ihren Pods ausgeführt wird. + Privilegierte Container werden in Fargate nicht unterstützt. + Pods, die in Fargate ausgeführt werden, können im Pod-Manifest kein `HostPort` oder `HostNetwork` angeben. + Das standardmäßige weiche `nofile`- und `nproc`-Limit beträgt 1 024 und das harte Limit 65 535 für Fargate-Pods. + GPUs sind derzeit in Fargate nicht verfügbar. + Pods, die in Fargate ausgeführt werden, werden nur in privaten Subnetzen unterstützt (mit NAT Gateway-Zugriff auf AWS-Services, aber ohne direkte Route zu einem Internet-Gateway). Daher müssen für die VPC Ihres Clusters private Subnetze verfügbar sein. Weitere Informationen zu Clustern ohne ausgehenden Internetzugang finden Sie unter [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md). + Sie können die Option [Pod-Ressourcen mit Vertical Pod Autoscaler anpassen](vertical-pod-autoscaler.md) verwenden, um die anfängliche korrekte Größe von CPU und Arbeitsspeicher für Ihre Fargate-Pods festzulegen, und anschließend die Option [Pod-Bereitstellungen mit Horizontal Pod Autoscaler skalieren](horizontal-pod-autoscaler.md) verwenden, um diese Pods zu skalieren. Wenn Sie möchten, dass der Vertical Pod Autoscaler Pods mit größeren CPU- und Speicherkombinationen automatisch erneut in Fargate bereitstellt, stellen Sie den Modus für den Vertical Pod Autoscaler entweder auf `Auto` oder `Recreate` ein, um die korrekte Funktionalität sicherzustellen. Weitere Informationen finden Sie in der [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start)-Dokumentation auf GitHub. + DNS-Auflösung und DNS-Hostnamen müssen für Ihre VPC aktiviert sein. Weitere Informationen finden Sie unter [Anzeigen und Aktualisieren der DNS-Unterstützung für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating). + Amazon-EKS-Fargate erweitert die Verteidigung für Kubernetes-Anwendungen, indem jeder Pod innerhalb einer virtuellen Maschine (VM) isoliert wird. Diese VM-Grenze verhindert den Zugriff auf hostbasierte Ressourcen, die von anderen Pods im Falle eines Container-Escapes verwendet werden. Dies ist eine übliche Methode, um containerisierte Anwendungen anzugreifen und Zugriff auf Ressourcen außerhalb des Containers zu erhalten. Die Verwendung von Amazon EKS ändert nichts an Ihren Verantwortlichkeiten im Rahmen des [Modells der geteilten Verantwortung](security.md). Sie sollten die Konfiguration von Cluster-Sicherheits- und Governance-Kontrollen sorgfältig prüfen. Der sicherste Weg, eine Anwendung zu isolieren, besteht immer darin, sie in einem separaten Cluster auszuführen. + Fargate-Profile unterstützen die Angabe von Subnetzen aus sekundären VPC-CIDR-Blöcken. Möglicherweise möchten Sie einen sekundären CIDR-Block angeben. Das liegt daran, dass in einem Subnetz nur eine begrenzte Anzahl von IP-Adressen verfügbar ist. Daher gibt es auch eine begrenzte Anzahl von Pods, die im Cluster erstellt werden können. Durch die Verwendung verschiedener Subnetze für Pods können Sie die Anzahl der verfügbaren IP-Adressen erhöhen. Weitere Informationen finden Sie unter [Hinzufügen von IPv4 CIDR-Blöcken zu einer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize). + Amazon EC2 Instance Metadata Service (IMDS) ist für Pods, die auf Fargate-Knoten bereitgestellt werden, nicht verfügbar. Wenn Sie Pods haben, die in Fargate bereitgestellt werden und IAM-Anmeldeinformationen erfordern, weisen Sie diese Ihren Pods mithilfe von [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) zu. Wenn Ihre Pods Zugriff auf andere Informationen benötigen, die über das IMDS verfügbar sind, müssen Sie diese Informationen in Ihre Pod-Spezifikation hart codieren. Dies umfasst die AWS-Region oder Availability Zone, in der ein Pod bereitgestellt wird. + Sie können Fargate-Pods nicht in AWS Outposts, AWS Wavelength oder AWS Local Zones bereitstellen. + Amazon EKS muss Fargate-Pods regelmäßig patchen, um deren Sicherheit zu gewährleisten. Wir versuchen, die Auswirkungen von Aktualisierungen möglichst gering zu halten. Es kann jedoch vorkommen, dass Pods gelöscht werden müssen, wenn sie nicht erfolgreich bereinigt wurden. Es gibt einige Maßnahmen, die Sie durchführen können, um Unterbrechungen zu minimieren. Weitere Informationen finden Sie unter [Festlegung von Maßnahmen für Betriebssystem-Patching-Ereignisse für AWS Fargate](fargate-pod-patching.md). + Das [Amazon-VPC-CNI-Plugin für Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) ist standardmäßig auf Fargate-Knoten installiert. Sie können keine [Alternativen CNI-Plugins für Amazon-EKS-Cluster](alternate-cni-plugins.md) mit Fargate-Knoten verwenden. + Ein in Fargate ausgeführter Pod bindet automatisch ein Amazon-EFS-Dateisystem ein, ohne dass manuelle Schritte zur Treiberinstallation erforderlich sind. Sie können mit Fargate-Knoten keine dynamische Bereitstellung persistenter Volumes verwenden, aber Sie können eine statische Bereitstellung verwenden. + Amazon EKS unterstützt Fargate Spot nicht. + Sie können Amazon-EBS-Volumes nicht in Fargate-Pods mounten. + Sie können den Amazon-EBS-CSI-Controller in Fargate-Knoten ausführen, aber der Amazon-EBS-CSI-Knoten-DaemonSet kann nur in Amazon-EC2-Instances ausgeführt werden. + Nachdem ein [Kubernetes-Auftrag](https://kubernetes.io/docs/concepts/workloads/controllers/job/) als `Completed` oder `Failed` gekennzeichnet wurde, existieren die vom Auftrag erstellten Pods normalerweise weiter. Durch dieses Verhalten können Sie die Protokolle und Ergebnisse anzeigen. Bei Fargate entstehen jedoch Kosten, wenn Sie den Auftrag nachher nicht bereinigen. Um die zugehörigen Pods automatisch zu löschen, nachdem ein Auftrag abgeschlossen wurde oder fehlgeschlagen ist, können Sie mithilfe des TTL-Controllers (Time-to-Live) einen Zeitraum angeben. Das folgende Beispiel veranschaulicht die Angabe von `.spec.ttlSecondsAfterFinished` im Auftrags-Manifest. ``` apiVersion: batch/v1 kind: Job metadata: name: busybox spec: template: spec: containers: - name: busybox image: busybox command: ["/bin/sh", "-c", "sleep 10"] restartPolicy: Never ttlSecondsAfterFinished: 60 # <-- TTL controller ``` ## Fargate-Vergleichstabelle | Kriterien | AWS-Fargate | | --- | --- | | Kann in [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) bereitgestellt werden | Nein | | Kann auf eine [AWS Lokale Zone](local-zones.md) bereitgestellt werden | Nein | | Kann Container ausführen, die Windows benötigen | Nein | | Kann Container ausführen, die Linux benötigen | Ja | | Kann Workloads ausführen, die den Inferentia-Chip benötigen | Nein | | Kann Workloads ausführen, die eine GPU benötigen | Nein | | Kann Workloads ausführen, die Arm-Prozessoren benötigen | Nein | | Kann ausgeführt werdenAWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Nein | | Pods teilen eine Kernel-Laufzeitumgebung mit anderen Pods | Nein – Jeder Pod hat einen bestimmten Kernel | | Pods teilen CPU, Arbeitsspeicher, Speicher und Netzwerkressourcen mit anderen Pods. | Nein – Jeder Pod hat bestimmte Ressourcen und kann unabhängig voneinander dimensioniert werden, um die Ressourcenauslastung zu maximieren. | | Pods können mehr Hardware und Speicher verwenden, als in den Pod-Spezifikationen angefordert | Nein – Der Pod kann jedoch mit einer größeren vCPU und Speicherkonfiguration erneut bereitgestellt werden. | | Bereitstellen und Verwalten von Amazon-EC2-Instances | Nein | | Das Betriebssystem von Amazon-EC2-Instances muss gesichert, gewartet und gepatcht werden | Nein | | Kann Bootstrap-Argumente bei der Bereitstellung eines Knotens bereitstellen, z. B. zusätzliche [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)-Argumente. | Nein | | IP-Adressen können Pods aus einem anderen CIDR-Block als der dem Knoten zugewiesenen IP-Adresse zuweisen. | Nein | | SSH im Knoten nicht möglich | Nein – Es gibt kein Knoten-Host-Betriebssystem für SSH. | | Kann Ihr eigenes benutzerdefiniertes AMI auf Knoten bereitstellen | Nein | | Kann Ihr eigenes benutzerdefiniertes CNI auf Knoten bereitstellen | Nein | | Knoten-AMI muss selbst aktualisiert werden | Nein | | Muss die Kubernetes-Version des Knotens selbst aktualisieren | Nein – Sie verwalten keine Knoten. | | Kann Amazon-EBS-Speicher mit Pods verwenden | Nein | | Kann Amazon-EFS-Speicher mit Pods verwenden | [Ja](efs-csi.md) | | Kann Amazon FSx für Lustre Speicher mit Pods verwenden | Nein | | Kann Network Load Balancer für Services verwenden | Ja, bei Verwendung der Option [Network Load-Balancer erstellen](network-load-balancing.md#network-load-balancer) | | Pods können in einem öffentlichen Subnetz ausgeführt werden | Nein | | Kann einzelnen Pods verschiedene VPC-Sicherheitsgruppen zuweisen | Ja | | Kann Kubernetes DaemonSets ausführen | Nein | | Unterstützung für `HostPort` und `HostNetwork` im Pod-Manifest | Nein | | AWS-Verfügbarkeit in Regionen | [Einige von Amazon EKS unterstützte Regionen](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Kann Container auf Amazon-EC2-Dedicated-Hosts ausführen | Nein | | Preise | Kosten für eine individuelle Fargate-Speicher- und CPU-Konfiguration. Jeder Pod hat seine eigenen Kosten. Weitere Informationen dazu finden Sie unter [AWS-Fargate-Preise](https://aws.amazon.com/fargate/pricing/). | # Beginnen Sie mit AWS Fargate für Ihren Cluster In diesem Thema werden die ersten Schritte zum Ausführen von Pods auf AWS Fargate mit Ihrem Amazon EKS-Cluster beschrieben. Wenn Sie den Zugriff auf den öffentlichen Endpunkt Ihres Clusters mithilfe von CIDR-Blöcken einschränken, empfehlen wir, dass Sie auch den privaten Endpunktzugriff aktivieren. Auf diese Weise können Fargate-Pods mit dem Cluster kommunizieren. Wenn der private Endpunkt nicht aktiviert ist, müssen die CIDR-Blöcke, die Sie für den öffentlichen Zugriff angeben, die Ausgangsquellen aus Ihrer VPC enthalten. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md). **Voraussetzung** Einen vorhandenen -Cluster. Wenn Sie noch über keinen Amazon-EKS-Cluster verfügen, lesen Sie [Erste Schritte mit Amazon EKS](getting-started.md). ## Schritt 1: Sicherstellen, dass vorhandene Knoten mit Fargate-Pods kommunizieren können Wenn Sie mit einem neuen Cluster ohne Knoten oder einem Cluster nur mit verwalteten Knotengruppen arbeiten (siehe [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md)), können Sie mit [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](#fargate-sg-pod-execution-role) fortfahren. Angenommen, Sie arbeiten mit einem vorhandenen Cluster, dem bereits Knoten zugeordnet sind. Stellen Sie sicher, dass die Pods auf diesen Knoten problemlos mit den Pods kommunizieren können, die in Fargate ausgeführt werden. Pods, die in Fargate ausgeführt werden, werden automatisch so konfiguriert, dass die Cluster-Sicherheitsgruppe für den Cluster verwendet wird, dem sie zugeordnet sind. Stellen Sie sicher, dass alle vorhandenen Knoten in Ihrem Cluster Datenverkehr an die Cluster-Sicherheitsgruppe senden und von dieser empfangen können. Verwaltete Knotengruppen werden automatisch so konfiguriert, dass sie auch die Cluster-Sicherheitsgruppe verwenden. Sie müssen sie also nicht ändern oder auf Kompatibilität prüfen (siehe [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md)). Für bestehende Knotengruppen, die mit `eksctl` oder den von Amazon EKS verwalteten AWS CloudFormation Vorlagen erstellt wurden, können Sie die Cluster-Sicherheitsgruppe manuell zu den Knoten hinzufügen. Alternativ können Sie die Auto-Scaling-Gruppestartvorlage für die Knotengruppe ändern, um die Cluster-Sicherheitsgruppe an die Instances anzuhängen. Weitere Informationen finden Sie unter [Ändern der Sicherheitsgruppen einer Instance](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) im *Amazon-VPC-Benutzerhandbuch*. Sie können im Abschnitt **Netzwerk** für den Cluster AWS-Managementkonsole nach einer Sicherheitsgruppe für Ihren Cluster suchen. Oder Sie können dies mit dem folgenden AWS CLI-Befehl tun. Wenn Sie diesen Befehl verwenden, ersetzen Sie `` durch den Namen Ihres Clusters. ``` aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId ``` ## Schritt 2: Fargate-Pod-Ausführungsrolle erstellen Wenn Ihr Cluster Pods auf AWS Fargate erstellt, müssen die Komponenten, die auf der Fargate-Infrastruktur ausgeführt werden, in AWS APIs Ihrem Namen Aufrufe tätigen. Die Amazon-EKS-Pod-Ausführungsrolle stellt die entsprechenden IAM-Berechtigungen bereit. Informationen zum Erstellen einer AWS Fargate-Pod-Ausführungsrolle finden Sie unter[IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). **Anmerkung** Wenn Sie den Cluster mithilfe von `eksctl` und der `--fargate`-Option erstellt haben, verfügt der Cluster bereits über eine Pod-Ausführungsrolle, die Sie in der IAM-Konsole mit dem Muster `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL` finden können. Wenn Sie Ihre Fargate-Profile mit `eksctl` anlegen, erstellt `eksctl` Ihre Pod-Ausführungsrolle, sofern noch keine erstellt wurde. ## Schritt 3: Fargate Profil für Ihren Cluster erstellen Bevor Sie Pods planen können, die in Fargate in Ihrem Cluster ausgeführt werden, müssen Sie ein Fargate-Profil definieren, das angibt, welche Pods Fargate beim Start verwenden soll. Weitere Informationen finden Sie unter [Festlegung, welche Pods beim Start AWS Fargate verwenden](fargate-profile.md). **Anmerkung** Wenn Sie Ihren Cluster mithilfe von `eksctl` und der Option `--fargate` erstellt haben, wurde bereits ein Fargate-Profil für Ihren Cluster mit Selektoren für alle Pods in den `kube-system`- und `default`-Namespaces erstellt. Gehen Sie wie folgt vor, um Fargate-Profile für alle anderen Namespaces zu erstellen, die Sie mit Fargate verwenden möchten. Sie können mit einem dieser Tools ein Fargate-Profil erstellen: + [`eksctl`](#eksctl_fargate_profile_create) + [AWS-Managementkonsole](#console_fargate_profile_create) ### `eksctl` Für diesen Vorgang ist `eksctl` Version `0.215.0` oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen: ``` eksctl version ``` Eine Installations- und Upgrade-Anleitung für `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation). **So erstellen Sie ein Fargate-Profil mit `eksctl`** Erstellen Sie Ihr Fargate-Profil mit dem folgenden `eksctl`-Befehl und ersetzen Sie jede `` durch Ihre eigenen Werte. Sie müssen einen Namespace angeben. Die Option `--labels` ist jedoch nicht erforderlich. ``` eksctl create fargateprofile \ --cluster \ --name \ --namespace \ --labels ``` Sie können bestimmte Platzhalter für ``- und ``-Labels verwenden. Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](fargate-profile.md#fargate-profile-wildcards). ### AWS-Managementkonsole **So erstellen Sie ein Fargate-Profil mit AWS-Managementkonsole ** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Cluster aus, für den Sie ein Fargate-Profil erstellen möchten. 1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus. 1. Wählen Sie unter **Fargate-Profile** die Option **Fargate-Profil hinzufügen** aus. 1. Auf der Seite **Konfigurieren des Fargate Profils** führen Sie folgende Schritte aus: 1. Geben Sie unter **Name** einen Namen für Ihr Fargate-Profil ein. Der Name muss eindeutig sein. 1. Wählen Sie für **Pod-Ausführungsrolle** die Pod-Ausführungsrolle aus, die mit Ihrem Fargate-Profil verwendet werden soll. Es werden nur IAM-Rollen mit dem `eks-fargate-pods.amazonaws.com`-Service-Prinzipal angezeigt. Wenn keine Rollen aufgelistet sind, müssen Sie eine erstellen. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). 1. Ändern Sie die ausgewählten **Subnetze** nach Bedarf. **Anmerkung** Für Pods, die in Fargate ausgeführt werden, werden nur private Subnetze unterstützt. 1. Für **Tags** können Sie Ihr Fargate-Profil wahlweise markieren. Diese Tags werden nicht an andere Ressourcen weitergegeben, die dem Profil zugeordnet sind, z. B. Pods. 1. Wählen Sie **Weiter** aus. 1. Führen Sie auf der Seite **Pod-Auswahl konfigurieren** die folgenden Schritte aus: 1. Geben Sie für **Namespace** einen Namespace ein, der mit Pods übereinstimmt. + Sie können bestimmte Namespaces für den Abgleich verwenden, z. B. `kube-system` oder `default`. + Sie können bestimmte Platzhalter verwenden (z. B. `prod-*`), um mehrere Namespaces abzugleichen (z. B. `prod-deployment` und `prod-test`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](fargate-profile.md#fargate-profile-wildcards). 1. (Optional) Fügen Sie dem Selektor Kubernetes-Markierungen hinzu. Fügen Sie sie insbesondere demjenigen hinzu, dem die Pods im angegebenen Namespace entsprechen müssen. + Sie können dem Selektor das Label `infrastructure: fargate` hinzufügen, sodass nur Pods im angegebenen Namespace, die ebenfalls die `infrastructure: fargate`-Kubernetes-Bezeichnung tragen, mit dem Selektor übereinstimmen. + Sie können bestimmte Platzhalter verwenden (z. B. `key?: value?`), um mehrere Namespaces abzugleichen (z. B. `keya: valuea` und `keyb: valueb`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](fargate-profile.md#fargate-profile-wildcards). 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie auf der Seite **Überprüfen und erstellen** die Informationen für Ihr -Profil und wählen Sie **Erstellen** aus. ## Schritt 4: CoreDNS aktualisieren Standardmäßig ist CoreDNS so konfiguriert, dass es auf der EC2 Amazon-Infrastruktur auf Amazon EKS-Clustern ausgeführt wird. Wenn Sie Ihre Pods *nur* in Fargate in Ihrem Cluster ausführen möchten, führen Sie die folgenden Schritte aus. **Anmerkung** Wenn Sie einen Cluster mit `eksctl` unter Verwendung von `--fargate`-Option erstellt haben, können Sie zu [Nächste Schritte](#fargate-gs-next-steps) springen. 1. Erstellen Sie jedes Fargate-Profil für CoreDNS mit dem folgenden Befehl. ``Ersetzen Sie es durch Ihren Clusternamen, `<111122223333>` durch Ihre Konto-ID, `` durch den Namen Ihrer Pod-Ausführungsrolle und `<000000000000000a>``<000000000000000b>`, und `<000000000000000c>` durch die IDs Ihrer privaten Subnetze. Wenn Sie über keine Pod-Ausführungsrolle verfügen, müssen Sie zuerst eine erstellen (siehe [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](#fargate-sg-pod-execution-role)). **Wichtig** Der Rollen-ARN darf als [Pfad](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) nur `/` enthalten. Wenn der Name Ihrer Rolle also beispielsweise `development/apps/AmazonEKSFargatePodExecutionRole` lautet, müssen Sie ihn beim Angeben des ARN für die Rolle in `AmazonEKSFargatePodExecutionRole` ändern. Das Format des Rollen-ARN muss ` arn:aws: iam::<111122223333>:role/` sein. ``` aws eks create-fargate-profile \ --fargate-profile-name coredns \ --cluster-name \ --pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \ --selectors namespace=kube-system,labels={k8s-app=kube-dns} \ --subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c> ``` 1. Lösen Sie die Einführung der `coredns`-Bereitstellung aus. ``` kubectl rollout restart -n kube-system deployment coredns ``` ## Nächste Schritte + Mit dem folgenden Workflow können Sie mit der Migration Ihrer vorhandenen Anwendungen zum Ausführen in Fargate beginnen. 1. [Erstellen eines Fargate-Profils](fargate-profile.md#create-fargate-profile), das mit dem Kubernetes-Namespace und den Kubernetes-Labels Ihrer Anwendung übereinstimmt. 1. Löschen Sie alle vorhandenen Pods und erstellen Sie sie neu, damit sie auf Fargate geplant werden. Ändern Sie `` und ``, um Ihre spezifischen Pods zu aktualisieren. ``` kubectl rollout restart -n deployment ``` + Stellen Sie das [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md) bereit, um Eingangsobjekte für Ihre Pods zuzulassen, die auf Fargate ausgeführt werden. + Sie können [Pod-Ressourcen mit Vertical Pod Autoscaler anpassen](vertical-pod-autoscaler.md) verwenden, um die CPU und den Speicher für Ihre Fargate- anfänglich richtig zu dimensionieren, und dann Fargate Pods verwenden, um [Skalierung von Pod-Bereitstellungen mit Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) diese Pods zu skalieren. Wenn Sie möchten, dass der Vertical Pod Autoscaler `Auto` mit höheren CPU- und Speicherkombinationen automatisch erneut in Fargate bereitstellt, stellen Sie den Modus für den Vertical-Pod-Autoscaler-Modus entweder auf oder `Recreate`. Dies dient der Gewährleistung einer korrekten Funktion. Weitere Informationen finden Sie in der [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start)-Dokumentation auf GitHub. + Sie können den [AWS Distro für OpenTelemetry](https://aws.amazon.com/otel)(ADOT)-Kollektor zur Anwendungsüberwachung durch Befolgen [dieser Anweisungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html) einrichten. # Festlegung, welche Pods beim Start AWS Fargate verwenden Bevor Sie Pods auf Fargate in Ihrem Cluster planen, müssen Sie mindestens ein Fargate-Profil definieren, das angibt, welche Pods Fargate beim Start verwenden. Als Administrator können Sie mithilfe eines Fargate-Profils angeben, welche Pods in Fargate ausgeführt werden. Sie können dies über die Selektoren des Profils tun. Sie können bis zu fünf Selektoren zu jedem Profil hinzufügen. Jeder Selektor muss einen Namespace enthalten. Der Selector kann auch Labels enthalten. Das Label-Feld besteht aus mehreren optionalen Schlüssel-Wert-Paaren. Pods, die den Selektoren entsprechen, werden auf Fargate geplant. Pods werden mit einem Namespace und den Labels abgeglichen, die im Selektor angegeben sind. Wenn ein Namespace-Selektor ohne Labels definiert ist, versucht Amazon EKS, alle Pods, die in diesem Namespace ausgeführt werden, mithilfe des Profils in Fargate zu planen. Wenn ein zu planender Pod mit einem der Selektoren im Fargate-Profil übereinstimmt, wird dieser Pod in Fargate geplant. Wenn ein Pod mit mehreren Fargate-Profilen übereinstimmt, können Sie angeben, welches Profil ein Pod verwendet, indem Sie der Pod-Spezifikation das folgende Kubernetes-Label hinzufügen: `eks.amazonaws.com/fargate-profile: my-fargate-profile`. Der Pod muss mit einem Selektor in diesem Profil übereinstimmen, um in Fargate geplant zu werden. Die Affinitäts-/Anti-Affinitätsregeln von Kubernetes gelten nicht und sind bei Amazon-EKS-Fargate-Pods nicht erforderlich. Wenn Sie ein Fargate-Profil erstellen, müssen Sie eine Pod-Ausführungsrolle angeben. Diese Ausführungsrolle ist für die Amazon-EKS-Komponenten vorgesehen, die auf der Fargate-Infrastruktur mit dem Profil ausgeführt werden. Es wird zur Autorisierung der [Rollenbasierten Zugriffskontrolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) von Kubernetes des Clusters hinzugefügt. Auf diese Weise kann sich `kubelet`, das in der Fargate-Infrastruktur ausgeführt wird, bei Ihrem Amazon-EKS-Cluster registrieren und als Knoten in Ihrem Cluster angezeigt werden. Die Pod-Ausführungsrolle bietet auch IAM-Berechtigungen für die Fargate-Infrastruktur, um Lesezugriff auf Amazon-ECR-Image-Repositorys zu ermöglichen. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). Fargate-Profile können nicht geändert werden. Sie können jedoch ein neues aktuelles Profil erstellen, um ein vorhandenes Profil zu ersetzen, und dann das Original löschen. **Anmerkung** Alle Pods, die mit einem Fargate-Profil ausgeführt werden, werden angehalten und als ausstehend gekennzeichnet, wenn das Profil gelöscht wird. Wenn Fargate-Profile in einem Cluster den Status `DELETING` haben, müssen Sie warten, bis dieses Fargate-Profil gelöscht wurde, bevor Sie andere Profile in diesem Cluster erstellen können. **Anmerkung** Fargate unterstützt derzeit keine Kubernetes [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). Amazon EKS und Fargate verteilen Pods auf alle Subnetze, die im Fargate-Profil definiert sind. Es kann jedoch zu einer ungleichmäßigen Verteilung kommen. Wenn Sie eine gleichmäßige Verteilung benötigen, verwenden Sie zwei Fargate-Profile. Eine gleichmäßige Verteilung ist in Szenarien wichtig, in denen Sie zwei Replikate bereitstellen möchten und keine Ausfallzeiten wünschen. Wir empfehlen, dass jedes Profil nur ein Subnetz hat. ## Fargate-Profilkomponenten Die folgenden Komponenten sind in einem Fargate-Profil enthalten. **Pod-Ausführungsrolle** Wenn Ihr Cluster Pods auf AWS Fargate erstellt, muss das auf der Fargate-Infrastruktur ausgeführte `kubelet` in Ihrem Namen AWS-API-Aufrufe durchführen. Beispielsweise muss er Aufrufe tätigen, um Container-Images aus Amazon ECR zu ziehen. Die Amazon-EKS-Pod-Ausführungsrolle stellt die entsprechenden IAM-Berechtigungen bereit. Wenn Sie ein Fargate-Profil erstellen, müssen Sie eine Pod-Ausführungsrolle angeben, die mit Ihren Pods verwendet werden soll. Diese Rolle wird zur Autorisierung der [Rollenbasierten Zugriffskontrolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) von Kubernetes des Clusters hinzugefügt. Auf diese Weise kann sich `kubelet`, das in der Fargate-Infrastruktur ausgeführt wird, bei Ihrem Amazon-EKS-Cluster registrieren und als Knoten in Ihrem Cluster angezeigt werden. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). **Subnets** Die IDs von Subnetzen, in denen Pods gestartet werden, die dieses Profil verwenden. Derzeit werden Pods, die in Fargate ausgeführt werden, keine öffentlichen IP-Adressen zugewiesen. Daher werden für diesen Parameter nur private Subnetze ohne direkte Route zu einem Internet-Gateway akzeptiert. **Selektoren** Die Selektoren, mit denen Pods, die dieses Fargate-Profil verwenden, übereinstimmen sollen. Sie können bis zu fünf Selektoren in einem Fargate-Profil angeben. Die Selektoren bestehen aus folgenden Komponenten: + **Namespace** – Sie müssen einen Namespace für einen Selektor angeben. Der Selektor stimmt nur mit Pods überein, die in diesem Namespace erstellt werden. Sie können jedoch mehrere Selektoren erstellen, um mehrere Namespaces zu adressieren. + **Bezeichnungen** – Sie können optional Kubernetes-Bezeichnungen angeben, mit denen der Selektor übereinstimmen muss. Der Selektor stimmt nur mit Pods überein, die alle im Selektor angegebenen Labels aufweisen. ## Platzhalter für Fargate-Profile Zusätzlich zu den Zeichen, die von Kubernetes erlaubt sind, dürfen Sie `*` und `?` in den Selektorkriterien für Namespaces, Label-Schlüssel und Label-Werte verwenden: + `*` steht für kein, ein oder mehrere Zeichen. Zum Beispiel kann `prod*` `prod` und `prod-metrics` darstellen. + `?` steht für ein einzelnes Zeichen (z. B. kann `value?` `valuea` darstellen). Es kann jedoch nicht `value` und `value-a` darstellen, weil `?` nur genau ein Zeichen darstellen kann. Diese Platzhalterzeichen können an jeder Position und in Kombination verwendet werden (z. B. `prod*`, `*dev` und `frontend*?`). Andere Platzhalter und Formen des Mustervergleichs, wie reguläre Ausdrücke, werden nicht unterstützt. Wenn mehrere übereinstimmende Profile für den Namespace und die Labels in der Pod-Spezifikation vorhanden sind, übernimmt Fargate das Profil basierend auf einer alphanumerischen Sortierung nach Profilnamen. Wenn zum Beispiel Profil A (mit dem Namen `beta-workload`) und Profil B (mit dem Namen `prod-workload`) passende Selektoren für die zu startenden Pods haben, wählt Fargate Profil A (`beta-workload`) für die Pods aus. Die Pods haben Labels mit Profil A auf den Pods (z. B. `eks.amazonaws.com/fargate-profile=beta-workload`). Wenn Sie vorhandene Fargate-Pods auf neue Profile migrieren möchten, die Platzhalter verwenden, gibt es zwei Möglichkeiten, dies zu tun: + Erstellen Sie ein neues Profil mit passenden Selektoren und löschen Sie dann die alten Profile. Mit alten Profilen gekennzeichnete Pods werden in neue übereinstimmende Profile verschoben. + Wenn Sie Workloads migrieren möchten, sich aber nicht sicher sind, welche Fargate-Labels sich auf jedem Fargate-Pod befinden, können Sie die folgende Methode verwenden. Erstellen Sie ein neues Profil mit einem Namen, das zuerst alphanumerisch unter den Profilen auf demselben Cluster sortiert. Recyceln Sie dann die Fargate-Pods, die in neue Profile migriert werden müssen. ## Erstellen eines Fargate-Profils In diesem Abschnitt wird beschrieben, wie Sie ein Fargate-Profil erstellen. Sie müssen auch eine Pod-Ausführungsrolle erstellt haben, die für Ihr Fargate-Profil verwendet werden soll. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). Pods, die in Fargate ausgeführt werden, werden nur in privaten Subnetzen unterstützt (mit [NAT Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)-Zugriff auf AWS-Services, aber ohne direkte Route zu einem Internet-Gateway. Dies ist so, da in der VPC Ihres Clusters private Subnetze verfügbar sein müssen. Sie können ein Profil mit Folgendem erstellen: + [`eksctl`](#eksctl_create_a_fargate_profile) + [AWS-Managementkonsole](#console_create_a_fargate_profile) ## `eksctl` **So erstellen Sie ein Fargate-Profil mit `eksctl`** Erstellen Sie Ihr Fargate-Profil mit dem folgenden `eksctl`-Befehl und ersetzen Sie dabei alle Beispielwerte durch Ihre eigenen Werte. Sie müssen einen Namespace angeben. Die Option `--labels` ist jedoch nicht erforderlich. ``` eksctl create fargateprofile \ --cluster my-cluster \ --name my-fargate-profile \ --namespace my-kubernetes-namespace \ --labels key=value ``` Sie können bestimmte Platzhalter für `my-kubernetes-namespace`- und `key=value`-Labels verwenden. Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](#fargate-profile-wildcards). ## AWS-Managementkonsole **So erstellen Sie ein Fargate-Profil mit AWS-Managementkonsole** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Cluster aus, für den Sie ein Fargate-Profil erstellen möchten. 1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus. 1. Wählen Sie unter **Fargate-Profile** die Option **Fargate-Profil hinzufügen** aus. 1. Auf der Seite **Konfigurieren des Fargate Profils** führen Sie folgende Schritte aus: 1. Geben Sie unter **Name** einen eindeutigen Namen für Ihr Fargate-Profil ein, wie z. B. `my-profile`. 1. Wählen Sie für **Pod-Ausführungsrolle** die Pod-Ausführungsrolle aus, die mit Ihrem Fargate-Profil verwendet werden soll. Es werden nur IAM-Rollen mit dem `eks-fargate-pods.amazonaws.com`-Service-Prinzipal angezeigt. Wenn keine Rollen aufgelistet sind, müssen Sie eine erstellen. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). 1. Ändern Sie die ausgewählten **Subnetze** nach Bedarf. **Anmerkung** Für Pods, die in Fargate ausgeführt werden, werden nur private Subnetze unterstützt. 1. Für **Tags** können Sie Ihr Fargate-Profil wahlweise markieren. Diese Tags werden nicht an andere Ressourcen weitergegeben, die dem Profil zugeordnet sind, z. B. Pods. 1. Wählen Sie **Weiter** aus. 1. Führen Sie auf der Seite **Pod-Auswahl konfigurieren** die folgenden Schritte aus: 1. Geben Sie für **Namespace** einen Namespace ein, der mit Pods übereinstimmt. + Sie können bestimmte Namespaces für den Abgleich verwenden, z. B. `kube-system` oder `default`. + Sie können bestimmte Platzhalter verwenden (z. B. `prod-*`), um mehrere Namespaces abzugleichen (z. B. `prod-deployment` und `prod-test`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](#fargate-profile-wildcards). 1. (Optional) Fügen Sie dem Selektor Kubernetes-Markierungen hinzu. Fügen Sie sie insbesondere demjenigen hinzu, dem die Pods im angegebenen Namespace entsprechen müssen. + Sie können dem Selektor das Label `infrastructure: fargate` hinzufügen, sodass nur Pods im angegebenen Namespace, die ebenfalls die `infrastructure: fargate`-Kubernetes-Bezeichnung tragen, mit dem Selektor übereinstimmen. + Sie können bestimmte Platzhalter verwenden (z. B. `key?: value?`), um mehrere Namespaces abzugleichen (z. B. `keya: valuea` und `keyb: valueb`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](#fargate-profile-wildcards). 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie auf der Seite **Überprüfen und erstellen** die Informationen für Ihr -Profil und wählen Sie **Erstellen** aus. # Fargate-Profil löschen In diesem Thema wird beschrieben, wie Sie ein Fargate-Profil löschen. Wenn Sie ein Fargate-Profil löschen, werden alle Pods gelöscht, die in Fargate mit dem Profil geplant wurden. Wenn diese Pods mit einem anderen Fargate-Profil übereinstimmen, werden sie mit diesem Profil in Fargate geplant. Wenn sie nicht mehr mit einem der Fargate-Profile übereinstimmen, werden sie nicht in Fargate geplant und ggf. als ausstehend gekennzeichnet. Nur ein Fargate-Profil in einem Cluster kann sich jeweils im `DELETING`-Status befinden. Warten Sie, bis das Löschen eines Fargate-Profils abgeschlossen ist, bevor Sie andere Profile in diesem Cluster löschen können. Sie können ein Profil mit einem der folgenden Tools löschen: + [`eksctl`](#eksctl_delete_a_fargate_profile) + [AWS-Managementkonsole](#console_delete_a_fargate_profile) + [AWS-CLI](#awscli_delete_a_fargate_profile) ## `eksctl` **Löschen eines Fargate-Profils mit `eksctl` ** Verwenden Sie den folgenden Befehl, um ein Profil aus einem Cluster zu löschen. Ersetzen Sie jeden *Beispielwert* durch Ihre eigenen Werte. ``` eksctl delete fargateprofile --name my-profile --cluster my-cluster ``` ## AWS-Managementkonsole **Löschen eines Fargate-Profils mit AWS-Managementkonsole ** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus. Wählen Sie in der Clusterliste den Cluster aus, in dem Sie das Fargate-Profil löschen möchten. 1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus. 1. Wählen Sie das zu löschende Fargate-Profil und dann **Delete** (Löschen) aus. 1. Geben Sie auf der Seite **Delete Fargate profile** (Fargate-Profil löschen) den Namen des Profils ein und wählen Sie dann **Delete** (Löschen) aus. ## AWS-CLI **Löschen eines Fargate-Profils mit der AWS-CLI** Verwenden Sie den folgenden Befehl, um ein Profil aus einem Cluster zu löschen. Ersetzen Sie jeden *Beispielwert* durch Ihre eigenen Werte. ``` aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster ``` # Details zur Fargate-Pod-Konfiguration verstehen In diesem Abschnitt werden einige der eindeutigen Pod-Konfigurationsdetails für die Ausführung von Kubernetes-Pods in AWS-Fargate beschrieben. ## CPU und Arbeitsspeicher des Pods Mit Kubernetes können Sie Anforderungen, eine minimale vCPU-Menge und Arbeitsspeicherressourcen definieren, die jedem Container in einem Pod zugewiesen werden. Pods werden von Kubernetes geplant, um sicherzustellen, dass mindestens die angeforderten Ressourcen für jeden Pod in der Rechenressource verfügbar sind. Weitere Informationen finden Sie unter [Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) in der Kubernetes-Dokumentation. **Anmerkung** Da Amazon-EKS-Fargate nur einen Pod pro Knoten ausführt, tritt das Szenario des Räumens von Pods bei weniger Ressourcen nicht auf. Alle Amazon-EKS-Fargate-Pods werden mit garantierter Priorität ausgeführt, daher müssen die angeforderte CPU-Leistung und der Arbeitsspeicher für alle Container dem Limit entsprechen. Weitere Informationen finden Sie unter [Konfigurieren von Dienstqualität für Pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) in der Kubernetes-Dokumentation. Wenn Pods in Fargate geplant sind, bestimmen die vCPU- und Speicherreservierungen innerhalb der Pod-Spezifikation, wie viel CPU und Speicher für den Pod bereitgestellt werden sollen. + Die maximale Anforderung von Init-Containern wird verwendet, um die vCPU- und Speicheranforderungen für die Init-Anforderung zu bestimmen. + Anforderungen für alle lang laufenden Container werden addiert, um die Anforderungen an die vCPU und den Arbeitsspeicher für lange laufende Anforderungen zu bestimmen. + Der größere der beiden zuvor genannten Werte wird für die vCPU und die Speicheranforderung für Ihren Pod ausgewählt. + Fargate fügt 256 MB zur Speicherreservierung jedes Pods für die erforderlichen Kubernetes-Komponenten (`kubelet`, `kube-proxy` und `containerd`) hinzu. Fargate rundet auf die folgende Rechenkonfiguration auf, die der Summe von vCPU und Speicheranforderungen am nächsten liegt, damit Pods immer über die Ressourcen verfügen, die sie für ihre Ausführung benötigen. Wenn Sie keine vCPU- und Speicherkombination angeben, wird die kleinste verfügbare Kombination verwendet (0,25 vCPU und 0,5 GB Arbeitsspeicher). Die folgende Tabelle zeigt die vCPU- und Speicherkombinationen, die für Pods verfügbar sind, die in Fargate ausgeführt werden. | vCPU-Wert | Speicherwert | | --- | --- | | 0,25 vCPU | 0,5 GB, 1 GB, 2 GB | | 0,5 vCPU | 1 GB, 2 GB, 3 GB, 4 GB | | 1 vCPU | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB | | 2 vCPU | Zwischen 4 GB und 16 GB in 1-GB-Schritten | | 4 vCPU | Zwischen 8 GB und 30 GB in 1-GB-Schritten | | 8 vCPU | Zwischen 16 GB und 60 GB in 4-GB-Schritten | | 16 vCPU | Zwischen 32 GB und 120 GB in 8-GB-Schritten | Der für die Kubernetes-Komponenten reservierte zusätzliche Arbeitsspeicher kann dazu führen, dass eine Fargate-Aufgabe mit mehr vCPUs als angefordert bereitgestellt wird. Bei einer Anforderung von 1 vCPU und 8 GB Speicher werden beispielsweise 256 MB zu ihrer Speicheranforderung hinzugefügt und eine Fargate-Aufgabe mit 2 vCPUs und 9 GB Speicher bereitgestellt, da keine Aufgabe mit 1 vCPU und 9 GB Speicher verfügbar ist. Es gibt keine Korrelation zwischen der Größe des Pods, der auf Fargate ausgeführt wird, und der von Kubernetes gemeldeten Knotengröße mit `kubectl get nodes`. Die gemeldete Knotengröße ist oft größer als die Kapazität des Pods. Sie können die Pod-Kapazität mit dem folgenden Befehl überprüfen. Ersetzen Sie *default* durch den Namespace Ihres Pods und *pod-name* durch den Namen Ihres Pods ``` kubectl describe pod --namespace default pod-name ``` Eine Beispielausgabe sieht wie folgt aus. ``` [...] annotations: CapacityProvisioned: 0.25vCPU 0.5GB [...] ``` Die `CapacityProvisioned`-Annotation stellt die erzwungene Pod-Kapazität dar und bestimmt die Kosten Ihres Pods, der auf Fargate ausgeführt wird. Preisinformationen für die Computing-Konfigurationen finden Sie unter [AWS-Fargate-Preise](https://aws.amazon.com/fargate/pricing/). ## Fargate-Speicher Ein in Fargate ausgeführter Pod bindet automatisch ein Amazon-EFS-Dateisystem ein, ohne dass manuelle Schritte zur Treiberinstallation erforderlich sind. Sie können mit Fargate-Knoten keine dynamische Bereitstellung persistenter Volumes verwenden, aber Sie können eine statische Bereitstellung verwenden. Weitere Informationen finden Sie unter [Amazon-EFS-CSI-Treiber](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) in GitHub. Bei der Bereitstellung erhält jedes Pod, die in Fargate ausgeführt wird, standardmäßig 20 GiB flüchtigen Speicher. Diese Art von Speicher wird gelöscht, nachdem ein Pod stoppt. Bei neu auf Fargate gestarteten Pods ist die Verschlüsselung des flüchtigen Speicher-Volumes standardmäßig aktiviert. Der flüchtige Pod-Speicher wird mit einem AES-256-Verschlüsselungsalgorithmus mit AWS-Fargate-verwalteten Schlüsseln verschlüsselt. **Anmerkung** Der standardmäßig nutzbare Speicher für Amazon-EKS-Pods, die in Fargate ausgeführt werden, beträgt weniger als 20 GiB. Dies liegt daran, dass ein Teil des Speicherplatzes von `kubelet` und anderen Kubernetes-Modulen belegt wird, die im Pod geladen werden. Sie können die Gesamtmenge des flüchtigen Speichers bis zu einem Maximum von 175 GB erhöhen. Um die Größe mit Kubernetes zu konfigurieren, geben Sie die `ephemeral-storage`-Ressourcen-Anfragen für jeden Container in einem Pod an. Wenn Kubernetes Pods plant, stellt es sicher, dass die Summe der Ressourcen-Anfragen für jeden Pod geringer ist als die Kapazität der Fargate-Aufgabe. Weitere Informationen finden Sie unter [Ressourcen-Management für Pods und Container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) in der Kubernetes-Dokumentation. Amazon EKS Fargate stellt mehr kurzlebigen Speicher bereit, als für die Systemnutzung angefordert wurde. Eine Anforderung von 100 GB stellt beispielsweise eine Fargate-Aufgabe mit 115 GB flüchtigem Speicher bereit. # Festlegung von Maßnahmen für Betriebssystem-Patching-Ereignisse für AWS Fargate Amazon EKS patcht regelmäßig das Betriebssystem für AWS-Fargate-Knoten, damit sie sicher bleiben. Im Rahmen des Patching-Prozesses werden die Knoten recycelt, um Betriebssystem-Patches zu installieren. Updates werden so durchgeführt, dass sie Ihre Services möglichst wenig beeinflussen. Wenn Pods jedoch nicht erfolgreich bereinigt wurden, kann es sein, dass sie gelöscht werden müssen. Die folgenden Maßnahmen können Ihnen helfen, potenzielle Unterbrechungen zu minimieren: + Legen Sie geeignete Budgets für Pod-Unterbrechung (PBDs) fest, um die Anzahl der Pods, die gleichzeitig ausfallen, zu steuern. + Erstellen Sie Amazon-EventBridge-Regeln für den Umgang mit fehlgeschlagenen Bereinigungen, bevor die Pods gelöscht werden. + Starten Sie die betroffenen Pods manuell neu, bevor das in der Benachrichtigung angegebene Bereinigungsdatum erreicht ist. + Erstellen Sie eine Benachrichtigungskonfiguration in AWS-Benutzerbenachrichtigungen. Amazon EKS arbeitet eng mit der Kubernetes-Community zusammen, um Fehlerbehebungen und Sicherheits-Patches so schnell wie möglich bereitzustellen. Alle Fargate-Pods starten mit der aktuellsten Kubernetes-Patch-Version, die über die über Amazon EKS für die Kubernetes-Version Ihres Clusters verfügbar ist. Wenn Sie einen Pod mit einer älteren Patch-Version haben, recycelt Amazon EKS ihn möglicherweise, um ihn auf die neueste Version zu aktualisieren. Das stellt sicher, dass Ihre Pods mit den neuesten Sicherheitsaktualisierungen ausgestattet sind. Wenn ein [Häufige Schwachstellen und Aufdeckungen](https://cve.mitre.org/) (CVE)-Problem auftritt, bleiben Sie so auf dem Laufenden und können Sicherheitsrisiken reduzieren. Wenn das AWS-Fargate-Betriebssystem aktualisiert wird, sendet Ihnen Amazon EKS eine Benachrichtigung, die Ihre betroffenen Ressourcen und das Datum der bevorstehenden Pod-Bereinigungen enthält. Wenn das angegebene Bereinigungsdatum ungünstig ist, haben Sie die Möglichkeit, Ihre betroffenen Pods vor dem in der Benachrichtigung angegebenen Bereinigungsdatum manuell neu zu starten. Alle Pods, die vor dem Zeitpunkt der Benachrichtigung erstellt wurden, können bereinigt werden. Weitere Anweisungen zum manuellen Neustart Ihrer Pods finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart). Um die Anzahl der Pods zu begrenzen, die bei der Wiederverwendung von Pods gleichzeitig ausfallen, können Sie Budgets für Pod-Unterbrechung (PDBs) festlegen. Sie können PDBs verwenden, um die Mindestverfügbarkeit basierend auf den Anforderungen jeder Ihrer Anwendungen zu definieren und gleichzeitig Aktualisierungen zuzulassen. Die Mindestverfügbarkeit Ihres PDB muss unter 100 % liegen. Weitere Informationen finden Sie unter [Angabe eines Budgets für Unterbrechung in Ihrer Anwendung](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) in der Kubernetes-Dokumentation. Amazon EKS verwendet die [Bereinigungs-AMI](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api), um den Pod sicher zu leeren. Dabei werden die PDBs eingehalten, die Sie für die Anwendung festgelegt haben. Pods werden von der Availability Zone bereinigt, um Auswirkungen zu minimieren. Wenn die Bereinigung erfolgreich ist, erhält der neue Pod den aktuellsten Patch und es sind keine weiteren Maßnahmen erforderlich. Wenn die Bereinigung für einen Pod fehlschlägt, sendet Amazon EKS ein Ereignis an Ihr Konto, das Details über die Pods enthält, deren Bereinigung fehlgeschlagen ist. Sie können vor der geplanten Beendigungszeit auf die Nachricht reagieren. Die spezifische Zeit variiert je nach Dringlichkeit des Patches. Zum festgelegten Zeitpunkt versucht Amazon EKS erneut, die Pods zu bereinigen. Dieses Mal wird bei einer fehlgeschlagenen Bereinigung jedoch kein neues Ereignis gesendet. Wenn die Bereinigung erneut fehlschlägt, werden Ihre vorhandenen Pods regelmäßig gelöscht, damit neue Pods den aktuellsten Patch haben. Nachfolgend sehen Sie ein Beispielereignis, das Sie erhalten könnten, wenn die Pod-Bereinigung fehlschlägt. Es enthält Informationen über den Cluster, den Pod-Namen, den Pod-Namespace, das Fargate-Profil und die geplante Beendigungszeit. ``` { "version": "0", "id": "12345678-90ab-cdef-0123-4567890abcde", "detail-type": "EKS Fargate Pod Scheduled Termination", "source": "aws.eks", "account": "111122223333", "time": "2021-06-27T12:52:44Z", "region": "region-code", "resources": [ "default/my-database-deployment" ], "detail": { "clusterName": "my-cluster", "fargateProfileName": "my-fargate-profile", "podName": "my-pod-name", "podNamespace": "default", "evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget", "scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]" } } ``` Einer der Gründe für ein Bereinigungsfehlerereignis kann sein, dass einem Pod mehrere PDBs zugeordnet sind. In diesem Fall gibt das Ereignis die folgende Fehlernachricht zurück. ``` "evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support", ``` Basierend auf diesem Ereignis können Sie eine gewünschte Aktion erstellen. Sie können beispielsweise Ihr Budget für Pod-Unterbrechung (PDB) anpassen, um zu steuern, wie die Pods bereinigt werden. Nehmen Sie zum Beispiel an, dass Sie ein PDB starten, dass den Zielprozentsatz von verfügbaren Pods angibt. Bevor Ihre Pods während eines Upgrades automatisch beendet werden, können Sie das PDB an einen unterschiedlichen Prozentsatz von Pods anpassen. Um dieses Ereignis zu erhalten, müssen Sie eine Amazon-EventBridge-Regel im AWS-Konto und der AWS-Region erstellen, zu denen der Cluster gehört. Die Regel muss das folgende **benutzerdefinierte Muster** verwenden. Weitere Informationen finden Sie unter [Erstellen von Erstellen von Amazon-EventBridge-Regeln, die auf Ereignisse reagieren](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) im *Amazon-EventBridge-Benutzerhandbuch*. ``` { "source": ["aws.eks"], "detail-type": ["EKS Fargate Pod Scheduled Termination"] } ``` Es kann ein geeignetes Ziel zur Erfassung durch das Ereignis festgelegt werden. Eine vollständige Liste der verfügbaren Ziele finden Sie unter [Amazon-EventBridge-Ziele](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) im *Amazon-EventBridge-Benutzerhandbuch*. Sie können eine Benachrichtigungskonfiguration in AWS-Benutzerbenachrichtigungen erstellen. Wenn Sie die AWS-Managementkonsole verwenden, um die Benachrichtigung zu erstellen, wählen Sie unter **Ereignisregeln** **Elastic Kubernetes Service (EKS)** als **AWS-Name** und **Geplante Beendigung des EKS-Fargate-Pod** als **Ereignistyp** aus. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Benutzerbenachrichtigungen](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) im AWS-Benutzerhandbuch für Benutzerbenachrichtigungen. Häufig gestellte Fragen zu EKS-Pod-Bereinigungen finden Sie in den [FAQs: Bereinigungsbeanchrichtigung für Fargate-Pods](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) in * AWS re:Post*. # Erfassen Sie die App- und Nutzungsmetriken von AWS Fargate Sie können Systemmetriken und CloudWatch Nutzungsmetriken für AWS Fargate sammeln. ## Anwendungsmetriken Für Anwendungen, die auf Amazon EKS und AWS Fargate ausgeführt werden, können Sie die AWS Distribution for OpenTelemetry (ADOT) verwenden. ADOT ermöglicht es Ihnen, Systemmetriken zu sammeln und sie an Container Insights-Dashboards zu CloudWatch senden. Informationen zu den ersten Schritten mit ADOT für Anwendungen, die auf Fargate ausgeführt werden, finden Sie unter [Using CloudWatch Container Insights with AWS Distro for OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) in der ADOT-Dokumentation. ## Nutzungsmetriken Sie können CloudWatch Nutzungsmetriken verwenden, um einen Überblick über die Ressourcennutzung Ihres Kontos zu erhalten. Verwenden Sie diese Metriken, um Ihre aktuelle Servicenutzung in CloudWatch Diagrammen und Dashboards zu visualisieren. AWS Die Nutzungsmetriken von Fargate entsprechen den AWS Servicekontingenten. Sie können Alarme konfigurieren, mit denen Sie benachrichtigt werden, wenn sich Ihre Nutzung einem Servicekontingent nähert. Weitere Hinweise zu Servicekontingenten für Fargate finden Sie unter [Service Quotas für Amazon EKS und Fargate anzeigen und verwalten](service-quotas.md). AWS Fargate veröffentlicht die folgenden Metriken im ` AWS/Usage` Namespace. | Metrik | Beschreibung | | --- | --- | | `ResourceCount` | Die Gesamtanzahl der angegebenen Ressourcen, die in Ihrem Konto ausgeführt werden. Die Ressource wird durch die Dimensionen definiert, die der Metrik zugeordnet sind. | Die folgenden Dimensionen werden verwendet, um die von AWS Fargate veröffentlichten Nutzungsmetriken zu verfeinern. | Dimension | Description | | --- | --- | | `Service` | Der Name des AWS Dienstes, der die Ressource enthält. Für AWS Fargate-Nutzungsmetriken ist `Fargate` der Wert für diese Dimension. | | `Type` | Der Typ der Entität, die gemeldet wird. Derzeit ist der einzig gültige Wert für AWS Fargate-Nutzungsmetriken. `Resource` | | `Resource` | Der Typ der Ressource, die ausgeführt wird. Derzeit gibt AWS Fargate Informationen zu Ihrer Fargate On-Demand-Nutzung zurück. Der Ressourcenwert für Fargate On-Demand-Nutzung ist `OnDemand`. [HINWEIS] ==== Die Fargate On-Demand-Nutzung kombiniert Amazon-EKS-Pods mit Fargate, Amazon-ECS-Aufgaben mit dem Fargate-Starttyp und Amazon-ECS-Aufgaben mithilfe des `FARGATE`-Kapazitätsanbieters. ==== | | `Class` | Die Klasse der nachverfolgten Ressource. Derzeit verwendet AWS Fargate die Klassendimension nicht. | ### Einen CloudWatch Alarm zur Überwachung der Fargate-Ressourcennutzungsmetriken erstellen AWS Fargate stellt CloudWatch Nutzungsmetriken bereit, die den AWS Servicekontingenten für die Nutzung von Fargate On-Demand-Ressourcen entsprechen. In der Service-Quotas-Konsole können Sie Ihre Nutzung in einem Diagramm visualisieren. Sie können auch Alarme konfigurieren, die Sie warnen, wenn sich Ihre Nutzung einem Service Quotas nähert. Weitere Informationen finden Sie unter [Erfassen Sie die App- und Nutzungsmetriken von AWS Fargate](#monitoring-fargate-usage). Gehen Sie wie folgt vor, um einen CloudWatch Alarm auf der Grundlage der Fargate-Kennzahlen zur Ressourcennutzung zu erstellen. 1. Öffnen Sie die Service Quotas Quotas-Konsole unter https://console.aws.amazon.com/servicequotas/. 1. Wählen Sie im linken Navigationsbereich ** AWS Dienste** aus. 1. Suchen Sie in der ** AWS Serviceliste** nach ** AWS Fargate** und wählen Sie es aus. 1. Wählen Sie in der Liste **Service quotas** (Servicekontingente) das Fargate-Nutzungskontingent aus, für das Sie einen Alarm erstellen möchten. 1. Wählen Sie im Bereich CloudWatch Amazon-Alarme die Option **Erstellen** aus. 1. Wählen Sie bei **Alarmschwellenwert** den Prozentsatz des angewendeten Kontingentwerts aus, den Sie als Alarmwert festlegen möchten. 1. Geben Sie bei **Alarmname** einen Namen für den Alarm ein und wählen Sie dann **Erstellen** aus. # AWS-Fargate-Protokollierung für Ihren Cluster starten Amazon EKS auf Fargate bietet einen integrierten Log-Router basierend auf Fluent Bit. Dies bedeutet, dass Sie einen Fluent-Bit-Container nicht explizit als Sidecar ausführen, sondern Amazon für Sie ausführen. Alles, was Sie tun müssen, ist den Log-Router zu konfigurieren. Die Konfiguration erfolgt über ein dediziertes `ConfigMap`, das die folgenden Kriterien erfüllen muss: + Benannte `aws-logging` + Erstellt in einem dedizierten Namespace namens `aws-observability` + Mehr als 5 300 Zeichen sind nicht zulässig. Sobald Sie die `ConfigMap` erstellt haben, erkennt Amazon EKS in Fargate sie automatisch und konfiguriert den Protokollrouter damit. Fargate verwendet eine Version von AWS für Fluent Bit, eine Upstream-kompatible Distribution von Fluent Bit, die von AWS verwaltet wird. Weitere Informationen finden Sie unter [AWS für Fluent Bit auf](https://github.com/aws/aws-for-fluent-bit) GitHub. Mit dem Log-Router können Sie die Bandbreite der Services von AWS für Protokoll-Analysen und -Speicherung nutzen. Sie können Protokolle von Fargate direkt an Amazon CloudWatch, Amazon OpenSearch Service streamen. Außerdem können Sie Protokolle über [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/) an Ziele wie [Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) und Partner-Tools streamen. + Ein vorhandenes Fargate-Profil, das einen vorhandenen Kubernetes-Namespace angibt, in dem Sie Fargate-Pods bereitstellen. Weitere Informationen finden Sie unter [Schritt 3: Fargate Profil für Ihren Cluster erstellen](fargate-getting-started.md#fargate-gs-create-profile). + Eine vorhandene Fargate-Pod-Ausführungsrolle. Weitere Informationen finden Sie unter [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](fargate-getting-started.md#fargate-sg-pod-execution-role). ## Router-Konfiguration protokollieren **Wichtig** Damit Protokolle erfolgreich veröffentlicht werden können, muss von der VPC, in der sich Ihr Cluster befindet, Netzwerkzugriff auf das Protokollziel bestehen. Dies betrifft vor allem Benutzer, die Ausgangsregeln für ihre VPC anpassen. Ein Beispiel für die Verwendung von CloudWatch finden Sie unter [Verwendung von CloudWatch-Protokollen mit Schnittstellen-VPC-Endpunkten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) im *Benutzerhandbuch zu Amazon CloudWatch Logs*. Ersetzen Sie in den folgenden Schritten jedes *Beispielwert* durch Ihre eigenen Werte. 1. Erstellen Sie einen dedizierten Kubernetes-Namespace namens `aws-observability`. 1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen `aws-observability-namespace.yaml` auf Ihrem Computer. Der Wert für `name` muss `aws-observability` sein und das Label `aws-observability: enabled` ist erforderlich. ``` kind: Namespace apiVersion: v1 metadata: name: aws-observability labels: aws-observability: enabled ``` 1. Erstellen Sie den Namespace. ``` kubectl apply -f aws-observability-namespace.yaml ``` 1. Erstellen Sie ein `ConfigMap` mit einem `Fluent Conf`-Datenwert, um Container-Logs an ein Ziel zu versenden. Fluent Conf ist Fluent Bit, eine schnelle und leichte Konfigurationssprache für den Protokollprozessor, die verwendet wird, um Container-Protokolle an ein Protokollziel Ihrer Wahl weiterzuleiten. Weitere Informationen finden Sie unter [Konfigurationsdatei](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) in der Fluent-Bit-Dokumentation. **Wichtig** In einer typischen `Fluent Conf` sind die Hauptabschnitte `Service`, `Input`, `Filter` und `Output` enthalten. Der Fargate-Protokoll-Router akzeptiert jedoch nur: Die Abschnitte `Filter` und `Output`. Ein `Parser`-Abschnitt. Wenn Sie andere Abschnitte angeben, werden diese abgelehnt. Der Fargate-Protokollrouter verwaltet die Abschnitte `Service` und `Input`. Es verfügt über den folgenden Abschnitt `Input`, der nicht geändert werden kann und in Ihrem `ConfigMap` nicht benötigt wird. Sie können daraus jedoch Erkenntnisse gewinnen, z. B. die Speicherpuffergrenze und das für Protokolle angewendete Tag. ``` [INPUT] Name tail Buffer_Max_Size 66KB DB /var/log/flb_kube.db Mem_Buf_Limit 45MB Path /var/log/containers/*.log Read_From_Head On Refresh_Interval 10 Rotate_Wait 30 Skip_Long_Lines On Tag kube.* ``` Berücksichtigen Sie beim Erstellen des `ConfigMap`, die folgenden Regeln, die Fargate verwendet, um Felder zu validieren: + `[FILTER]`, `[OUTPUT]`, und `[PARSER]` sollen unter jedem entsprechenden Schlüssel angegeben werden. `[FILTER]` muss beispielsweise unter `filters.conf` liegen. Sie können ein oder mehrere `[FILTER]` in der `filters.conf` haben. Die Abschnitte `[OUTPUT]` und `[PARSER]` sollten sich auch unter den entsprechenden Schlüssel befinden. Durch die Angabe mehrerer `[OUTPUT]`-Abschnitte können Sie Ihre Protokolle gleichzeitig an verschiedene Ziele weiterleiten. + Fargate validiert die erforderlichen Schlüssel für jeden Abschnitt. `Name` und `match`sind für jedes `[FILTER]` und `[OUTPUT]` erforderlich. `Name` und `format` werden jeweils für jeden `[PARSER]` benötigt. Bei den Schlüssel wird nicht zwischen Groß- und Kleinschreibung unterschieden. + Umgebungsvariablen wie `${ENV_VAR}` sind im `ConfigMap` nicht erlaubt. + Die Einrückung muss für die Direktive oder das Schlüssel-Wert-Paar innerhalb von `filters.conf`, `output.conf` und `parsers.conf` gleich sein. Schlüssel-Wert-Paare müssen stärker eingerückt werden als Direktiven. + Fargate validiert gegen die folgenden unterstützten Filter: `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify`, und `kubernetes`. + Fargate validiert mit der folgenden unterstützten Ausgabe: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs`, und `kinesis`. + Mindestens ein unterstütztes `Output`-Plugin muss im `ConfigMap` bereitgestellt werden, um die Protokollierung zu ermöglichen. `Filter` und `Parser` sind nicht erforderlich, um die Protokollierung zu aktivieren. Sie können Fluent Bit auch auf Amazon EC2 mit der gewünschten Konfiguration ausführen, um alle Probleme zu beheben, die sich aus der Validierung ergeben. Erstellen Sie Ihr `ConfigMap` mit einem der folgenden Beispiele. **Wichtig** Die Amazon-EKS-Fargate-Protokollierung unterstützt keine dynamische Konfiguration einer `ConfigMap`. Alle Änderungen an eine `ConfigMap` werden nur auf neue Pods angewendet. Änderungen werden nicht auf vorhandene Pods angewendet. Erstellen Sie anhand des Beispiels ein `ConfigMap` für Ihr gewünschtes Protokollziel. **Anmerkung** Sie können auch Amazon Kinesis Data Streams als Protokollziel verwenden. Stellen Sie bei der Nutzung von Kinesis Data Streams sicher, dass der Pod-Ausführungsrolle die Berechtigung `kinesis:PutRecords` erteilt wurde. Weitere Informationen finden Sie unter [Berechtigungen](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) für Amazon Kinesis Data Streams im offiziellen *Handbuch zu Fluent Bit*. **Example** ------ #### [ CloudWatch ] Bei der Verwendung von CloudWatch haben Sie zwei Ausgabeoptionen: + [Ein Ausgabe-Plug-In in C geschrieben](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) + [Ein in Golang geschriebenes Ausgabe-Plug-In](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) Das folgende Beispiel zeigt Ihnen, wie Sie das `cloudwatch_logs`-Plug-in verwenden, um Protokolle an CloudWatch zu senden. 1. Speichern Sie den folgenden Inhalt in einer Datei namens `aws-logging-cloudwatch-configmap.yaml`. Ersetzen Sie den *region-code* durch die AWS-Region, in der sich Ihr Cluster befindet. Die Parameter unter `[OUTPUT]` sind erforderlich. ``` kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch. filters.conf: | [FILTER] Name parser Match * Key_name log Parser crio [FILTER] Name kubernetes Match kube.* Merge_Log On Keep_Log Off Buffer_Size 0 Kube_Meta_Cache_TTL 300s output.conf: | [OUTPUT] Name cloudwatch_logs Match kube.* region region-code log_group_name my-logs log_stream_prefix from-fluent-bit- log_retention_days 60 auto_create_group true parsers.conf: | [PARSER] Name crio Format Regex Regex ^(?