Vereinfachung der Rechenverwaltung mit AWS Fargate

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 und Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten.

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.

Sie können die Option Pod-Ressourcen mit Vertical Pod Autoscaler anpassen 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 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-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.

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. 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.

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 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.

Das Amazon-VPC-CNI-Plugin für Amazon EKS ist standardmäßig auf Fargate-Knoten installiert. Sie können keine Alternativen CNI-Plugins für Amazon-EKS-Cluster 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 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