FinOps: Cloud-Börse - Spot-Instanzen in Kubernetes sicher nutzen

Stellen Sie sich vor, Sie könnten die gleiche Rechenleistung für 70 % bis 90 % weniger Kosten erhalten. Der Haken? Der Cloud-Provider darf Ihnen den Server jederzeit mit einer Vorwarnzeit von nur zwei Minuten (AWS) oder sogar nur 30 Sekunden (Azure) wieder wegnehmen.

Was für klassische Server ein Albtraum ist, ist für Kubernetes–Workloads eine riesige Chance. Da Kubernetes von Grund auf darauf ausgelegt ist, dass Pods sterben und an anderer Stelle neu entstehen können, sind Spot-Instanzen (oder “Preemptible VMs”) der perfekte Partner für eine kosteneffiziente Cloud-Strategie im Jahr 2026.

Das Prinzip: Restposten-Rampe der Cloud-Giganten

Cloud-Provider wie AWS, Google und Azure halten riesige Kapazitäten vor, um Lastspitzen abzufangen. Diese ungenutzten Ressourcen werden an der “Börse” als Spot-Instanzen versteigert. Sobald ein Vollzahler die Kapazität benötigt, wird die Spot-Instanz gekündigt.

Welche Workloads eignen sich für Spot?

Nicht jede Applikation sollte auf einer Instanz laufen, die plötzlich verschwinden kann.

• Perfekt geeignet: Stateless Microservices, CI/CD-Runner, Batch-Processing, KI-Training, Rendering-Jobs.
• Bedingt geeignet: Hochverfügbare Web-Frontends (bei ausreichend hoher Replikation).
• Nicht geeignet: Datenbanken (ohne Replikation), Legacy-Monolithen mit langen Startzeiten, Single-Node-Applikationen.

Die Geheimwaffe: Intelligente Orchestrierung mit Karpenter

Früher war das Management von Spot-Instanzen mühsam. Man musste “Spot-Terminations-Handler” installieren und hoffen, dass der Cluster rechtzeitig reagiert. Heute übernimmt Karpenter (der moderne Node-Provisioner) diese Aufgabe.

Karpenter versteht den Markt:

1. Diversifizierung: Er wählt nicht nur einen Instanz-Typ, sondern streut über verschiedene Größen und Familien, um das Risiko einer Massenkündigung zu minimieren.
2. Proaktives Handeln: Er empfängt die Kündigungssignale des Providers und leitet sofort das “Draining” (kontrolliertes Räumen) des Nodes ein, während er parallel bereits Ersatz beschafft.
3. Kosten-Optimierung: Karpenter berechnet in Echtzeit, welche Kombination aus Spot-Instanzen gerade am günstigsten ist, um Ihre aktuellen Pods zu beherbergen.

[Image showing Karpenter replacing a terminating Spot instance with a new one before the workload is affected]

Strategie: Der “Mixed-Instance” Ansatz

Für geschäftskritische Umgebungen im Mittelstand empfehlen wir selten eine reine Spot-Strategie. Der sicherste Weg ist der Mix:

• Base Capacity (On-Demand): Ein kleiner Teil Ihres Clusters läuft auf stabilen On-Demand-Instanzen (evtl. durch Savings Plans oder Reserved Instances zusätzlich rabattiert). Hier liegen die absolut kritischen Dienste.
• Burst Capacity (Spot): Alles, was darüber hinausgeht oder asynchron arbeitet, wird auf Spot-Instanzen ausgelagert.

Durch Kubernetes-Features wie Node Affinity und Taints/Tolerations können wir präzise steuern, welche App auf welcher “Güteklasse” von Hardware landet.

Fazit: Wer wagt, gewinnt (an Marge)

Spot-Instanzen sind kein Risiko, sondern eine architektonische Entscheidung. Wenn Ihr System “Cloud-Native” gebaut ist – also kurze Startzeiten hat und zustandslos arbeitet – verschenken Sie jeden Monat Geld, wenn Sie keine Spot-Kapazitäten nutzen. Mit modernen Tools wie Karpenter ist das Risiko heute geringer denn je, während der finanzielle Hebel enorm bleibt.

Technical FAQ: Spot-Instanzen

Was passiert, wenn eine ganze Instanz-Klasse (z.B. alle c5.large) im Rechenzentrum ausverkauft ist? Das ist das größte Risiko. In diesem Fall kann der Cluster nicht mehr auf Spot-Instanzen skalieren. Ein guter Provisioner (wie Karpenter) wechselt dann automatisch auf teurere On-Demand-Instanzen (Fallback), um die Verfügbarkeit zu retten – und kehrt zu Spot zurück, sobald diese wieder verfügbar sind.

Wie reagiert meine Monitoring-Software auf die ständigen Neustarts? Wenn Sie viele Spot-Instanzen nutzen, wird Ihr Cluster dynamischer. Ihre Monitoring-Lösung (z.B. Prometheus/Grafana) muss damit umgehen können, dass Nodes kommen und gehen. “Flapping Alerts” sollten hier für Spot-Nodes deaktiviert oder angepasst werden.

Muss ich meinen Code für Spot-Instanzen anpassen? Nicht direkt, aber die Applikation muss ein SIGTERM-Signal sauber verarbeiten können (Graceful Shutdown). Sie hat nur 30-120 Sekunden Zeit, laufende Transaktionen abzuschließen, bevor der Prozess hart beendet wird.