Kubernetes-Spot-Instanzen sind Nodes aus der freien Kapazität des Anbieters, die er zu einem niedrigeren, veränderlichen Preis vergibt und jederzeit zurückholen kann; in einem Cluster werden sie zu einem eigenen Node-Pool mit Taint, auf dem nur Workloads laufen, die eine Unterbrechung vertragen. Der Preis ist bekannt, das Risiko ist die Unterbrechung, und beides erscheint in den Abrechnungsdaten anders als On-Demand-Kapazität. Diese Seite beschreibt, welche Workloads sich eignen, wie Unterbrechungen behandelt werden, wie gemischte Pools mit Rückfall auf On-Demand aufgebaut sind, wie Spot-Preise je Anbieter in den Daten stehen, und was ein Spot-Pool spart und riskiert. Die Kaufoption selbst, ihre Preisbildung und ihre Grenzen bei allen drei Anbietern erklärt Spot- und Preemptible-Kapazität; hier geht es um den Cluster.

So funktioniert es

Ein Spot-Node ist eine gewöhnliche virtuelle Maschine mit einer anderen Kaufoption. Der Anbieter nimmt sie zurück, wenn er die Kapazität braucht, mit einer kurzen Vorwarnung: AWS meldet eine Unterbrechung zwei Minuten vorher als EventBridge-Ereignis und in den Instanzmetadaten, und kann davor eine Rebalance-Empfehlung senden; Azure entzieht Spot-VMs nach Kapazität oder nach dem gesetzten Höchstpreis; GKE gibt den Pods eines Spot-Nodes standardmäßig 30 Sekunden zum Herunterfahren. In dieser Zeit muss der Node cordoned und gedrained werden, damit Pods geordnet enden und der Scheduler sie neu platziert. Auf EKS übernimmt das Karpenter über eine SQS-Warteschlange mit den Unterbrechungsereignissen oder der AWS Node Termination Handler als DaemonSet; EKS Auto Mode behandelt die Ereignisse selbst. AKS und GKE drainen den Node vor der Verdrängung.

Geeignet sind Workloads, die eine Unterbrechung ohne Datenverlust überstehen und deren Neustart die Nutzer nicht spüren: Batch-Jobs mit Checkpoints, Warteschlangen-Worker, CI-Runner, zustandslose Replikas hinter einem Load Balancer, Entwicklungsumgebungen. Ungeeignet sind Datenbanken, Controller mit einer Replika, Pods mit lokalem Speicher und alles, dessen Startzeit die Vorwarnung übersteigt. Ein PodDisruptionBudget schützt beim Drain, aber nicht vor dem Entzug des Nodes nach Ablauf der Frist.

Ein Spot-Pool bekommt einen Taint, damit nur Pods mit passender Toleration darauf landen, und ein Label für die Node Affinity: AKS setzt kubernetes.azure.com/scalesetpriority=spot:NoSchedule, GKE cloud.google.com/gke-spot=true als Label und bei automatisch erstellten Pools als Taint, Karpenter unterscheidet mit karpenter.sh/capacity-type: spot oder on-demand. Gemischte Pools mindern das Risiko: Ein NodePool, der viele Instanztypen und mehrere Zonen zulässt, findet eher Kapazität, und ein On-Demand-Pool als Rückfall nimmt die Pods auf, wenn Spot-Kapazität fehlt; Karpenter bevorzugt Spot und weicht auf On-Demand aus, wenn der NodePool beides erlaubt, und die Konsolidierung löscht Spot-Nodes standardmäßig, ersetzt sie aber nur mit dem Feature-Flag SpotToSpotConsolidation durch günstigere (Cluster Autoscaler, Karpenter und Node-Provisioning).

der Anbieter brauchtdie Kapazitätja: viele Typen undZonen erlaubtneinEin Pod mit Spot-Tolerationund -AffinityEin Node im Spot-PoolDie Ankündigung: zwei Minuten bei AWS,30 Sekunden bei GKE, eineVerdrängung bei AzureCordon und Drain: Pods endensauber innerhalb des FenstersSpot-Kapazitätanderswo?Auf einem anderenSpot-Node neu geplantDer On-Demand-Rückfallpool,zum vollen Preis
Ein Spot-Pool ist nur über seinen Taint erreichbar, und nimmt der Anbieter einen Node zurück, ist das Ankündigungsfenster das, was die Pods entleert und auf einen anderen Spot-Node oder den On-Demand-Rückfall bringt

AWS

Der Spot-Preis je Instanztyp und Availability Zone ändert sich mit Angebot und Nachfrage; im Cost and Usage Report stehen Spot-Nodes unter Amazon EC2 mit Usage Types wie EUC1-SpotUsage:m6i.large zum Preis der jeweiligen Stunde. Unterbricht AWS eine Linux-Instanz in ihrer ersten Stunde, kostet sie nichts; danach werden die genutzten Sekunden berechnet, und wer selbst beendet, zahlt die Sekunden immer. EKS-Managed-Node-Groups und Karpenter unterstützen Spot; Fargate Spot gibt es nur für ECS.

Azure

Ein Spot-Node-Pool ist ein sekundärer Pool, nie der Standard-Pool, mit variablem Preis je Region und VM-Größe und einem Höchstpreis in USD, bei -1 bis zum On-Demand-Preis. Die Eviction Policy Delete löscht die VM, Deallocate stoppt sie; gestoppte VMs zählen weiter gegen das Compute-Kontingent und können Skalierung und Upgrade blockieren. Die Positionen tragen in Azure Cost Management den Meter mit dem Zusatz Spot, etwa D4s v5 Spot, und die Preis-API gibt den aktuellen Spot-Preis je Region aus.

Google Cloud

Spot-VMs haben, anders als die älteren Preemptible-VMs mit ihrer 24-Stunden-Grenze, keine Laufzeitgrenze und werden nur bei Bedarf des Anbieters entzogen. Im Abrechnungsexport stehen sie unter Compute Engine mit SKUs, deren Beschreibung Spot Preemptible enthält, je Maschinenfamilie und Region. Autopilot bietet Spot-Pods an, die Autopilot auf Spot-VMs platziert und nach Requests zum Spot-Satz abrechnet.

Was es für Ihre Kosten bedeutet

Ein Spot-Pool senkt den Stundenpreis derselben Maschine; die Einsparung ist der Abstand zum On-Demand-Preis mal den Stunden, die der Pool tatsächlich auf Spot läuft. Zwei Dinge schmälern sie. Die Rückfallstunden auf On-Demand, wenn Spot-Kapazität fehlt, kosten den vollen Preis, und die Unterbrechungen kosten Arbeit: Jobs, die von vorn beginnen, Starts, Drains, Ersatz-Nodes, die neu hochfahren. Spot-Nodes zählen nicht in ein Commitment: Ein Savings Plan oder eine Reservierung deckt On-Demand-Nutzung, und ein Pool, der zwischen Spot und On-Demand wechselt, lässt die Commitment-Abdeckung schwanken. Die Aufteilung folgt deshalb der Last: Commitments für die Grundlast, Spot für den unterbrechbaren Teil darüber (Kapazitätsplanung und Headroom).

Der Abstand zwischen On-Demand- undSpot-Preis, mal die Stunden, die derPool tatsächlich auf Spot läuftDie EinsparungAbzüglich: Rückfall-stunden On-Demandzum vollen PreisAbzüglich: die Unter-brechungsarbeit, neugestartete Jobs, Drains,startende Ersatz-NodesNicht auf ein Commitmentgezählt: Plan oder Reser-vierung decken die On-Demand-Basis, Spotsteht daneben
Die Einsparung ist der Preisabstand mal die Stunden auf Spot, abzüglich der Rückfallstunden und der Unterbrechungsarbeit, und Spot-Stunden zählen nie auf ein Commitment

In den Abrechnungsdaten ist ein Spot-Node am Usage Type, am Meter oder an der SKU zu erkennen, nicht am Cluster; die Pods auf ihm kosten anteilig weniger, weil der Node-Preis niedriger ist (was ein Pod kostet). Belegt ist die Einsparung, wenn die Spot-Stunden in den Daten steigen und die On-Demand-Stunden desselben Pools im gleichen Maß sinken; eine Unterbrechungsrate, die die Arbeit übersteigt, die sie spart, ist das Signal, den Pool auf andere Instanztypen zu öffnen oder den Workload zurückzunehmen.

Wo es schiefgeht

  • Pods ohne Toleration auf Spot. Symptom: Eine Datenbank oder ein Controller mit einer Replika fällt bei einer Unterbrechung aus. Ursache: Dem Spot-Pool fehlt der Taint, oder die Toleration wurde zu großzügig verteilt.
  • Rückfall auf On-Demand unbemerkt. Symptom: Die Spot-Stunden sinken, die Rechnung steigt. Ursache: Der NodePool weicht bei fehlender Spot-Kapazität auf On-Demand aus, und niemand misst den Anteil.
  • Ein Instanztyp, eine Zone. Symptom: Der Spot-Pool bleibt leer oder wird häufig unterbrochen. Ursache: Zu wenige zulässige Instanztypen und Zonen; die Kapazität eines einzelnen Typs ist knapp.
  • Unterbrechung ohne Drain. Symptom: Jobs enden mit Fehlern, Anfragen gehen verloren. Ursache: Kein Termination Handler oder keine Warteschlange, die die Ereignisse verarbeitet; die Vorwarnung verstreicht ungenutzt.
  • Deallocate blockiert den Cluster. Symptom: Skalierung oder Upgrade eines AKS-Clusters scheitern nach Verdrängungen. Ursache: Die Eviction Policy Deallocate lässt gestoppte Spot-VMs gegen das Kontingent zählen.
  • Commitment auf Spot gerechnet. Symptom: Die Auslastung eines Savings Plan sinkt, nachdem ein Pool auf Spot gewechselt hat. Ursache: Spot-Stunden werden nicht vom Commitment gedeckt; es war auf die On-Demand-Stunden dieses Pools bemessen.

Beispiel

Listenpreise, gelesen am 2026-10-21 über die Azure Retail Prices API für Germany West Central, Linux: eine VM Standard_D4s_v5 (4 vCPU, 16 GiB) kostet 0,23 USD je Stunde als reguläre VM und 0,042504 USD je Stunde als Spot-VM; der Spot-Preis ist variabel und gilt zum Lesezeitpunkt.

Ein Pool aus fünf D4s_v5 kostet regulär 5 × 0,23 × 730 = 839,50 USD im Monat, auf Spot 5 × 0,042504 × 730 = 155,14 USD, ein Abstand von 684,36 USD. Läuft der Pool wegen fehlender Spot-Kapazität an 10 Prozent der Stunden auf dem On-Demand-Rückfall, kosten diese 73 Stunden 5 × 0,23 × 73 = 83,95 USD statt 5 × 0,042504 × 73 = 15,51 USD, und die Einsparung des Monats sinkt um 68,44 USD. Was die Unterbrechungen selbst kosten, steht nicht auf der Rechnung: wiederholte Jobs und die Minuten, in denen Ersatz-Nodes hochfahren, zahlen die Teams in Zeit.

Quellen

Gelesen am 2026-10-21. AWS Spot-Instance-Unterbrechungen, Unterbrechungshinweise und Abrechnung unterbrochener Spot-Instances, AWS Node Termination Handler, Karpenter Disruption, Microsoft Spot-Node-Pools in AKS und Azure Retail Prices API, Google Cloud Spot-VMs in GKE.