Ihr Team baut Produkt – wir räumen die Plattform auf.

Kubernetes-Beratung für Tech-Unternehmen: was wir anders machen

Kubernetes-Beratung für Tech-Unternehmen hat einen schlechten Ruf, und oft zu Recht: Jemand kommt für zwei Wochen, malt ein Zielbild mit zwanzig neuen Werkzeugen, und danach sitzt das Team allein mit dem Ergebnis. Wir arbeiten anders. Wir lesen zuerst Ihren Code, reden mit den Leuten, die nachts angerufen werden, und schlagen dann die kleinsten Änderungen mit der größten Wirkung vor. Neue Werkzeuge kommen nur dazu, wenn sie ein konkretes Problem lösen, das Sie heute haben.

Dabei sprechen wir Ihre Sprache: Manifeste, Pull Requests, Incidents, SLOs. Sie bekommen keine Folien, sondern Commits und ein Dokument, das Ihr Team in einem Jahr noch versteht.

Das Review: was wir uns ansehen

Ein Review beginnt mit lesendem Zugriff auf Ihre Repositories und Cluster. Wir schauen uns an, wie Deployments entstehen und ausgerollt werden, wie Rechte vergeben sind, wo Secrets liegen, wie Netzwerk-Policies aussehen und welche Version Ihre Cluster und Add-ons haben. Dazu kommen Requests und Limits, Node-Auslastung, Monitoring und die Frage, welche Alerts tatsächlich jemand liest.

Das Ergebnis ist ein schriftlicher Bericht mit drei Kategorien: was gut ist und so bleiben sollte, was brennt und zuerst angegangen werden muss, und was warten kann. Jeder Befund hat eine Begründung und einen Vorschlag, wie man ihn behebt.

Platform Engineering in kleinen Schritten

Aus dem Bericht wird ein Plan, den wir gemeinsam abarbeiten. Typische erste Schritte sind ein sauberes GitOps-Setup mit Flux, in dem Umgebungen und Promotion klar geregelt sind, Policies als Code, die gefährliche Konfigurationen schon im Pull Request abfangen, und ein Secrets-Management, das ohne Copy-and-paste auskommt. Später folgen wiederverwendbare Bausteine, mit denen neue Dienste in Minuten statt Tagen produktionsreif sind.

Wichtig ist uns die Reihenfolge. Ein Upgrade, das seit drei Versionen aussteht, ist wichtiger als die schönste interne Entwicklerplattform.

Upgrades ohne Drama

Viele Teams schieben Cluster-Upgrades vor sich her, bis der Anbieter mit dem Ende des Supports droht. Dann wird aus einem Routinejob ein Projekt mit Wochenendschicht. Wir machen Upgrades wieder langweilig: Zuerst suchen wir mit Werkzeugen wie Pluto nach APIs, die in der Zielversion entfernt werden, und prüfen Helm-Charts und Operatoren auf Kompatibilität. Dann läuft das Upgrade in einer Staging-Umgebung, mit denselben Manifesten wie in Produktion.

In der Produktion sorgen PodDisruptionBudgets, sinnvolle Readiness-Probes und genügend Replikas dafür, dass beim Austausch der Nodes nichts ausfällt. Am Ende steht ein Runbook, mit dem Ihr Team das nächste Upgrade selbst durchführen kann.

Kosten: Requests, Limits und leere Nodes

Die Cloud-Rechnung wächst bei vielen Teams schneller als die Last. Meist liegt es nicht am Anbieter, sondern an großzügigen Requests, die niemand mehr hinterfragt, an Nodes, die halb leer laufen, und an Testumgebungen, die nie schlafen. Wir messen, was Ihre Workloads wirklich brauchen, passen Requests und Limits an, sorgen dafür, dass Nodes sinnvoll ausgelastet werden, und schalten ab, was niemand vermisst. Jede Änderung ist messbar und lässt sich zurückdrehen.

Pairing statt Abhängigkeit

Wir wollen nicht unersetzlich werden. Deshalb entsteht alles in Ihren Repositories, per Pull Request, mit Reviews durch Ihr Team. Komplexere Änderungen setzen wir im Pairing um, sodass mindestens eine Person bei Ihnen jeden Schritt nachvollziehen kann. Zum Abschluss gibt es Dokumentation und eine Session, in der wir das Wichtigste gemeinsam durchgehen. Auf Wunsch bleiben wir danach als zweite Meinung erreichbar; das rechnen wir gesondert ab.

Mehr dazu, wie wir Cluster aufbauen und absichern, steht auf der Seite zur Kubernetes-Beratung. Ob ein Review für Ihr Team sinnvoll ist, klären wir in einem kostenlosen Erstgespräch.