Fargate-Profile für serverlose Pods

AWS Fargate für EKS ermöglicht es Ihnen, Kubernetes-Pods auszuführen, ohne EC2-Nodes bereitzustellen oder zu verwalten. Statt sich mit Instance-Typen und Node-Gruppen zu befassen, definieren Sie ein Fargate-Profil, das anhand des Namespace und optionaler Label-Selektoren festlegt, welche Pods auf Fargate ausgeführt werden sollen. AWS stellt automatisch die passende Menge an Rechenleistung für jeden Pod bereit und beendet sie, wenn der Pod beendet wird.

Ein Fargate-Profil ist an einen EKS-Cluster angehängt und enthält einen oder mehrere Selektoren — jeder Selektor gibt einen Namespace sowie optionale Kubernetes-Label-Schlüssel-Wert-Paare an. Ein Pod muss mindestens einem Selektor entsprechen, damit er auf Fargate eingeplant werden kann. Das Profil gibt außerdem die Pod-Ausführungsrolle (eine IAM-Rolle) und die privaten Subnetze an, die Fargate zum Starten der Pods verwenden soll.

Die Pod-Ausführungsrolle ist eine IAM-Rolle, die EKS übernimmt, wenn Fargate Container-Images abruft und Pod-Logs an CloudWatch sendet. Sie muss die von AWS verwaltete Richtlinie AmazonEKSFargatePodExecutionRolePolicy enthalten. Ohne diese Rolle können auf Fargate eingeplante Pods nicht gestartet werden, da Fargate sich nicht bei ECR authentifizieren oder in CloudWatch Logs schreiben kann.

Fargate unterliegt wichtigen Namespace-Einschränkungen. Der Namespace kube-system ist für die meisten Fargate-Profile nicht zulässig, da dort System-Pods wie kube-proxy ausgeführt werden. Eine Ausnahme ist CoreDNS: AWS stellt einen geführten Prozess bereit, mit dem Sie das CoreDNS-Deployment patchen und die Annotation eks.amazonaws.com/compute-type: ec2 entfernen können, damit es auf Fargate ausgeführt werden kann. Pods in ausgeschlossenen Namespaces bleiben ungeplant, wenn keine EC2-Nodes verfügbar sind.

Fargate weist Rechenressourcen anhand der in der Pod-Spezifikation definierten CPU- und Speicheranforderungen zu. Die Werte werden auf die nächstgrößere von Fargate unterstützte vCPU-/Speicherkombination aufgerundet (beispielsweise von 0,25 vCPU / 0,5 GB bis zu 16 vCPU / 120 GB). Sie zahlen nur für die pro Sekunde zugewiesenen Ressourcen, während der Pod ausgeführt wird. Legen Sie immer genaue Ressourcenanforderungen fest — zu niedrige Anforderungen führen zu Beendigungen wegen Speichermangels, zu hohe Anforderungen erhöhen die Kosten.

Fargate macht die Node-Verwaltung überflüssig, unterliegt jedoch Einschränkungen: keine DaemonSets (da keine persistenten Nodes vorhanden sind, auf denen sie eingeplant werden könnten), keine privilegierten Container und eingeschränkte Unterstützung für bestimmte Speichertypen. EC2-Node-Gruppen unterstützen GPUs, benutzerdefinierte Kernel und zustandsbehaftete Workloads mit lokalen NVMe-Laufwerken. Ein häufig verwendetes Muster besteht darin, zustandslose Services auf Fargate und zustandsbehaftete oder GPU-Workloads auf dedizierten EC2-Node-Gruppen innerhalb desselben EKS-Clusters auszuführen.

Jeder Fargate-Pod erhält eine eigene elastische Netzwerkschnittstelle (ENI) und eine private IP-Adresse aus dem im Profil angegebenen Subnetz. Dadurch können Sie jedem Pod mithilfe der Funktion „Security Groups for Pods“ eine eigene Security Group zuweisen. Fargate-Pods unterstützen alle standardmäßigen VPC-Security-Group-Regeln und ermöglichen so eine fein abgestimmte Steuerung des eingehenden und ausgehenden Datenverkehrs auf Ebene einzelner Pods — ein erheblicher Sicherheitsvorteil gegenüber gemeinsam genutzten Security Groups auf Node-Ebene.

Fargate-Pods senden Logs mithilfe des integrierten Fluent-Bit-Log-Routers an Amazon CloudWatch Logs. Sie konfigurieren die Protokollierung, indem Sie eine ConfigMap namens aws-logging im Namespace aws-observability erstellen. Die Pod-Ausführungsrolle muss berechtigt sein, Log-Gruppen zu erstellen und Log-Ereignisse zu schreiben. Die Logs werden in CloudWatch nach Cluster und Namespace in Log-Gruppen organisiert, wodurch eine zentrale Log-Aggregation ohne einen separaten Log-Agenten unkompliziert möglich ist.

Fargate unterstützt den Kubernetes-Horizontal Pod Autoscaler (HPA). Wenn der HPA die Anzahl der Replikate erhöht, stellt Fargate automatisch neue Micro-VMs bereit, ohne dass Sie die Größe einer Node-Gruppe anpassen müssen. Dadurch entsteht eine echte serverlose Autoscaling-Erfahrung: Der HPA steuert die Anzahl der Pods, und Fargate übernimmt die elastische Bereitstellung der Rechenleistung. Im Cluster muss weiterhin der Metrics Server bereitgestellt sein, damit der HPA die CPU- und Speichernutzung auslesen kann.

Sie zahlen bei Fargate für die verbrauchten vCPU-Sekunden und GB-Sekunden, mit einer Mindestabrechnung von 1 Minute pro Pod. Es gibt keine Kosten auf Node-Ebene, Gebühren für reservierte Kapazität oder Kosten für AMI-/Betriebssystem-Patches. Fargate ist pro Recheneinheit typischerweise teurer als passend dimensionierte EC2-On-Demand-Instances, aber die Gesamtbetriebskosten sind oft niedriger, wenn Sie die eingesparte Entwicklungszeit für Node-Verwaltung, Patching und Skalierungsentscheidungen berücksichtigen.

Wichtige Fargate-Einschränkungen für die SAA-C03-Prüfung: keine DaemonSet-Unterstützung (Pods können nicht auf jedem Node platziert werden, da keine persistenten Nodes vorhanden sind), keine privilegierten Container, kein hostNetwork-Modus und ein auf 20 GB pro Pod begrenzter ephemerer Speicher (mit einer Konfiguration auf 200 GB erweiterbar). Persistenter Blockspeicher mit EBS wird nicht unterstützt — verwenden Sie EFS für gemeinsam genutzten persistenten Dateispeicher mit Fargate-Pods.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Fargate-Profile verwenden Namespace- und Label-Selektoren, um Pods serverlos einzuplanen, die Pod-Ausführungsrolle erteilt Fargate die Berechtigung, Images abzurufen und Logs zu schreiben, und Fargate unterstützt weder DaemonSets noch EBS — verwenden Sie EFS für persistenten Speicher. Als Nächstes sehen wir uns die EKS-Netzwerkfunktionen mit dem VPC-CNI-Plugin und dem AWS Load Balancer Controller an.