EKS Auto Mode NodeClass konfigurieren: Kubelet, Sysctls und Hugepages ohne Launch Template

Das Tuning-Vakuum: Warum Platform-Teams bisher ausweichen mussten

Wer EKS Auto Mode eingeführt hat, kennt das Versprechen: AWS übernimmt Provisioning, Patching und Upgrades der Nodes, das Team konzentriert sich auf die Workloads. In der Praxis stieß dieses Modell schnell an eine Grenze. Sobald eine Anwendung spezifische Node-Parameter brauchte – ein erhöhtes net.core.somaxconn für einen Message-Broker, vorab reservierte Hugepages für eine In-Memory-Datenbank, angepasste Eviction-Schwellwerte für einen Cluster mit vielen kleinen Pods – blieb nur ein Ausweg: zurück zu Managed Node Groups mit eigenem EC2 Launch Template oder einem Custom AMI. Beides bedeutet, dass das Team wieder Verantwortung für AMI-Builds, Bootstrap-Skripte und Upgrade-Koordination übernimmt – genau das, was Auto Mode eigentlich abnehmen sollte.

Seit dem 1. Oktober 2026 gibt es dafür eine andere Antwort. AWS hat das advancedCompute-Feld in der NodeClass-Ressource von EKS Auto Mode allgemein verfügbar gemacht. Damit lässt sich EKS Auto Mode NodeClass konfigurieren – mit Kubelet-Einstellungen, Linux-Kernel-Sysctls und Hugepages – direkt über die Kubernetes API, ohne ein einziges EC2 Launch Template, Custom AMI oder privilegiertes DaemonSet.

Was advancedCompute konkret ermöglicht

Das neue Feld gliedert sich in drei Unterbereiche, die unabhängig voneinander oder kombiniert gesetzt werden können:

• advancedCompute.kubelet – Überschreibt Kubelet-Einstellungen auf den Nodes der NodeClass: Pod-Dichte, Eviction-Schwellwerte, Container-Log-Rotation und OOM-Verhalten.
• advancedCompute.kernel.sysctl – Setzt Linux-Kernel-Sysctls beim Node-Boot. Die Property-Namen entsprechen exakt den Kernel-Sysctl-Namen, also etwa vm.swappiness oder net.core.somaxconn.
• advancedCompute.hugepages – Reserviert 2-MiB- oder 1-GiB-Hugepages vorab auf dem Node, bevor Kubernetes startet.

Hinzu kommt die Möglichkeit, User Namespaces für rootlose Container-Builds in CI/CD-Pipelines zu konfigurieren. AWS wendet alle Einstellungen beim Node-Boot an, validiert sie vorher und erhält sie durch Scaling- und Upgrade-Events. Wer also eine NodeClass mit einem erhöhten net.core.somaxconn deployed, bekommt diesen Wert auf jedem neuen Node dieser Klasse – auch nach einem automatischen Upgrade.

Eine wichtige Konsequenz: Wenn ein Sysctl auf einer bestehenden NodeClass geändert wird, beginnt EKS Auto Mode damit, die betroffenen Nodes zu ersetzen, damit der neue Wert wirksam wird. Das ist gewünschtes Verhalten und ein Grund, Sysctl-Änderungen mit denselben Vorsichtsmaßnahmen zu behandeln wie AMI-Updates: Pod Disruption Budgets prüfen, Rollout beobachten.

Kubelet-Einstellungen: Eviction, Log-Rotation, Pod-Dichte

Die häufigsten Gründe, warum Teams bisher ein Launch Template brauchten, waren Kubelet-Parameter. Ein Cluster mit vielen kleinen Pods läuft schnell in Disk-Pressure-Situationen, wenn die Standard-Eviction-Schwellwerte nicht zur tatsächlichen Workload passen. Container-Log-Rotation ist ein weiteres Thema: Ohne angepasste Limits können einzelne Container den ephemeren Speicher eines Nodes vollschreiben, bevor der Eviction-Mechanismus greift.

Mit advancedCompute.kubelet lassen sich diese Parameter jetzt direkt in der NodeClass setzen. Ein vereinfachtes Beispiel:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: high-density
spec:
  advancedCompute:
    kubelet:
      evictionHard:
        memory.available: "200Mi"
        nodefs.available: "10%"
      containerLogMaxSize: "50Mi"
      containerLogMaxFiles: 5
      maxPods: 110

EKS wendet diese Werte beim Node-Boot an. Die Kubernetes-Dokumentation zu KubeletConfiguration bleibt die Referenz für alle unterstützten Felder – AWS überschreibt nur die Werte, die explizit im advancedCompute.kubelet-Block gesetzt sind; alle anderen behalten die EKS-Auto-Mode-Defaults.

EKS Auto Mode Hugepages für HPC- und Datenbank-Workloads

Hugepages sind für Workloads relevant, die große zusammenhängende Speicherbereiche brauchen: In-Memory-Datenbanken, HPC-Anwendungen, latenzempfindliche Netzwerk-Stacks. Statt der Standard-4-KiB-Seiten reserviert der Linux-Kernel dabei 2-MiB- oder 1-GiB-Blöcke, was TLB-Misses reduziert und den Speicherdurchsatz verbessert. Wie stark der Effekt ausfällt, hängt stark von der Workload ab – pauschale Zahlen wären hier irreführend.

Bisher musste man Hugepages über preBootstrapCommands in einer eksctl-Konfiguration oder über ein Launch Template setzen – beides außerhalb des Kubernetes-API-Pfads und damit schwerer zu versionieren und zu auditieren. Mit advancedCompute.hugepages geht das jetzt deklarativ:

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: database-nodes
spec:
  advancedCompute:
    hugepages:
      hugepages-2Mi: "4Gi"
      hugepages-1Gi: "0"

EKS Auto Mode reserviert die Hugepages vor dem Kubelet-Start. Der Node meldet sie anschließend als allocatable Resource, sodass Pods sie über das übliche resources.requests-Feld anfordern können. Für 2-MiB-Hugepages und 1-GiB-Hugepages können beide Größen gleichzeitig konfiguriert werden.

Für Kernel-Tuning – etwa das Erhöhen von net.core.somaxconn für einen Message-Broker oder das Anpassen von vm.swappiness – nutzt man das advancedCompute.kernel.sysctl-Feld. Die Property-Namen entsprechen exakt den Kernel-Sysctl-Namen, was die Konfiguration direkt lesbar macht.

Kubernetes Node Tuning in EKS: Was advancedCompute nicht löst

advancedCompute schließt eine echte Lücke – aber es ist kein Freifahrtschein für beliebige Node-Anpassungen. EKS Auto Mode hat strukturelle Grenzen, die das neue Feature nicht aufhebt:

• Bottlerocket only. Auto Mode Nodes laufen ausschließlich auf Bottlerocket-AMIs. Amazon Linux 2, Ubuntu oder Windows sind nicht unterstützt. Wer ein Custom AMI braucht – etwa für Compliance-Anforderungen, die AMI-Pinning vorschreiben, oder für air-gapped Setups – muss weiterhin auf Managed Node Groups ausweichen.
• Kein SSH- und kein IMDS-Zugriff. Auto Mode Nodes sind immutable. Es gibt keinen direkten Zugriff auf den Node über SSH oder den Instance Metadata Service. Debugging läuft über Kubernetes-native Werkzeuge.
• 21-Tage-Node-Lebensdauer. AWS ersetzt Nodes spätestens nach 21 Tagen automatisch. Workloads müssen diese Rotation tolerieren – Pod Disruption Budgets sind hier keine Empfehlung, sondern Pflicht.
• Management Fee. EKS Auto Mode berechnet neben den üblichen EC2-Kosten eine zusätzliche Management-Gebühr für Auto-Mode-verwaltete Nodes. Für Cluster, die ohnehin schon Karpenter selbst betreiben, lohnt sich ein Kostenvergleich, bevor man migriert.

Wer diese Grenzen kennt und akzeptiert, bekommt mit advancedCompute einen deutlich kürzeren Weg zu produktionsreifen Node-Konfigurationen. Wer sie nicht akzeptieren kann, ist mit Standard-EKS plus selbst verwaltetem Karpenter besser bedient – und sollte sich den Beitrag zu EKS Capabilities mit Argo CD, ACK und kro ansehen, der zeigt, wie weit das verwaltete Modell inzwischen reicht.

EKS Auto Mode NodeClass konfigurieren: Wann lohnt sich der Wechsel?

advancedCompute macht EKS Auto Mode für eine Klasse von Workloads attraktiv, die bisher außen vor blieb: Datenbanken mit Hugepage-Bedarf, Cluster mit hoher Pod-Dichte, CI/CD-Pipelines mit rootlosen Builds. Wenn Ihr Team heute Managed Node Groups mit Launch Templates betreibt, ausschließlich um Kubelet-Parameter oder Sysctls zu setzen, ist jetzt der richtige Zeitpunkt, den Wechsel zu evaluieren.

Der konkrete nächste Schritt: Prüfen Sie, welche Ihrer bestehenden Launch-Template-Konfigurationen sich auf Kubelet-Einstellungen, Sysctls oder Hugepages beschränken. Für diese Node Groups lässt sich eine NodeClass mit advancedCompute direkt als Ersatz bauen – und damit die Upgrade-Verantwortung für diese Nodes an AWS zurückgeben. Für Node Groups, die ein Custom AMI oder direkten Node-Zugriff benötigen, bleibt das bisherige Modell die richtige Wahl.

Wie ein solcher Migrationspfad konkret aussieht und welche Fallstricke beim Wechsel von Karpenter zu EKS Auto Mode auftreten können, haben wir im Beitrag zu EKS Version Rollback am Beispiel von Upgrade-Strategien beschrieben.

Quellen: AWS What's New: Amazon EKS Auto Mode now supports advanced compute configuration (1. Oktober 2026); AWS Dokumentation: Create a Node Class for Amazon EKS; AWS Dokumentation: Automate cluster infrastructure with EKS Auto Mode (April 2026).