Vereinfachen Sie die 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 auf Fargate ausgeführt werden, werden nur in privaten Subnetzen unterstützt (mit NAT-Gateway-Zugriff auf AWS Dienste, aber nicht mit direkter Route zu einem Internet Gateway). Daher muss die VPC Ihres Clusters über private Subnetze verfügen. 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. Dazu gehört die AWS Region oder Availability Zone, in der ein Pod bereitgestellt wird.

Du kannst Fargate-Pods nicht in AWS Outposts, AWS Wellenlängenzonen oder AWS Local Zones einsetzen.

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 auf Fargate-Knoten ausführen, aber der Amazon EBS CSI-Knoten DaemonSet kann nur auf Amazon EC2 EC2-Instances ausgeführt werden.

Versions-Rollback: Das Versions-Rollback wird für Fargate-Worker-Knoten nicht unterstützt. Sie können die Steuerungsebene eines Clusters, der Fargate verwendet, rückgängig machen, aber Fargate-Pods, auf denen dieselbe Kubernetes-Version wie die Kontrollebene ausgeführt wird, lösen eine verzerrte Kubelet-Version mit dem Status ERROR aus. Wenn Sie Fargate-Pods mit einer Nebenversion haben, die der Version auf der Kontrollebene entspricht, löschen Sie diese Pods, bevor Sie ein Rollback durchführen. Führen Sie dann ein Rollback Ihrer Kontrollebene durch. Alle verbleibenden Pods werden mit der Rollback-Version gestartet, wenn Sie sie erneut bereitstellen. Sie können diese Option auch verwenden, --force um die Insight-Prüfung zu umgehen. Wenn Sie jedoch mit einem Verstoß gegen die Kubelet-Version fortfahren, kann dies zu unerwartetem Verhalten führen. Weitere Informationen finden Sie unter Rollback des Clusters auf vorherige Kubernetes-Version.

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