AWS Fargate

Jeder Pod, der auf Fargate ausgeführt wird, hat seine eigene Isolationsgrenze. Sie teilen sich den zugrunde liegenden Kernel, die CPU-Ressourcen, die Arbeitsspeicherressourcen oder die Elastic-Network-Schnittstelle nicht mit einem anderen Pod.

Network Load Balancer und Application Load Balancer (ALBs) können mit Fargate nur mit IP-Zielen verwendet werden. Weitere Informationen finden Sie unter Erstellen eines Network Load Balancers und Application Load Balancing auf Amazon EKS.

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 auf Fargate ausgeführt werden sollen, mit einem Fargate-Profil übereinstimmen. Pods, die nicht mit einem Fargate-Profil übereinstimmen, können als Pending stecken 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 auf Fargate ausgeführt werden, können im HostPort-Manifest kein HostNetwork oder Pod angeben.

Das standardmäßige weiche nofile- und nproc-Limit beträgt 1024 und das harte Limit 65535 für Fargate-Pods.

GPUs sind derzeit auf Fargate nicht verfügbar.

Pods, die auf 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 Anforderungen an private Cluster.

Sie können Vertical Pod Autoscaler verwenden, um die CPU und den Speicher für Ihre Fargate-Pods anfänglich richtig zu dimensionieren, und dann Horizontal Pod Autoscaler 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 fügt defense-in-depth für Kubernetes Anwendungen hinzu, 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. Dies 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.

Der Amazon EC2 Instance Metadata Service (IMDS) ist für Pods nicht verfügbar, die auf Fargate-Knoten bereitgestellt werden. Wenn Sie Pods haben, die in Fargate bereitgestellt werden und die IAM-Anmeldeinformationen benötigen, weisen Sie sie Ihren Pods mit 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ören die AWS-Region oder Availability Zone, in der ein bereitgestellt Pod wird.

Sie können Fargate nicht Pods in AWS Outposts AWS Wavelength, oder AWS Local Zones bereitstellen.

Amazon EKS muss Fargate Pods regelmäßig patchen, damit diese sicher bleiben. Wir versuchen, die Auswirkungen von Updates möglichst gering zu halten. Es kann jedoch vorkommen, dass Pods gelöscht werden müssen, wenn sie nicht erfolgreich entfernt wurden. Es gibt einige Maßnahmen, die Sie durchführen können, um Unterbrechungen zu minimieren. Weitere Informationen finden Sie unter Betriebssystem-Patching für Fargate.

Das Amazon-VPC-CNI-Plugin für Amazon EKS ist standardmäßig auf Fargate-Knoten installiert. Sie können Alternative kompatible CNI-Plugins nicht mit Fargate-Knoten verwenden.

Ein Pod, der in Fargate ausgeführt wird, mountet automatisch ein Amazon-EFS-Dateisystem. Sie können die dynamische Bereitstellung von persistenten Volumes nicht mit Fargate-Knoten verwenden, aber Sie können die statische Bereitstellung verwenden.

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-Instances ausgeführt werden.

Nachdem ein Kubernetes-Job als Completed oder Failed gekennzeichnet wurde, existieren die vom Job erstellten Pods normalerweise weiter. Durch dieses Verhalten können Sie die Protokolle und Ergebnisse anzeigen. Bei Fargate entstehen jedoch Kosten, wenn Sie den Job nachher nicht bereinigen.

Um das zugehörige automatisch zu löschen, Pods nachdem ein Job abgeschlossen ist oder fehlschlägt, können Sie mithilfe des time-to-live (TTL)-Controllers einen Zeitraum angeben. Das folgende Beispiel veranschaulicht die Angabe von .spec.ttlSecondsAfterFinished im Job-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