Kubernetes im Mittelstand — Wann es sich lohnt und wann nicht

Kaum eine Technologie polarisiert im Mittelstand so stark wie Kubernetes. Auf der einen Seite verspricht sie Standardisierung, Auto-Scaling, deklarative Infrastruktur und eine Sprache, die alle modernen Cloud-Anbieter sprechen. Auf der anderen Seite ist Kubernetes eine der komplexesten Plattformen, die ein IT-Team betreiben kann — mit eigener Lernkurve, eigenen Sicherheits-Themen und einem laufenden Wartungs-Aufwand, der viele kleinere Häuser überfordert. Die richtige Frage ist deshalb nicht „Kubernetes ja oder nein“, sondern: passt diese Plattform zu meiner Anwendungs-Topologie, zu meiner Team-Größe und zu meinem realen Skalierungs-Bedarf. Dieser Artikel ordnet die Entscheidung sachlich ein, zeigt typische Fehl-Investitionen, vergleicht Managed-Angebote und Self-hosted-Distributionen, und beziffert die realen Betriebs- und Lizenzkosten kleiner und mittlerer Cluster. Für den Gesamtkontext siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Warum Kubernetes-Entscheidungen Geschäftsführungs-Risiko sind

Eine Kubernetes-Einführung berührt drei Kostenblöcke gleichzeitig — Infrastruktur, Personal und Geschwindigkeit. Wer die Plattform zu früh einführt, baut Komplexität auf, ohne den passenden Nutzen zu haben: ein zweiköpfiges IT-Team verbringt dann mehrere Wochen pro Quartal mit Upgrades, Zertifikats-Rotation und CNI-Themen statt mit produktiver Entwicklung. Wer Kubernetes zu spät einführt, sammelt parallel laufende „Server-Inseln“ mit individuellen Skripten und uneinheitlichen Deployment-Wegen — die Zeit, jede neue Anwendung produktiv zu setzen, steigt von Tagen auf Wochen.

Hinzu kommen zwei regulatorische Hebel. Erstens NIS2: viele mittelständische Unternehmen fallen seit Oktober 2024 unter erweiterte Sorgfaltspflichten, und eine deklarative Plattform mit Audit-Trail vereinfacht Nachweis-Pflichten erheblich. Zweitens ISO 27001 in der Fassung 2022 mit Control A.8.9 (Configuration Management) und A.8.32 (Change Management) — Kubernetes mit GitOps liefert hier per Design eine prüfbare Historie, die manuell betriebene VM-Landschaften meist nicht haben. Beide Punkte sprechen für die Plattform — aber nur, wenn das Team sie auch sicher betreibt.

Aus unserer Beratungs-Praxis sehen wir drei Muster, in denen Kubernetes wirtschaftlich gut funktioniert und drei, in denen es regelmäßig schiefgeht. Die nächsten Abschnitte arbeiten diese Muster heraus.

Was Kubernetes 2026 wirklich löst

Kubernetes ist eine deklarative Orchestrierungs-Plattform für Container. Ihr Kern-Versprechen ist: man beschreibt den gewünschten Soll-Zustand in YAML, und der Cluster sorgt dafür, dass dieser Zustand erreicht und gehalten wird — auch wenn Knoten ausfallen oder Last steigt. Im Jahr 2026 ist die Plattform reif: die zentralen Schnittstellen — CRI für Container-Runtimes, CNI für Netzwerk, CSI für Storage — sind stabil, die wichtigsten Distributionen sind zertifiziert, und das Ökosystem aus Helm, Argo CD, Cilium, Linkerd und cert-manager deckt fast alle produktiven Anforderungen ab.

Konkret löst Kubernetes vier Probleme besonders gut. Erstens Standardisierung: Hundert Services aus zwanzig Teams sehen aus Betriebs-Sicht gleich aus — gleiche Health-Checks, gleiche Log-Wege, gleiche Update-Strategie. Zweitens horizontale Skalierung: bei sauber gebauten Workloads wachsen und schrumpfen die Replikate automatisch mit der Last. Drittens Multi-Umgebung: Staging, Pre-Prod und Produktion sind Namespaces oder Cluster, deren Konfigurations-Unterschiede minimal und versionierbar sind. Viertens Wiederherstellbarkeit: ein vollständiger Cluster-Neuaufbau aus Git ist innerhalb weniger Stunden möglich, wenn die Anwendungen sauber als Helm-Charts beschrieben sind.

Wann Kubernetes übertrieben ist

Drei Szenarien sprechen klar gegen Kubernetes — auch wenn die Geschäftsführung davon gehört hat und der Wettbewerber damit wirbt:

• Mono-Anwendung ohne ModularisierungEin einzelnes ERP, ein einzelnes Vertriebs-System oder ein Monolith ohne klare Service-Grenzen profitiert kaum von Kubernetes. Die zusätzliche Plattform-Komplexität liefert keinen messbaren Nutzen, und die Anwendung ist meist nicht für rolling updates oder mehrere Replikate ausgelegt. Klassische VMs mit Backups und einem Reverse Proxy sind hier wirtschaftlicher.
• IT-Team unter drei PersonenKubernetes braucht laufende Aufmerksamkeit — Upgrades, Patches, Zertifikate, Monitoring-Anpassungen. Wenn das gesamte IT-Team unter drei Personen liegt und davon nur eine Person Plattform-Erfahrung hat, ist ein einzelnes Krankheits- oder Urlaubs-Fenster ein Risiko. In dieser Größe ist ein Platform-as-a-Service wie Hetzner Cloud Apps, Render oder Fly.io oft die bessere Wahl.
• Geringe und sehr stabile LastWenn die Anwendung eine planbare, geringe Last hat — typische interne Tools, Buchhaltungs-Systeme, kleine Branchen-Anwendungen — gibt es kein Auto-Scaling-Problem, das Kubernetes lösen müsste. Eine VM, ein Backup-Job und ein Monitoring-Agent reichen.

In allen drei Fällen lohnt sich Kubernetes erst, wenn ein zweiter oder dritter Treiber dazu kommt — etwa der Wunsch nach Self-Service für Entwickler-Teams, eine bevorstehende Architektur-Modernisierung in mehrere Services oder ein konkretes Compliance-Audit, das deklarative Plattformen begünstigt.

Wann Kubernetes wirklich sinnvoll ist

Spiegelbildlich gibt es drei Szenarien, in denen Kubernetes deutlich mehr Wert liefert, als es an Komplexität kostet:

• Microservices oder modularer MonolithWenn die Anwendung in mindestens fünf bis zehn unabhängig deploybare Services aufgeteilt ist, liefert Kubernetes pro Service den gleichen Standard-Rahmen — Health, Logs, Updates, Skalierung. Der Plattform-Overhead amortisiert sich schnell, weil jedes neue Team-Onboarding schneller geht.
• Mehrere Umgebungen mit häufigen ReleasesStaging, Pre-Prod, Produktion und gegebenenfalls Test-Umgebungen pro Pull-Request sind in Kubernetes per Namespace fast trivial. In klassischer VM-Welt ist jede zusätzliche Umgebung ein eigener Server-Bauplan mit doppeltem Pflege-Aufwand.
• Lastspitzen mit klarem Skalierungs-BedarfSaisonale Peaks (Black Friday, Steuerstichtage, Schul-Anmeldungen), event-getriebene Lasten oder asynchrone Batch-Verarbeitung profitieren stark von Horizontal Pod Autoscaler und Cluster Autoscaler. Hier rechtfertigt der Skalierungs-Mechanismus die Plattform-Investition alleine.

Managed Kubernetes im Vergleich

Wenn die Entscheidung für Kubernetes gefallen ist, steht als nächstes die Anbieter-Frage. Der Markt teilt sich grob in drei Lager: Hyperscaler mit globaler Reichweite, europäische Anbieter mit DSGVO-Fokus und schlanke Managed-Angebote für kleinere Cluster. Die folgende Übersicht ordnet die wichtigsten Anbieter ohne Detail-Ranking — die Wahl hängt von Datenstandort, Integrations-Tiefe und Budget ab.

Anbieter	Stärken	Typische Eignung	Control-Plane-Preis
Amazon EKS	Größtes Ökosystem, viele Integrations-Module, weltweite Regionen	Bestehende AWS-Landschaft, internationaler Datenverkehr	ca. 70 €/Monat pro Cluster
Microsoft AKS	Tiefe Azure-AD-Integration, Windows-Workloads möglich	Microsoft-affine Unternehmen, hybride Szenarien	0 € Control-Plane, Knoten zahlen
Google GKE	Reifste Auto-Scaling- und Upgrade-Automatik, Autopilot-Modus	Daten-lastige Workloads, Machine-Learning-Pipelines	ca. 70 €/Monat (außer Autopilot)
OVHcloud Managed K8s	EU-Datenstandort, DSGVO-konform, transparente Preise	DACH-Unternehmen mit Datenschutz-Anforderungen	0 € Control-Plane
Hetzner-managed (Partner)	Günstige VMs, EU-Datenstandort, kleine Cluster sehr preiswert	Startup, KMU mit knappem Budget	variabel je Partner
Scaleway Kapsule	Französischer Anbieter, EU-Datenstandort, faire Preise	DACH/FR-Mittelstand mit moderaten Lasten	0 € Control-Plane

Für den deutschen Mittelstand mit klarer DSGVO-Anforderung sind OVHcloud, Scaleway und Hetzner-managed-Angebote häufig die wirtschaftlichste Wahl. Wer ohnehin AWS oder Azure nutzt, sollte beim Hyperscaler bleiben — die Integration in IAM, Logging und Datenbanken spart mehr Aufwand, als die Control-Plane-Gebühr ausmacht.

Self-hosted Kubernetes — wann ja

Self-hosted ist keine Sparmaßnahme, sondern eine Architektur-Entscheidung. Drei Distributionen sind im Mittelstand relevant. kubeadm ist das offizielle Upstream-Werkzeug der Kubernetes-Community, ideal für Teams, die Full-Control wollen, aber bereit sind, jede Upgrade-Stufe selbst zu planen. k3s aus dem SUSE-Umfeld ist eine schlanke Distribution, die Etcd durch SQLite ersetzen kann und auf kleinen Servern produktiv läuft — die häufigste Wahl für mittelständische Edge- oder Branch-Cluster. RKE2, ebenfalls SUSE, ist die hardened Variante mit CIS-konformen Defaults, sinnvoll für regulierte Branchen und behördennahe Umgebungen.

Self-hosted lohnt sich, wenn drei Bedingungen erfüllt sind: das Team hat oder baut interne Plattform-Kompetenz auf, die Datenstandort-Anforderungen sind so spezifisch, dass kein Managed-Anbieter passt, und das Cluster soll langfristig stehen. Für temporäre Setups oder erste Schritte in die Welt der Container ist Managed fast immer die bessere Wahl. Wer Self-hosted geht, sollte außerdem von Anfang an mit GitOps arbeiten — sonst entsteht eine schwer pflegbare Kombination aus manuellen kubectl-Eingriffen und vergessenen Änderungen, die im Krisenfall nicht reproduzierbar ist.

Realistischer Betriebsaufwand

Eine ehrliche Aufwands-Schätzung ist die häufigste Lücke in Kubernetes-Business-Cases. Die folgende Tabelle fasst typische Wartungs-Zeiten zusammen — sie ist als Orientierung gedacht und variiert je nach Cluster-Größe, Anwendungen und Compliance-Anforderung.

Aufgabe	Frequenz	Managed	Self-hosted
Kubernetes-Minor-Upgrade	3-4× pro Jahr	0,5-1 Tag pro Cluster	2-4 Tage pro Cluster
OS-Patches der Knoten	monatlich	automatisch	0,5-1 Tag pro Monat
Zertifikat-Rotation	jährlich automatisch	automatisch	0,5 Tag
Etcd-Backups + Restore-Tests	monatlich	automatisch	0,5-1 Tag pro Monat
Sicherheits-Patches kritisch	ad hoc	1-4 Std. Reaktion	4-16 Std. Reaktion
Add-on-Pflege (Ingress, CNI, cert-manager)	quartalsweise	1 Tag pro Quartal	2-3 Tage pro Quartal

Über das Jahr summiert sich der Self-hosted-Aufwand für einen mittelgroßen Cluster typischerweise auf 25 bis 45 Personentage — also rund 15 bis 25 Prozent einer Vollzeit-Stelle. Bei Managed-Kubernetes sinkt dieser Wert auf 5 bis 12 Personentage pro Jahr. Wer diesen Unterschied unterschätzt, baut auf dem Papier ein günstiges Self-hosted-Setup und stellt nach sechs Monaten fest, dass das Team produktive Arbeit liegen lässt.

Storage und Netzwerk

Container brauchen persistenten Speicher und ein klar definiertes Netzwerk. Drei Standard-Schnittstellen prägen die Architektur. CSI (Container Storage Interface) bindet Block- und Datei-Speicher von Cloud-Anbietern oder On-Premises-Systemen an. CNI (Container Network Interface) liefert das Pod-Netzwerk — Cilium ist seit 2024 die De-facto-Wahl, weil es eBPF-basiert performant und gleichzeitig sichtbar ist. Ingress-Controller wie ingress-nginx, Traefik oder das neuere Gateway API von Envoy übernehmen die Anbindung an externe HTTP-Lasten.

Optional kommt ein Service-Mesh hinzu — Linkerd für Teams, die einen schlanken, sicheren mTLS-Layer wollen, Istio für Teams mit hohem Routing- und Observability-Bedarf. Für mittelständische Cluster reicht häufig ein gutes Ingress-Setup plus NetworkPolicies aus; ein Service-Mesh wird oft eingeführt, wenn mehrere Teams unabhängige Services produktiv laufen und ein konsistentes Sicherheits-Modell brauchen. Mehr Hintergrund zur Container-Wahl im Cluster gibt unser Vergleich Docker vs. Podman.

Helm und GitOps für Deployments

Helm ist der etablierte Paket-Manager für Kubernetes: jede Anwendung wird als Chart verpackt — Templates plus Werte-Datei — und mit einer einzigen Operation installiert oder aktualisiert. Für interne Anwendungen lohnt sich ein eigenes Chart-Repository (zum Beispiel ein OCI-Registry-Pfad), für externe Komponenten genügt der Public-Chart-Pull.

GitOps geht einen Schritt weiter: der gewünschte Cluster-Zustand liegt in einem Git-Repo, und ein Controller (Argo CD oder Flux) synchronisiert kontinuierlich. Vorteile sind nachvollziehbar: jeder Zustands-Wechsel ist ein Commit, Rollbacks sind ein Git-Revert, und neue Cluster sind durch Klonen des Repos aufgebaut. Für Audit-Anforderungen ist das ein Quantensprung gegenüber manuellen kubectl-Workflows. Detaillierter zum Vergleich der GitOps-Werkzeuge siehe unseren Artikel GitOps mit Argo CD und Flux.

Sicherheit im Cluster

Kubernetes-Sicherheit ist ein eigenes Feld. Vier Schichten sind im Mittelstand Pflicht — alles darüber hinaus ist optional und Risiko-getrieben.

• RBAC sauber definiertRole-Based Access Control regelt, wer im Cluster was darf. Die Standard-Falle ist „cluster-admin für alle Entwickler“ — das ist bequem, aber bei einem fehlerhaften Skript fatal. Ein Namespace-getrennter RBAC mit Service-Accounts pro Anwendung und Personen-Rollen pro Team ist die Mindest-Reife.
• Pod-Security-StandardsSeit Kubernetes 1.25 ist Pod Security Admission der Standard. Drei Profile — privileged, baseline, restricted — decken die wichtigsten Szenarien ab. Produktions-Namespaces sollten standardmäßig restricted laufen, mit ausdrücklicher Begründung pro Ausnahme.
• NetworkPolicies pro NamespaceStandard-Kubernetes erlaubt jedem Pod, mit jedem anderen Pod zu sprechen. Das ist im Vorfallsfall problematisch. NetworkPolicies — am besten über Cilium oder Calico — beschränken den Pod-zu-Pod-Verkehr auf das, was die Anwendung tatsächlich braucht.
• Image-Scanning in der PipelineJedes Container-Image sollte vor dem Push in die Registry auf bekannte Schwachstellen geprüft werden — Trivy und Grype sind die etablierten Open-Source-Werkzeuge, kommerzielle Alternativen sind Aqua und Sysdig. Critical-Findings sollten den Build stoppen, Mittel- und Niedrig-Findings dokumentiert werden.

Wer Observability ernst nimmt, ergänzt diese vier Schichten um zentrale Audit-Logs und Laufzeit-Anomalie-Erkennung. Mehr dazu in unserem Artikel Observability-Monitoring-Stack.

Kosten-Beispiele kleiner und mittlerer Cluster

Konkrete Zahlen helfen bei der Entscheidung. Die folgenden Beispiele zeigen typische Monatskosten für drei Cluster-Größen — sie sind Mittelwerte aus realen Projekten und schließen Worker-Knoten, Load-Balancer, Speicher und Datenverkehr ein, jedoch nicht Personalaufwand.

Cluster-Größe	Hetzner-managed/Scaleway	OVHcloud Managed	EKS/AKS/GKE
Klein (3 Knoten, 12 vCPU, 24 GB RAM)	120-180 €	180-250 €	250-400 €
Mittel (6 Knoten, 24 vCPU, 48 GB RAM)	250-380 €	380-550 €	500-800 €
Größer (12 Knoten, 48 vCPU, 96 GB RAM)	500-750 €	750-1.100 €	1.000-1.800 €

Die Hyperscaler-Preise enthalten häufig Daten-Transfer-Kosten, die in europäischen Angeboten deutlich niedriger oder pauschal sind — bei viel Datenverkehr ist die EU-Variante real spürbar günstiger. Self-hosted auf Hetzner-Dedicated kann nochmal 30 bis 50 Prozent unter den Managed-Werten liegen, kostet aber die oben dokumentierten Personentage zusätzlich.

Reepa-Kubernetes-Coaching

Wir begleiten mittelständische Teams in zwei Modellen. Erstens das Architektur-Erstgespräch: ein 90-minütiges Gespräch mit Architektur-Review, Anbieter-Empfehlung und ehrlichem Kostenrahmen — auch mit dem Ergebnis „Sie brauchen kein Kubernetes“, wenn das die richtige Antwort ist. Zweitens das mehrwöchige Coaching, in dem wir gemeinsam mit dem Team einen ersten produktiven Cluster aufbauen, GitOps einführen, die Sicherheits-Schichten konfigurieren und das interne Team auf den laufenden Betrieb vorbereiten. Wir installieren bewusst keine Black-Box-Plattform, sondern dokumentierte, reproduzierbare Bausteine, die das Team langfristig selbst pflegen kann.

Häufige Fragen