Kubernetes-Orchestrierung und -Optimierung
Cluster in der richtigen Grösse, ruhig im Betrieb und langweilig beim Upgrade.
Für Teams mit AKS, EKS, GKE oder Kubernetes auf eigener Hardware, die für halb leere Nodes zahlen, Upgrades fürchten oder zu oft geweckt werden. Ich dimensioniere nach echter Nutzung, bringe den Cluster unter GitOps und mache Skalierung und Upgrades zur Routine, in der Cloud, auf Bare Metal oder beidem.
Kommt Ihnen das bekannt vor?
- Requests und Limits wurden einmal geschätzt und nie überprüft, also laufen Nodes halb leer
- Niemand traut sich an das Cluster-Upgrade, also fällt er hinter unterstützte Versionen zurück
- Änderungen werden von Hand eingespielt, und niemand weiss genau, was gerade läuft
- Ein Teil der Workloads muss on-premises bleiben oder sogar offline laufen
So gehe ich vor
- 1
Eine echte Woche messen
Prometheus erfasst über mindestens eine Woche, inklusive der starken Tage, p95-CPU und -Speicher pro Workload, damit Entscheidungen auf Daten statt Gefühl beruhen.
- 2
Requests aus den Daten setzen
Requests folgen p95 plus Puffer, Limits schützen die Nachbarn, und PodDisruptionBudgets halten Dienste verfügbar, während Nodes kommen und gehen.
- 3
Den Cluster schrumpfen lassen
Der Cluster Autoscaler oder Karpenter baut Nodes ab, die die Pods nicht mehr brauchen. In einem Produktiv-Cluster ging das so von 7 auf 4 Nodes, ohne Auswirkung auf Kunden.
- 4
Alles in Git
FluxCD und Helm spielen ein, was im Repository steht, damit jede Änderung geprüft, reproduzierbar und leicht rückgängig zu machen ist, und Upgrades werden zum Pull Request.
- 5
Cloud, On-Prem oder beides
Wo nötig, spannt eine Plattform Bare Metal und AWS auf, Windows-Workloads laufen als VMs auf KubeVirt, und Teile bleiben air-gapped.
Interaktiv
Wie viele Nodes brauchen Ihre Requests wirklich?
Schieben Sie die Regler auf Ihre Werte. Requests entscheiden, wo Pods Platz finden, zu grosse Requests kaufen also Nodes, die niemand nutzt.
Node-Grösse
5
Nodes heute
2
Nodes nach Right-Sizing (200m)
60%
weniger Node-Kapazität
Nur CPU, rund 90 % eines Nodes sind allokierbar, mindestens 2 Nodes für Verfügbarkeit. Speicher genauso prüfen, bevor ein Node wegfällt.
Alle Rechner und ChecklistenWas Sie bekommen
- p95-Dashboards pro Workload in Grafana
- Requests, Limits und Disruption Budgets aus echten Daten
- Autoscaling, das unnötige Nodes abbaut, unter Last getestet
- GitOps mit FluxCD und Helm, inklusive Upgrade-Runbook
- Alerts auf Geschäftsergebnisse, nicht nur auf CPU
Fragen, die Kunden stellen
Mit welchen Kubernetes-Varianten arbeiten Sie?
AKS, EKS und GKE in der Cloud sowie Kubernetes auf eigener Hardware wie Talos, auch hybride Setups, bei denen eine Plattform beides umfasst.
Ist Right-Sizing riskant für die Produktion?
Nicht, wenn es auf p95-Daten basiert, mit Puffer, Disruption Budgets und einer Änderung nach der anderen. Jeder Schritt hat einen Rückweg, und Nodes gehen erst, wenn die Pods umgezogen sind.
Wie lange dauert es?
Eine Woche messen, dann die ersten Änderungen. Ein typisches Right-Sizing mit GitOps-Setup dauert wenige Wochen, je nach Anzahl Cluster und Workloads.
Kann mein Team das danach selbst betreiben?
Ja. Alles liegt in Git, mit Runbooks für Upgrades und Störungen, und die Übergabe passiert in Arbeitssessions mit Ihrem Team.
Wie rechnen Sie ab?
Nach einem 30-Minuten-Gespräch: ein fester Umfang für ein definiertes Ergebnis oder einige Tage pro Monat als Ihr Platform Lead.
Weiterlesen
- Kubernetes richtig dimensionieren: das Playbook, mit dem ein Cluster von 7 auf 4 Nodes kam
- Kubernetes-Kosten auf EKS und GKE: dasselbe Playbook, andere Hebel
- MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?
- Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben
- Gratis-Leitfaden (PDF): Cloud-Kosten senken, ohne etwas kaputt zu machen
Kontakt aufnehmen
Erzählen Sie mir von Ihrem Projekt, ich antworte innerhalb von 1–2 Werktagen.
- mail@dominikheinrich.ch
- Unternehmen
- MADO Consulting
- Folgen Sie mir auf LinkedIn
Weltweit verfügbar, remote. Vor Ort auf Anfrage, je nach Land.
Öffnet hier den Buchungskalender von Calendly. Beim Laden werden Daten an Calendly übertragen (siehe Impressum).