VPC CNI mit Prefix Delegation in EKS: So sparen Sie bis zu 75 % bei ungenutzten Knoten

In Kubernetes-Clustern auf Amazon EKS kommt es häufig zu einer unnötigen Verschwendung von Ressourcen: Ein Knoten mit zwei vCPUs und acht GiB RAM zeigt eine Auslastung von nur 18 % CPU und 22 % Speicher, während gleichzeitig keine weiteren Pods mehr geplant werden können. Der Grund? Die Standardkonfiguration des Amazon VPC CNI-Plugins begrenzt die Anzahl der Pods pro Knoten über die verfügbaren Secondary IPs der EC2-Instanz – ein Problem, das viele Administratoren vor teure Überraschungen stellt.

Doch es gibt eine Lösung: Prefix Delegation ermöglicht es dem VPC CNI, nicht nur einzelne IPs, sondern ganze IP-Blöcke zuzuweisen. Dadurch lässt sich die maximale Pod-Anzahl pro Knoten deutlich steigern – und das bei gleichbleibenden EC2-Kosten. Wie das funktioniert und worauf Sie achten müssen, erfahren Sie in diesem Artikel.

Warum Standard-EKS-Knoten oft ungenutzt bleiben

Jeder EKS-Knoten ist technisch gesehen eine EC2-Instanz, der Elastic Network Interfaces (ENIs) zugewiesen werden. Jede ENI bietet dabei eine primäre IP-Adresse für den Knoten selbst sowie mehrere Secondary IPs für die Pods. Das VPC CNI-Plugin ist für die Zuweisung dieser IPs verantwortlich und folgt dabei einer festen Formel zur Berechnung der maximalen Pod-Anzahl pro Knoten:

MaxPods pro Knoten = ENIs × (IPs pro ENI − 1) + 2

Dabei gelten folgende Einschränkungen:

• Die Anzahl der ENIs und Secondary IPs pro Instanz ist je nach EC2-Typ begrenzt (siehe AWS-Dokumentation).
• Die zwei zusätzlichen Pods dienen typischerweise für kube-proxy und das aws-node-DaemonSet.

Ein konkretes Beispiel: Die Instanz m5.large unterstützt maximal 29 Pods. Bei einer Auslastung von nur 100 Millicores CPU und 256 MiB RAM pro Pod bedeutet das, dass der Knoten trotz ausreichender Ressourcen keine weiteren Workloads aufnehmen kann. Die Konsequenz? Der Auto-Scaler startet zusätzliche Knoten – und die Kosten steigen.

Prefix Delegation: Mehr Pods mit weniger IPs

Die Lösung liegt in der Aktivierung von Prefix Delegation, einer Konfigurationsoption des VPC CNI-Plugins. Statt einzelne Secondary IPs zuzuweisen, fordert das Plugin nun /28-IP-Blöcke an – also Gruppen von 16 zusammenhängenden IPs. Pro ENI erhöht sich die Anzahl der verfügbaren Pod-IPs dadurch um den Faktor 16.

Die neue Formel zur Berechnung der maximalen Pod-Anzahl lautet nun:

MaxPods pro Knoten = ENIs × ((IPs pro ENI − 1) × 16) + 2

Für die m5.large ergibt sich damit eine theoretische Obergrenze von 434 Pods. Allerdings greifen hier zusätzliche Kubernetes-spezifische Limits, die eine realistische Obergrenze setzen.

So aktivieren Sie Prefix Delegation

Die Aktivierung erfolgt über eine Umgebungsvariable im VPC CNI-Addon. Fügen Sie folgende Konfiguration hinzu:

{
  "env": {
    "ENABLE_PREFIX_DELEGATION": "true",
    "WARM_PREFIX_TARGET": "1"
  }
}

Wichtig: Diese Einstellung allein reicht nicht aus. Der kubelet-Prozess auf jedem Knoten muss ebenfalls über die neuen Limits informiert werden, da Kubernetes die Pod-Anzahl standardmäßig weiterhin nach der alten Formel berechnet.

Die Rolle von kubelet und Auto-Scaling-Tools

Damit Prefix Delegation ihre Wirkung entfaltet, müssen Sie sicherstellen, dass kubelet die neuen Kapazitäten erkennt. Andernfalls erhalten Sie Fehlermeldungen wie:

„Too many pods, 0/N nodes are available“ – obwohl IPs verfügbar sind.

Konfiguration bei Karpenter

Karpenter verwendet standardmäßig --use-max-pods=false und setzt eine feste Obergrenze von 110 Pods pro Knoten – ohne automatische Anpassung an die Instanzgröße. Um die volle Leistung von Prefix Delegation auszuschöpfen, passen Sie die NodePool-Konfiguration an:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      kubelet:
        maxPods: 110  # Hier auf die tatsächliche Kapazität anpassen

Hintergrund: Der von AWS bereitgestellte max-pods-calculator.sh berücksichtigt Prefix Delegation noch nicht. Karpenter verlässt sich daher auf konservative Defaults.

Managed Node Groups anpassen

Bei Managed Node Groups müssen Sie die Bootstrap-Skripts des EKS-Clusters anpassen. Fügen Sie folgende Parameter hinzu:

/etc/eks/bootstrap.sh my-cluster \
  --use-max-pods false \
  --kubelet-extra-args '--max-pods=110'

Kubernetes-spezifische Limits beachten

Nicht jede Pod-Anzahl ist sinnvoll – Kubernetes selbst setzt Grenzen, um die Stabilität des Clusters zu gewährleisten. Die offizielle Empfehlung lautet:

maxPods = min(110, 10 × Anzahl der CPU-Kerne pro Knoten)

Für eine m5.large mit zwei vCPUs ergibt sich damit ein Maximum von 20 Pods. In der Praxis wird daher empfohlen, den Wert auf 110 zu setzen, sofern die Ressourcen des Knotens dies zulassen.

Vergleich der Pod-Kapazitäten

Nach der Aktivierung von Prefix Delegation ergeben sich folgende realistischen Obergrenzen pro EC2-Typ:

| Instanz | vCPUs | RAM (GiB) | ENIs | Max Pods (Standard) | Max Pods (Prefix Delegation) | |---------|-------|-----------|------|---------------------|------------------------------| | m5.large | 2 | 8 | 3 | 29 | 110 | | m5.xlarge | 4 | 16 | 4 | 58 | 110 | | m5.2xlarge | 8 | 32 | 4 | 58 | 110 | | m5.4xlarge | 16 | 64 | 8 | 234 | 110 | | m5.8xlarge | 32 | 128 | 8 | 234 | 250 | | m5.12xlarge | 48 | 192 | 8 | 234 | 250 | | m5.16xlarge | 64 | 256 | 15 | 737 | 250 | | m5.24xlarge | 96 | 384 | 15 | 737 | 250 |

Wann Prefix Delegation nicht die richtige Wahl ist

Trotz der offensichtlichen Vorteile gibt es Szenarien, in denen Prefix Delegation nicht sinnvoll ist:

• Große Pods: Workloads mit mehr als einer vCPU oder über zwei GiB RAM belasten die CPU oder den Speicher des Knotens stärker als das Netzwerk. Hier bringt die höhere Pod-Dichte keinen Kostenvorteil.
• Hohe Netzwerklast: Wenn Pods intensiv mit externen Diensten kommunizieren, kann die erhöhte Pod-Dichte zu mehr Netzwerkverkehr pro Knoten führen – ein potenzielles Bottleneck.
• VPC-Beschränkungen: In sehr kleinen VPCs mit begrenzten IP-Ranges können /28-Blöcke zu schnell erschöpft sein.

Fazit: Kostensenkung mit Prefix Delegation

Prefix Delegation im VPC CNI-Plugin von AWS bietet eine einfache, aber wirkungsvolle Methode, um die Effizienz von EKS-Knoten zu steigern. Durch die Erhöhung der Pod-Dichte pro Instanz lassen sich EC2-Kosten um bis zu 75 % reduzieren – ohne Änderungen am Anwendungscode. Wichtig ist jedoch, die neuen Limits korrekt zu konfigurieren und die Kubernetes-spezifischen Einschränkungen zu beachten. Für Teams, die ihre EKS-Clusterkosten optimieren möchten, ist Prefix Delegation eine unverzichtbare Technologie.

In Zukunft könnte AWS die automatische Erkennung von Prefix Delegation in Tools wie Karpenter oder Managed Node Groups integrieren. Bis dahin lohnt es sich, die Konfiguration manuell vorzunehmen und die Auswirkungen auf die Cluster-Performance genau zu überwachen.