Kubernetes Beratung
Architekturgutachten zum Cluster — Wir bringen euren Cluster in einen produktionsreifen Zustand und übergeben ihn eurem Team.
Beratung und Umsetzung für Teams, die Kubernetes bereits betreiben und merken, dass der Cluster den Alltag bestimmt statt ihn zu tragen. Wir bringen die Umgebung in einen produktionsreifen Zustand und übergeben sie.
Wir arbeiten an eurem Cluster, in euren Repositories, über eure Reviews. Das Mandat endet, wenn euer Team ein Upgrade ohne uns fährt — nicht, wenn ein Architekturbild abgenommen ist.
FIT-CHECK BUCHENWarum Cluster halbfertig bleiben
Kubernetes wird selten falsch eingeführt. Es wird eingeführt und dann nicht fertig gebaut: Der Cluster läuft, die Anwendungen laufen, und alles darum herum ist von Hand entstanden.
Was fehlt, zeigt sich erst im Betrieb. Ein Zertifikat läuft ab, und niemand weiß, wer es erneuert. Ein Node fällt aus, und die Wiederherstellung steht in einem Chatverlauf. Ein Upgrade steht an, und die Antwort ist ein Termin im nächsten Quartal.
Dieser Zustand ist teuer, aber unauffällig. Er kostet selten Ausfallzeit am Stück. Er kostet Aufmerksamkeit: Jede Änderung braucht die eine Person, die noch weiß, wie es gemeint war.
Woran ihr es im Betrieb merkt
Sechs Situationen, die wir in bestehenden Kubernetes-Umgebungen regelmäßig antreffen. Je mehr davon zutrifft, desto eher ist der Cluster kein Werkzeug mehr, sondern ein eigenes Projekt.
- Ein Cluster-Upgrade wird seit mehreren Quartalen verschoben, weil niemand sagen kann, welche Workloads danach nicht mehr starten.
- Der Cluster wurde von einer Person aufgesetzt, die inzwischen andere Aufgaben hat. Geändert wird er nur noch im Notfall.
- Was im Cluster läuft, steht so in keinem Repository. Wer den aktuellen Stand wissen will, fragt kubectl, nicht Git.
- Dashboards gibt es, aber im Vorfall schaut niemand hinein. Die Alarme laufen in einen Kanal, den alle stummgeschaltet haben.
- Ein neues Team soll auf den Cluster. Was es dazu braucht, weiß nur die Person, die es diesmal wieder von Hand einrichtet.
- Zugriffsrechte sind historisch gewachsen. Wer in der Produktion deployen darf, lässt sich nicht in einem Satz beantworten.
Was „produktionsreif“ hier heißt
„Produktionsreif“ ist auf dieser Seite kein Werbewort, sondern eine Liste. Ein Cluster gilt für uns als produktionsreif, wenn diese acht Aussagen zutreffen — jede davon gemeinsam mit eurem Team überprüfbar.
- Ein Upgrade von Control Plane und Nodes ist ein geplanter Vorgang mit Runbook und Rückweg, kein Risiko, das ins nächste Quartal wandert.
- Der Sollzustand des Clusters steht in Git. Was dort steht, läuft — und was läuft, steht dort.
- Der Ausfall eines Nodes und der Verlust eines Namespace sind geprobt, nicht nur beschrieben.
- Zugriff hängt an Rollen statt an Personen. Wer in der Produktion was darf, ist dokumentiert und nachprüfbar.
- Metriken, Logs und Traces beantworten die Frage, was gerade kaputt ist — ohne dass sich jemand auf einen Node verbindet.
- Jeder Alarm hat einen Empfänger und ein Runbook. Alarme ohne beides sind abgeschaltet, nicht stummgeschaltet.
- Ein neuer Workload bekommt Namespace, Limits, Zugriff und einen Auslieferungsweg über einen dokumentierten Vorgang.
- Mindestens zwei Personen aus eurem Team führen jeden dieser Punkte ohne uns durch.
Diese Liste ist unser Maßstab, kein Branchenstandard. Im Fit-Check sagen wir, welche Punkte in eurer Umgebung realistisch erreichbar sind und welche wir für zu teuer halten.
Wenn ihr diese acht Punkte an eurem eigenen Cluster durchgehen wollt, bevor ihr mit uns redet: Die Checkliste löst sie in vierundzwanzig Aussagen auf, mit einem ersten Schritt neben jeder offenen. Zur Kubernetes-Checkliste
Was enthalten ist
Acht Arbeitsblöcke. Welche davon ein Auftrag enthält, entscheidet der Zustand eurer Umgebung — in kaum einem Projekt sind es alle.
Platform Rescue
Wenn der Cluster gerade Schaden anrichtet, kommt Stabilisierung vor Umbau. Wir nehmen die akuten Fehlerquellen heraus und stellen einen Zustand her, in dem wieder geplant gearbeitet werden kann.
Cluster-Architektur
Zuschnitt von Clustern und Umgebungen, Netzwerk, Ingress, Storage und Ressourcengrenzen — entschieden entlang eurer Workloads statt entlang eines Standardbilds.
Security
RBAC, Network Policies, Secrets, Image-Herkunft und Admission-Regeln. Die technische Umsetzung Richtung ISO 27001 oder NIS2 gehört dazu; das Testat stellt eine Prüfstelle aus, nicht wir.
GitOps
Der Sollzustand liegt in Git und wird von dort abgeglichen. Änderungen an der Infrastruktur laufen über Pull Requests, genau wie Änderungen am Anwendungscode.
Observability
Metriken, Logs und Traces an einem Ort, verknüpft mit genau den Alarmen, auf die tatsächlich jemand reagiert. Der Rest wird abgeschaltet statt stummgeschaltet.
Betriebsmodell
Wer ist wofür zuständig, wer wird nachts geweckt, was steht im Runbook. Wir schreiben das mit euch auf und proben es einmal, statt es zu behaupten.
Workload-Onboarding
Der dokumentierte Weg, auf dem ein neuer Service in den Cluster kommt: Namespace, Limits, Zugriff, Auslieferungsweg. Damit der nächste Workload nicht wieder ein Einzelfall ist.
Wissenstransfer
Pair Programming an euren eigenen Änderungen, Dokumentation im Repository und eine Übergabe, bei der euer Team die Vorgänge selbst durchführt und wir zusehen.
So läuft eine Zusammenarbeit
Vier Schritte, in dieser Reihenfolge. Nach dem zweiten könnt ihr abbrechen und behaltet trotzdem ein Ergebnis, mit dem ihr weiterarbeiten könnt.
Fit-Check
Ein Gespräch über den Zustand eures Clusters — und darüber, ob Kubernetes für euren Fall überhaupt die richtige Wahl ist. Wenn nicht, sagen wir es in diesem Termin.
Cluster-Review
Wir sehen uns Manifeste, Cluster und Pipelines selbst an und schreiben auf, welche der acht Aussagen oben zutreffen, welche nicht und was das im Betrieb kostet.
Umsetzung im Team
Jede Änderung geht über einen Pull Request, den jemand aus eurem Team liest. Wir arbeiten in euren Repositories, nicht neben ihnen.
Übergabe
Euer Team fährt ein Upgrade und einen Wiederherstellungsfall selbst, wir sehen dabei zu. Dazu eine Liste der Dinge, die wir bewusst nicht gebaut haben — mit Begründung.
Zusammenarbeitsmodelle
Vier Wege in die Zusammenarbeit. Welcher passt, entscheidet sich im Fit-Check; die Seiten dahinter nennen Umfang, Dauer und Preis im Detail.
Zuerst analysieren
Wenn noch nicht feststeht, woran es liegt: eine Analyse mit festem Umfang, die mit einer priorisierten Roadmap endet.
Zuerst stabilisieren
Wenn der Cluster gerade Schaden anrichtet und vor jedem Umbau erst einmal Ruhe einkehren muss.
Neu aufsetzen
Wenn aus einer gewachsenen Umgebung eine Plattform werden soll, die euer Team allein betreibt — mit festem Start- und Endtermin.
Laufende Begleitung
Begleitung über mehrere Monate mit festen Tagen pro Woche, wenn der Betrieb dauerhaft eine erfahrene Hand braucht. Umfang und Laufzeit legen wir pro Fall fest.
Was ihr überprüfen könnt
Ehrlich gesagt: Auf dieser Seite steht keine Zahl aus einem Kundenprojekt. Was wir vorher an Clustern gebaut haben, wurde nie so gemessen, dass es hier etwas belegen würde — und wir erfinden dafür keine Werte.
An dieser Stelle stünde eine Kennzahl. Es gibt keine: In keinem früheren Projekt wurde die Wirkung so gemessen, dass sie hier etwas belegen würde. Sobald ein Kunde eine Messung freigibt, steht sie hier — vorher nicht.
Referenzen
Woran wir gearbeitet haben, beschrieben ohne Kennzahlen, weil wir keine erhoben haben.
Liefermodell
Wer die Arbeit macht, wer sie liest und bei wem die Lieferverantwortung bleibt.
Fachartikel
Wie wir über Cluster, Betrieb und Übergaben denken — öffentlich und in voller Länge nachlesbar.
Passende Fallstudien
Fallstudien zu dieser Leistung, mit Kontext, Eingriff und Übergabe. Jede erscheint erst, wenn der Kunde die Veröffentlichung schriftlich freigegeben hat.
Zu dieser Leistung ist noch keine Fallstudie veröffentlicht. Bis dahin steht im Referenzbereich, woran wir gearbeitet haben.
Wann Kubernetes die falsche Wahl ist
Kubernetes beantwortet Betriebsprobleme, die längst nicht jedes Team hat. In diesen vier Fällen raten wir davon ab — auch dann, wenn die Anfrage bereits nach Kubernetes klingt.
Ein Dienst, ein Team, überschaubare Last
Eine einzelne Anwendung mit ruhigem Verkehr läuft auf einer verwalteten Plattform günstiger und mit weniger Betriebsaufwand. Kubernetes fügt hier vor allem eine Ebene hinzu, die jemand pflegen muss.
Nach dem Projekt betreibt es niemand
Ein Cluster braucht dauerhaft Aufmerksamkeit: Upgrades, Zertifikate, Kapazität. Wenn dafür danach niemand zuständig ist, ist ein verwaltetes Angebot die ehrlichere Wahl — und wir sagen das vor dem Angebot.
Der Engpass liegt nicht im Betrieb
Wenn Releases an Freigaben, Abstimmung oder manuellen Tests hängen, ändert ein Cluster daran nichts. Diese Engpässe verschiebt Kubernetes nur an eine neue Stelle.
Ein Altsystem soll dadurch wartbar werden
Eine Anwendung wird durch Containerisierung nicht besser schneidbar. Wer ein Architekturproblem hat, löst es im Code; Kubernetes verpackt es nur neu.
Trifft einer dieser Fälle zu, sagen wir das im Fit-Check und nennen die Alternative. Ein Kubernetes-Projekt, das niemand braucht, ist auch für uns ein schlechtes Projekt.
Was nicht enthalten ist
Vier Anfragen, die rund um Kubernetes regelmäßig eingehen und die wir ablehnen. Besser hier nachzulesen als erst im Angebot zu finden.
Rund-um-die-Uhr-Betrieb, Rufbereitschaft und SLA-gebundene Betriebsverantwortung
Wir bauen Plattformen und übergeben sie betriebsfähig. Den Betrieb selbst übernehmen wir nicht — das kann ein Managed-Service-Provider zusagen, wir nicht.
Zertifikate, Audit-Freigaben und Konformitätserklärungen
Die technische Umsetzung in Richtung ISO 27001, NIS2 oder AI Act gehört zur Arbeit. Das Testat ausstellen darf nur eine akkreditierte Prüfstelle — dafür braucht es einen Auditor, keinen Ingenieur.
Projekte ohne eigenes Entwicklungsteam
Wissenstransfer ist fester Bestandteil jeder Zusammenarbeit. Ohne Team, das übernimmt, wird daraus dauerhaftes Outsourcing — ein Modell, das wir nicht anbieten.
Festpreis für eine Gesamttransformation, bevor jemand hineingesehen hat
Eine ungeprüfte Legacy-Landschaft zu bepreisen ist Raten. Wir schätzen nach einer kurzen Analyse — und sagen auch, wenn sich der Umbau nicht lohnt.
Häufige Fragen zum Cluster-Betrieb
Betreibt ihr den Cluster danach für uns?
Nein. Wir bringen die Umgebung in einen Zustand, den euer Team betreiben kann, und übergeben sie. Rufbereitschaft und SLA-gebundene Betriebsverantwortung bietet ein Managed-Service-Provider an, wir nicht.
Wir nutzen einen verwalteten Kubernetes-Dienst. Passt das trotzdem?
Ja. Ob EKS, AKS, GKE oder eine eigene Installation ändert, wer die Control Plane betreibt — nicht die acht Aussagen oben. Was euer Anbieter bereits abdeckt, steht entsprechend im Ergebnis.
Müssen wir dafür alles neu aufsetzen?
Nein. In den meisten Fällen existieren ein Cluster, ein paar Manifeste und eine Pipeline. Wir arbeiten damit weiter und bauen nur das neu, wofür wir einen Grund nennen können.
Wie geht ihr mit einem laufenden Betrieb um?
Änderungen nehmen denselben Weg wie eure eigenen: Pull Request, Review, Rollout in einer Vorstufe. Für die Eingriffe, die sich nicht vorher proben lassen, steht der Rückweg vorher fest.
Was, wenn ihr im Review zu dem Schluss kommt, dass Kubernetes falsch ist?
Dann steht das im Ergebnis, mit der Alternative daneben. Der Abschnitt weiter oben ist nicht rhetorisch gemeint: Wir haben Anfragen abgesagt, weil eine verwaltete Plattform die günstigere Antwort war.
Wie schnell könnt ihr anfangen?
Wir führen nur wenige Projekte parallel, deshalb klären wir die Verfügbarkeit vor dem Angebot. Im Fit-Check nennen wir einen realistischen Starttermin, auch wenn er später liegt als gewünscht.
Ist euer Cluster produktionsreif?
Ein Gespräch über den Zustand eurer Umgebung — und eine ehrliche Einschätzung, ob Kubernetes für euren Fall die richtige Wahl ist.