Kubernetes-Kosten senken: Platform Engineering

Zwölf Pods fordern je 2 Prozessorkerne (CPU) an. Das 95. Perzentil der tatsächlichen Nutzung, p95, liegt bei 0,22 Kernen. Der Kubernetes-Scheduler packt Pods nach der Anforderung (Request), nicht nach der Nutzung. Reserviert: 24 Kerne. Arbeit: 2,6 Kerne. Der horizontale Autoscaler (Horizontal Pod Autoscaler, HPA) rechnet den Prozentwert des Requests, sieht Luft und senkt die Replikazahl nicht. Der Cluster Autoscaler stellt eine weitere Maschine desselben Typs dazu, weil der freie Platz auf dem Knoten von einem Request belegt ist, den seit der Migration niemand angefasst hat.

Cloud-Kosten senken beginnt nicht mit einem Rabatt beim Anbieter. Es beginnt damit, wer im Platform Engineering den Request, die Maschinenfamilie und die Uhrzeit ändern darf, zu der eine Nicht-Produktionsumgebung ausgeht. Ein zu hart geschnittener Limit hebt die Latenz p99 (99. Perzentil) oder beendet den Prozess wegen Speichermangels (Out of Memory, OOM). Ein richtig geschnittener Request nimmt Knoten weg, die niemand nutzt.

Drei Wörter, die in Briefings zu einer Zeile werden:

• Platform Engineering ist das Team, das die interne Plattform baut: Cluster, kontinuierliche Integration und Auslieferung (CI/CD), Servicekatalog, Budgets. Produktteams setzen Kubernetes nicht von null auf.
• FinOps (Financial Operations) ist der Takt, in dem Technik und Finanzen die Kosten einer Arbeitseinheit sehen, zum Beispiel von tausend Anfragen, und nicht nur die Rechnung am Monatsende.
• Slack ist die Lücke zwischen Limit oder Request und realer Nutzung. Bei Google lagen manuell konfigurierte Jobs bei 46% Slack. Die Automatik senkte das auf 23%.

1. Drei Schleifen, die nicht dieselbe Zahl sehen

Auf dem Cluster laufen drei Regler. Jeder optimiert eine andere Größe. Keiner sieht allein die Rechnung.

1. Request und Limit am Pod. Der Request ist eine Reservierung für den Scheduler. Das Limit ist die Decke: darüber wird CPU gedrosselt, und Speicher endet mit dem Abschuss des Prozesses. Ein Request 4× über p95 lässt auf dem Knoten ein Loch, in das der nächste Pod nicht passt.
2. Replikazahl (HPA). Der HPA ergänzt Pods, wenn der Prozentwert des Requests ein Ziel überschreitet, oft 50–80%. Ist der Request 9× zu groß, sieht die Nutzung aus wie 11%. Der HPA schläft. Oder er schwingt, wenn das Limit die CPU drosselt und die Latenz steigt, bevor der Mittelwert „nachzieht“.
3. Knotenzahl (Cluster Autoscaler). Der Cluster Autoscaler nimmt Maschinen aus einem festgelegten Pool hinzu und wieder weg. Der Pool ist homogen: der Instanztyp, den jemand in Infrastruktur als Code (Infrastructure as Code, IaC) geschrieben hat. Ein Pod, der nicht in den freien Platz passt, weckt eine neue Maschine derselben Familie, auch wenn eine günstigere Familie (mehr Speicher, weniger CPU) die Arbeit mit einem Knoten erledigt hätte.

Das vierte Element ist kein Regler. Es ist ein Kalender. Dev und Stage in Produktionsgröße, 24 Stunden am Tag, 7 Tage die Woche. Arbeitszeit 8–19 Uhr sind 55 von 168 Stunden. Der Rest, etwa zwei Drittel der Woche, ist eine Rechnung für Leere.

resources:
  requests:
    cpu: "500m"       # Reservierung: Scheduler und HPA schauen hierhin
    memory: "512Mi"
  limits:
    cpu: "1500m"      # Decke; darüber wird CPU gedrosselt
    memory: "1Gi"     # darüber stirbt der Prozess (OOM)

Der vertikale Autoscaler (Vertical Pod Autoscaler, VPA) kann den Request umschreiben. Im Automatikmodus startet er Pods neu. Beim Speicher kann er ein Leck verdecken: Die Anwendung wächst, der VPA hebt das Limit, der Fehler verschwindet aus dem Diagramm und bleibt auf der Rechnung. Eine VPA-Empfehlung ohne Sperre ist kein Rollout.

Werkzeuge, die für wartende Pods einen Maschinentyp wählen (bei Amazon Web Services ist das Karpenter, anderswo Node-Auto-Provisioning), umgehen die Grenze des homogenen Pools. Sie ersetzen das Right-Sizing des Requests nicht. Sie packen, worum die Pods bitten. Bitten sie um das 9-Fache, kauft Karpenter eine ordentlichere Version desselben Lochs, nicht null Loch.

Die Rechnung für Grafikprozessoren (GPU) und Modelltraining ist eine andere Schleife: Drifterkennung und Retraining, nicht das Packen von Knoten. Das steht getrennt im Artikel über MLOps-Services. Beide Briefings in eine Person „DevOps für alles“ zu legen ergibt eine Bereitschaft. Es ergibt weder FinOps noch Retraining.

2. Was die Arbeiten wirklich messen

Eine Folie „wir sparen 40%“ sagt nicht, auf welchem Aufbau und gegen welche Basis. Vier Quellen messen Verschiedenes. Trennen Sie das, bevor jemand einen Prozentsatz in den Vertrag schreibt.

• Manueller Slack 46%, Automatik 23%. Rzadca, Findeisen, Świderski u. a., Autopilot: Workload Autoscaling at Google (EuroSys 2020). Autopilot setzt horizontale Skalierung (Aufgabenanzahl) und vertikale Skalierung (CPU und Speicher) aus der Historie. Slack fällt von 46% bei manueller Konfiguration auf 23%. Die Zahl der stark von OOM getroffenen Jobs fällt etwa um den Faktor 10. Zum Zeitpunkt der Veröffentlichung deckte Autopilot über 48% des flottenweiten Ressourcenverbrauchs von Google. Das ist Borg, Googles internes System, kein Produkt für EKS (Elastic Kubernetes Service). Übertragbar ist die Mechanik: vertikal und horizontal zusammen, auf Historie, mit dem Ziel „weniger Slack, ohne OOM und ohne CPU-Drosselung“.
• Gleiche Maschinen und Upgrades brechen das Muster. Hua, Yang, Qian u. a., Humas (arXiv:2406.15769, 2024). Versuch mit 50 realen Microservices und über 11 000 Containern. Gegen als Stand der Technik behandelte Verfahren verbessert Humas die Ressourceneffizienz um etwa 30,4% und die Stabilität um etwa 48,0%. In der Tabelle liegt Slack auf den Rohspuren bei 52,87%, bei einer Neuimplementierung von Autopilot bei 16,63%, bei Humas bei 11,58%. Die mittlere CPU-Zuteilung sinkt um etwa 46,8% gegenüber den Rohspuren. Getrennt: Nach einem neuen Release ändert sich das Nutzungsmuster (Pattern Drift). Ein auf der alten Version trainierter Autoscaler trifft wieder daneben. Das ist nicht dasselbe 23% wie bei Rzadca. Andere Spur, andere Zahl.
• Eine CPU-Schwelle pro Dienst sieht die Ende-zu-Ende-Latenz nicht. Sachidananda und Sivaraman, Collective Autoscaling for Cloud Microservices (COLA, arXiv:2112.14845). Jeder Microservice, der allein über eine CPU-Schwelle skaliert, weiß nicht, dass die Latenz des Nutzers die Summe mehrerer Dienste ist. Auf der Google Kubernetes Engine (GKE), im Standard- und im Autopilot-Modus, hält COLA ein Median- oder Tail-Latenzziel auf 53 von 63 Lasten und ist dann im Mittel 19,3% günstiger als der nächste Autoscaler, der dasselbe Ziel hält. Auf 48 dieser 53 ist es der günstigste. Auf kleinen Anwendungen, deren Konfigurationen sich vollständig aufzählen lassen, ist es in 90% der Fälle optimal. Die Autoren schreiben, die Ersparnis trage die Trainingskosten in wenigen Tagen. Das ist ihr Versuchsaufbau, kein Versprechen auf Ihre Rechnung.
• Der Cluster Autoscaler wechselt die Maschinenfamilie nicht. Boghani, Kirimlioglu, Moturi und Tso, Cloud Resource Allocation with Convex Optimization (arXiv:2503.21096, 2025). Der Cluster Autoscaler skaliert bestehende Pools identischer Instanzen hoch und runter. Er wählt keinen Mix. Die Arbeit vergleicht eine konvexe Optimierung mit diesem Autoscaler in einer Simulation (Python, Median aus fünf Läufen), nicht auf einer AWS-Rechnung. Szenario 1, einfache Webanwendung von null: kein wesentlicher Unterschied. Ein Standard-Autoscaler reicht. Szenario 2, Zubau zu bestehender Infrastruktur: 42,5% günstiger (0,12 USD/h gegen 0,07 USD/h). Szenarien 3–5: 80,5%, 87,2% und 71,1%. Mittel über fünf: 56,3%. Speicherlast (Szenario 4): von 1,08 USD/h auf 0,14 USD/h. Überprovisionierung in der Größenordnung von Tausenden Prozent erscheint in dem Szenario, das nur kleine Instanzen erlaubt. Das ist keine typische Rechnung. Es ist der Beleg, dass die falsche Maschinenfamilie Knoten multipliziert.
• VPA ohne Leck-Sperre kauft Speicher für einen Fehler. Karakaya, Şengül und Kaplan, Safety-Gated Autoscaling (arXiv:2607.26503, 29. Juli 2026). Ein Speicherleck-Detektor (lineare Regression, R²) blockiert die Empfehlung, statt einen defekten Container zu vergrößern. Auf einem lebenden GKE-Cluster sind 20–40% Ersparnis eine Was-wäre-wenn-Projektion, keine gemessene Rechnung. Der Detektor trifft zu 83%. Testsatz: 1118 Tests, Abdeckung 80,3%. Es gibt einen Dry-Run und eine menschliche Freigabe. Die 20–40% nur mit diesem Vorbehalt zitieren.

3. Rechenbeispiel: 24 Kerne reserviert, 2,6 in Nutzung

Die Zahlen aus den Papieren übertragen sich nicht 1:1 auf Ihre Rechnung. Die Reihenfolge schon: zuerst der Request, dann der Maschinentyp, dann das Abschalten dessen, was keinen Verkehr bedient. Wer mit Karpenter auf Requests von 2000m bei 220m Nutzung anfängt, kauft eine hübschere Packung desselben Lochs.

4. Entscheidungstabelle

DevOps / SRE / Cloud: Satz des Spezialisten 140–200 PLN/h, Satz für den Kunden 200–325 PLN/h. Marge des Anbieters 10–25%. Das ist eine Marktkarte, kein Angebot. Aufschlüsselung: was IT Body Leasing 2026 kostet. No Fluff Jobs nennt für das 1. Quartal 2026 B2B-Spannen eines DevOps-Spezialisten von 23,5–28,5 Tsd. PLN. Das ist seine Rechnung, nicht der Preis, den der Kunde zahlt.

5. Anti-Muster, die im HPA-Tutorial fehlen

1. HPA auf 80% eines Requests, der 4× zu groß ist. Der Autoscaler sieht Untätigkeit. Die Knoten bleiben. Das Dashboard „Clusterauslastung“ zeigt 20%, und niemand verbindet das mit dem Manifest.
2. VPA im Auto-Modus auf Speicher, ohne Leckdetektor. Die Empfehlung wächst mit dem Fehler. Der OOM-Vorfall verschwindet. Die Rechnung nicht. Der Dry-Run existiert, damit ein Mensch den Trend sieht, bevor das Limit steigt.
3. Vier Pools „für alle Fälle“ und ein Cluster Autoscaler, der nur denselben Typ ergänzen kann. Boghani: bei einer einfachen Anwendung von null ist kein Gewinn sichtbar. Der Gewinn liegt dort, wo die Pod-Form nicht zur Familie passt, die vor zwei Jahren in Terraform stand.
4. FinOps als PDF und DevOps auf 20% einer Stelle. CI/CD, Bereitschaft, Kosten, Kubernetes und noch GPU. Eine Person auf fünf Schleifen schließt keine. Ein Kostenwerkzeug nur zum Lesen, ohne Recht, den Request zu ändern, ist ein teureres PDF.

6. Playbook: wen mieten, und in welcher Reihenfolge

Fangen Sie nicht mit dem nächsten Cluster an. Fangen Sie mit der Frage an, welche Schleife die Rechnung hält: Request, Maschinentyp, Nicht-Produktion oder GPU.

1. Cluster, Identität (IAM, Identity and Access Management) und Terraform stehen. Es fehlt der Eigentümer der Requests, des Namespace-Budgets und der wöchentlichen Durchsicht. Das ist klassisches Body Leasing eines DevOps-Ingenieurs: eine Person, Ihr Stand-up, Ihre Definition of Done. Body Leasing heißt hier: ein Spezialist in Ihrem Team, meist nach Aufwand (Time and Materials, T&M). Wir verkaufen keine namentliche Bank für Montagmorgen.
2. Niemand besitzt den Cluster. Vier Konten, kein IaC, Dev in Produktionsgröße, Manifeste mit einem Request aus dem Tutorial. Eine Person näht das nicht in einem Sprint. Ein Platform-Squad: jemand für Cluster und IaC, jemand für CI/CD, jemand mit dem Recht zu sagen „dieser Namespace geht um 19 Uhr aus“. Das liegt näher am Team-Leasing als an „wir kaufen noch einen DevOps“. Wann ein Squad, wann eine Rolle: Team Leasing vs Body Leasing 2026.
3. Daten und Kubeconfig verlassen den Laptop nicht. Der Kontraktor arbeitet in Ihrem IAM, in Ihrer Cloud, unter Geheimhaltung (NDA) und Auftragsverarbeitung. Ein exportiertes Kubeconfig „um Requests schneller zu rechnen“ ist Produktionszugriff. Klauseln: Verträge, Margen, Urheberrecht.
4. Anlauf. Eine Person in ein bestehendes Team: erste Profile in Tagen, Start nach Ihren Gesprächen und dem Vertrag. Ein Squad von null: Wochen, weil Sie Rechte und eine Definition of Done für die Änderung eines Requests in Produktion zusammennähen. Die Ansage „drei Senior-Plattformleute ab Montag“ ist entweder ein Lebenslauf oder eine Bank, die wir nicht halten.

Commoditech macht seit 2012 T&M und Festanstellung aus Warschau. Im Netz sind 80+ Spezialisten. Wir halten sie nicht untätig auf einer Bank. Ein Brief für Body Leasing oder für eine Festanstellung (Erfolgshonorar, ohne Einstellung keine Gebühr) lässt sich auch aus dem Editor ablegen, über MCP für KI-Agenten (Model Context Protocol, das Protokoll, mit dem ein Assistent in der IDE Werkzeuge aufruft). Den Betrag für einen konkreten Stack rechnet ein Mensch. Die Spannen stehen im Artikel zu den Sätzen, nicht in einer automatischen Antwort. Kontakt: das Formular.

FAQ

Quellen

• Rzadca, K., Findeisen, P., Świderski, J. et al. (2020). Autopilot: Workload Autoscaling at Google. EuroSys 2020. doi.org/10.1145/3342195.3387524. research.google.
• Hua, Q., Yang, D., Qian, S., Cao, J., Xue, G., Li, M. (2024). Humas. arXiv:2406.15769. arxiv.org/abs/2406.15769.
• Sachidananda, V., Sivaraman, A. (2022). Collective Autoscaling for Cloud Microservices. arXiv:2112.14845. arxiv.org/abs/2112.14845.
• Boghani, S., Kirimlioglu, E., Moturi, A., Tso, H.-T. (2025). Cloud Resource Allocation with Convex Optimization. arXiv:2503.21096. arxiv.org/abs/2503.21096.
• Karakaya, A., Şengül, E., Kaplan, A. (2026). Safety-Gated Autoscaling. arXiv:2607.26503. arxiv.org/abs/2607.26503.
• Commoditech — Sätze für Body Leasing 2026, DevOps-Ingenieure mieten, Team Leasing vs Body Leasing.