Irgendwann kommt der Moment, in dem die Empfehlung auf dem Tisch liegt: Man solle auf Kubernetes setzen. Modern, skalierbar, zukunftssicher. Die Technologie ist ausgereift, die Community groß, die Referenzlisten beeindruckend.

All das stimmt. Die Frage ist nicht, ob Kubernetes funktioniert. Die Frage ist, welches Problem es löst – und ob dieses Problem im eigenen Unternehmen überhaupt existiert.

Was tatsächlich steht

Ein Unternehmen mit bis zu 150 Mitarbeitern hat meist eine überschaubare Infrastruktur. Zwei, vielleicht drei physische Server. Darauf laufen virtuelle Maschinen – ein Domänencontroller, ein Fileserver, ein Terminalserver, vielleicht ein Applikationsserver und ein Update-Verwaltungssystem. Daneben eine Handvoll containerisierter Dienste: eine Datenbank, ein Cache, ein Reverse Proxy, vielleicht ein Identity-Management-System.

Fünf bis zwanzig Container auf zwei, drei Servern. Jeder davon läuft als Einzelinstanz – kein horizontales Scaling, keine Redundanz, kein automatisches Failover. Nicht weil die IT schlecht aufgestellt ist, sondern weil diese Infrastruktur für diesen Zweck vollkommen ausreichend ist.

Wofür Kubernetes gebaut wurde

Kubernetes wurde entwickelt, um zehntausende Container auf tausenden Servern zu orchestrieren. Automatisches Rescheduling bei Node-Ausfall, Service Discovery für hunderte parallel laufende Dienste, Rolling Deployments ohne Downtime in Umgebungen, die täglich mehrfach aktualisiert werden.

Diese Anforderungen existieren. Bei Google, bei Netflix, bei Plattformen mit Millionen gleichzeitiger Nutzer.

Zwanzig Container auf drei Servern haben andere Anforderungen. Sie brauchen etwas, das sie zuverlässig startet – in der richtigen Reihenfolge, nach einem Neustart, ohne manuelle Intervention. Das ist ein gelöstes Problem. Es war bereits gelöst, bevor Kubernetes existierte.

Die Personalfrage – und was dahintersteckt

Der eigentliche Gedanke hinter Automatisierung ist richtig: Repetitive, manuelle Aufgaben sollen durch Technik übernommen werden – damit qualifizierte Mitarbeiter ihre Zeit für wertschöpfende Tätigkeiten nutzen können. Das ist kein Selbstzweck, das ist wirtschaftlich sinnvoll.

Kubernetes verspricht genau das. In der Praxis des Mittelstands dreht es den Gedanken jedoch um: Anstatt Kapazität freizusetzen, bindet es sie. Zertifikatsrotation, Cluster-Upgrades, Zugriffskontrolle, Netzwerk-Konfiguration – das ist eine Vollzeitstelle. In Unternehmen, die Kubernetes ernsthaft betreiben, sind es mehrere.

Derzeit gibt es im Mittelstand mehrheitlich keine dedizierte Stelle dafür. Es gibt einen Administrator, der auch die Telefonanlage betreut, die Drucker wartet und gelegentlich erklärt, warum der Laptop des Geschäftsführers sich nicht mehr mit dem WLAN verbindet. Dieser Administrator soll nun nebenbei einen Kubernetes-Cluster betreiben.

Das Ergebnis ist vorhersehbar: Der Cluster läuft, solange nichts passiert.

PS. Wenn etwas passiert, passiert es meistens freitags.

Die Cloud-Rechnung

Wer die Personalkosten scheut, kann den Betrieb an Hyperscaler wie Microsoft, Amazon oder Google auslagern. Deren verwaltete Dienste nehmen den operativen Overhead ab – gegen eine monatliche Rechnung, die mit der Nutzung wächst und deren Höhe schwer vorherzusagen ist.

Was dabei unterschätzt wird, sind nicht die Kosten allein. Es ist die Abhängigkeit, die entsteht: Wer seine Infrastruktur vollständig in einen solchen Dienst überführt hat, ist auf dessen Verfügbarkeit angewiesen. Fällt die Internetverbindung aus, steht der Betrieb. Steigt der Anbieter aus dem Markt aus oder ändert seine Konditionen, sind die Optionen begrenzt. Und sensible Geschäftsdaten – Mandanteninformationen, Patientendaten, Fertigungsgeheimnisse – liegen auf Infrastruktur, die man nicht kontrolliert, in Rechenzentren, deren genaue Lage vertraglich „irgendwo in der EU" bedeutet.

Wer einmal vollständig migriert ist, kehrt nicht ohne weiteres zurück. Nicht weil es technisch unmöglich wäre – sondern weil niemand die Zeit hat, es zu tun.

Was stattdessen funktioniert

Zwanzig Container auf drei Servern brauchen keine Orchestrierungsplattform. Diese Basis bringt das Betriebssystem bereits von Haus aus mit. Kombiniert mit ressourcenschonenden Container-Engines wie Podman lassen sich Dienste verwalten – ohne externe Orchestrierungs-Monster. Ihr Verhalten ist seit Jahren dokumentiert und vorhersehbar, ihre Konfiguration liegt offen vor – lesbar, versionierbar, auditierbar.

Ein wesentlicher Aspekt dabei: Container sollten ohne erweiterte Systemrechte betrieben werden. Was bedeutet das konkret? Ein Container, der mit vollen Administratorrechten läuft, kann im Fehlerfall – oder nach einer Kompromittierung durch Angreifer – auf das gesamte System zugreifen. Daten können abfließen, andere Dienste können manipuliert werden, der Schaden breitet sich aus. Ein Container ohne diese Rechte bleibt in seiner eigenen Umgebung eingesperrt. Was dort passiert, bleibt dort. Das ist kein akademisches Sicherheitskonzept – das ist der Unterschied zwischen einem kontrollierten Vorfall und einem vollständigen Datenverlust.

Wie Daten in diesem Modell gesichert und wiederhergestellt werden, ist ein eigenes Thema – und ein ebenso unterschätztes.

Das klingt unspektakulär. Das ist der Punkt.

Eine Infrastruktur, die niemanden überrascht, die nach einem Stromausfall ohne manuelle Intervention wieder läuft, die von zwei Leuten vollständig verstanden und betreut werden kann – das ist keine Kompromisslösung. Das ist das Ziel.

Kontrolle über die Infrastruktur ist Kontrolle über die Daten

Eine Umgebung, die ohne externe Cloud-Abhängigkeit auskommt, läuft auf eigenen Servern oder auf dedizierten Maschinen beim Hoster des Vertrauens. Die Daten liegen dort, wo der Betreiber sie hinlegt.

Für eine Kanzlei, eine Praxis, ein Unternehmen mit sensiblen Kundendaten ist das keine abstrakte Überlegung. Es ist eine konkrete Anforderung – an Datenschutz, an Mandantenvertrauen, an das eigene Risikomanagement. Diese Anforderung lässt sich mit einer überschaubaren, selbst betriebenen Infrastruktur, die jeder im Team vollständig versteht, zuverlässiger erfüllen als mit einer verteilten Plattform, deren Komplexität niemand mehr vollständig überblickt.

Die eigentliche Frage

Welches konkrete Problem soll gelöst werden – und existiert dieses Problem hier?

Kubernetes ist die richtige Antwort auf eine bestimmte Klasse von Problemen. Diese Probleme sind real. Sie entstehen bei einer Größenordnung und Komplexität, die der Mittelstand in aller Regel nicht hat – und nicht anstreben muss.

Die richtige Technologie für den richtigen Zweck. Das ist keine Einschränkung. Das ist eine Entscheidung.