Die Kosten eines Kubernetes-Node-Pools sind die Summe der Stundenpreise seiner Nodes, und der Node-Pool ist die Einheit, in der ein Cluster Preisentscheidungen trifft: eine Maschinenfamilie, eine Größe, eine Kaufoption und ein Skalierungsbereich je Pool. Alles, was ein Pod kostet, leitet sich vom Preis des Nodes ab, auf dem er landet (was ein Pod kostet); die Wahl des Pools setzt diesen Preis. Diese Seite beschreibt, wie Familie und Größe den Preis je vCPU und je GiB bestimmen, was Bin Packing mit der Größe zu tun hat, warum ARM-Pools und getrennte System-Pools Kostenentscheidungen sind, und wie Taints und Affinity Pods in den richtigen Pool lenken.
So funktioniert es
Ein Node-Pool ist eine Gruppe von Nodes mit einem Instanztyp, einem Image und einem Skalierungsbereich; der Anbieter hält sie als Auto Scaling Group, Virtual Machine Scale Set oder verwaltete Instanzgruppe. Die Rechnung zeigt die Nodes als virtuelle Maschinen mit dem Stundenpreis ihres Typs, und nur über ein Tag oder Label lässt sich eine Instanz einem Pool und einem Cluster zuordnen. Drei Eigenschaften des Pools setzen den Preis.
Die Maschinenfamilie legt das Verhältnis von CPU, Arbeitsspeicher und Preis fest. Innerhalb einer Generation kostet eine speicheroptimierte Instanz mit derselben vCPU-Zahl mehr als eine allgemeine, weil sie viermal so viel Arbeitsspeicher trägt; eine rechenoptimierte kostet weniger und trägt die Hälfte. ARM-Instanzen (AWS Graviton, Azure Cobalt, Google Axion) derselben Klasse haben einen niedrigeren Stundenpreis bei gleicher vCPU-Zahl und setzen Container-Images für die Architektur voraus. Welche Familie zu einem Workload passt, entscheidet das Verhältnis seiner Requests: Ein Pool mit zu viel Arbeitsspeicher je vCPU bezahlt Speicher, den kein Pod anfordert.
Die Größe skaliert innerhalb einer Familie linear: Die doppelte Instanz kostet das Doppelte. Der Preis je vCPU ändert sich dadurch nicht, die Packung schon. Jeder Node reserviert Kapazität für Kubelet und Container-Runtime und trägt eine Kopie jedes DaemonSets (Logging, Monitoring, Netzwerk-Agent); auf kleinen Nodes wiegt dieser Fixanteil schwerer. Große Nodes lassen mehr Pods ohne Verschnitt zu, kleine Nodes lassen den Autoscaler in feineren Schritten abbauen. Ein Pod, der auf keinen Node passt, weil seine Requests die Allocatable-Kapazität jedes Typs übersteigen, erzwingt einen größeren Typ für den ganzen Pool.
Die Rolle trennt System von Workloads. AKS verlangt mindestens einen System-Node-Pool für kritische Systempods und empfiehlt, Workloads in User-Pools zu betreiben; GKE Standard hat einen Standard-Pool, EKS keine Rolle, aber dieselbe Praxis. Ein kleiner System-Pool mit fester Größe hält die Add-ons vom Autoscaling der Workloads fern.
Taints und Affinity sind die Kostenregeln zwischen den Pools. Ein Taint am Pool hält jeden Pod fern, der ihn nicht toleriert; so bleibt ein GPU-Pool oder ein Spot-Pool denen vorbehalten, die dafür vorgesehen sind. nodeSelector und Node Affinity ziehen Pods zu einem Pool hin, etwa nach Architektur (kubernetes.io/arch: arm64) oder Kapazitätstyp. Ohne diese Regeln verteilt der Scheduler Pods nach Platz, und ein teurer Pool füllt sich mit Pods, die auch auf dem günstigen gelaufen wären.
AWS
EKS kennt verwaltete Node-Gruppen mit einem oder mehreren Instanztypen; Karpenter und EKS Auto Mode ersetzen den statischen Pool durch einen NodePool mit Anforderungen (Familien, Größen, Architekturen, Kapazitätstyp), aus denen je wartendem Pod die günstigste passende Instanz gewählt wird. Auto Mode berechnet je gestarteter Instanz eine Verwaltungsgebühr nach Instanztyp zusätzlich zum EC2-Preis (EKS, ECS und Fargate).
Azure
AKS-Node-Pools sind Virtual Machine Scale Sets mit einer VM-Größe je Pool; ein Pool trägt den Modus System oder User, und Node Auto Provisioning wählt VM-Größen nach den Requests wartender Pods. Mit AKS Automatic kommt je vCPU und Stunde eine Gebühr nach VM-Kategorie hinzu.
Google Cloud
GKE Standard hat Node-Pools mit einem Maschinentyp je Pool, wahlweise mit automatisch erstellten Node-Pools für wartende Pods; Autopilot hat keine Pools, dort setzt die Compute-Klasse des Pods die Hardware, und abgerechnet werden Requests.
Was es für Ihre Kosten bedeutet
Der Node-Pool ist der Ort, an dem die Mehrzahl der Kubernetes-Kosten entschieden wird, bevor ein Pod läuft. Die Reihenfolge der Entscheidungen: zuerst das Verhältnis von CPU zu Arbeitsspeicher der Workloads messen und die Familie danach wählen; dann die Größe so, dass die typischen Pods ohne Verschnitt passen und ein DaemonSet-Satz nicht mehr als einen kleinen Anteil des Nodes belegt; dann die Architektur, wenn die Images für ARM gebaut werden können; dann die Kaufoption je Pool, Commitments für die Grundlast (Commitment-Strategie), Spot für das Unterbrechbare. Ein Pool, der mehrere Instanztypen zulässt, gibt dem Autoscaler und dem Spot-Markt Spielraum; ein Pool mit genau einem Typ ist leichter zu reservieren.
Was ein Pool kostet, ist in den Abrechnungsdaten nicht als Pool sichtbar, sondern als Instanzstunden mit Tags; Tags und Labels am Pool sind die Voraussetzung dafür, dass der Vergleich zweier Pools aus den Daten möglich ist. Die Effizienz eines Pools, also Requests gegen Allocatable, behandelt Kubernetes-Effizienz; die Zahl der Nodes im Pool setzt der Node-Autoscaler.
Wo es schiefgeht
- Teurer Pool voll, günstiger leer. Symptom: Der GPU- oder speicheroptimierte Pool skaliert hoch, obwohl die Pods darauf keine GPU oder keinen großen Arbeitsspeicher anfordern. Ursache: Dem Pool fehlt ein Taint, und der Scheduler nimmt den Platz, den er findet.
- Speicher bezahlt, den niemand anfordert. Symptom: Die Nodes sind nach CPU voll und nach Arbeitsspeicher halb leer. Ursache: Die Familie trägt mehr GiB je vCPU als die Requests der Workloads; eine rechenoptimierte oder allgemeine Familie passt besser.
- Kleine Nodes, großer Fixanteil. Symptom: Ein nennenswerter Teil jedes Nodes ist belegt, bevor der erste Workload-Pod läuft. Ursache: Kube-Reserved und ein DaemonSet-Satz je Node wiegen auf einer Instanz mit zwei vCPU schwer.
- Pod passt auf keinen Node. Symptom: Ein Pod bleibt
Pending, obwohl der Pool skalieren darf. Ursache: Seine Requests übersteigen die Allocatable-Kapazität des einzigen Instanztyps im Pool. - ARM-Pool ohne Images. Symptom: Pods auf dem ARM-Pool scheitern mit
exec format error. Ursache: Die Images sind nur für x86 gebaut; ohne Multi-Arch-Images bleibt der günstigere Pool ungenutzt. - System-Pool skaliert mit. Symptom: Add-ons werden bei jedem Scale-down verschoben und starten neu. Ursache: Systempods laufen im Workload-Pool; ein eigener System-Pool mit fester Größe hält sie stabil.
Beispiel
Listenpreise, gelesen am 2026-10-21 aus der AWS-Preisliste für Frankfurt (eu-central-1), On-Demand, Linux: m6i.large (2 vCPU, 8 GiB) 0,115 USD, m6i.2xlarge (8 vCPU, 32 GiB) 0,46 USD, m7g.large (2 vCPU, 8 GiB, Graviton) 0,0978 USD, c6i.large (2 vCPU, 4 GiB) 0,097 USD, r6i.large (2 vCPU, 16 GiB) 0,152 USD je Stunde.
Vier m6i.large kosten 4 × 0,115 = 0,46 USD je Stunde, genau so viel wie eine m6i.2xlarge: Die Größe ändert den Preis je vCPU nicht. Läuft ein DaemonSet-Satz mit 200 Millicores je Node, belegt er auf den vier kleinen Nodes 800 Millicores von 8 vCPU, auf dem großen 200 Millicores. Derselbe Pool aus vier m7g.large kostet 4 × 0,0978 = 0,3912 USD je Stunde, also 0,0688 USD weniger, im Monat mit 730 Stunden 50,22 USD je vier Nodes. Je vCPU-Stunde kostet die c6i.large 0,0485 USD, die m6i.large 0,0575 USD und die r6i.large 0,076 USD; was die Familie teurer macht, ist der Arbeitsspeicher, den sie je vCPU mitbringt.
Quellen
Gelesen am 2026-10-21. AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1, AWS Verwaltete Node-Gruppen, Karpenter NodePools, AWS EKS Auto Mode, Microsoft System- und User-Node-Pools in AKS und Node Auto Provisioning, Google Cloud Node-Pools und Compute-Klassen in Autopilot, Kubernetes Pods zu Nodes zuweisen, Taints und Tolerations und Rechenressourcen für System-Daemons reservieren.