Kubernetes im eigenen Rechenzentrum

Der Hype um Kubernetes ist längst in der Realität angekommen. Doch während der Betrieb in der Public Cloud oft per Mausklick startet, stehen IT-Entscheider im eigenen Rechenzentrum vor einer gewaltigen Hürde: Die Komplexität des Eigenbetriebs.

Oft scheitern Projekte nicht an der Technologie selbst, sondern am sogenannten Day-2-Aufwand – also der Frage: Wie halten wir das System sicher, verfügbar und vor allem kontrollierbar?

In diesem Beitrag zeige ich Ihnen eine bewährte Architektur, die klein startet, aber professionellen Ansprüchen an Hochverfügbarkeit und Betriebssicherheit gerecht wird.

Die Qual der Wahl: Distributionen im Vergleich

Bevor wir über Server sprechen, müssen wir über das “Betriebssystem” des Clusters entscheiden.

Red Hat OpenShift: Der “Enterprise-Panzer”

OpenShift ist das Rundum-sorglos-Paket inklusive Registry, Monitoring und striktem Security-Hardening.

Vorteil: Voller Herstellersupport, sehr sicher.
Nachteil: Hohe Lizenzkosten und eine Komplexität, die meist eine dedizierte Mannschaft oder einen starken Partner erfordert.

Die schlanken Alternativen: RKE2, K3s & Vanilla

Wenn Sie maximale Flexibilität und geringeren Overhead suchen:

RKE2 / K3s: Von SUSE/Rancher entwickelt, extrem einfach zu installieren und bereits im Standard sehr sicher (“Hardened by Design”).
Vanilla (kubeadm): Der pure Standard. Maximale Kontrolle, aber auch hoher manueller Aufwand bei Updates.

Die Architektur: Schlank, aber hochverfügbar

Ein häufiger Fehler ist es, Kubernetes “irgendwie” auf ein paar Servern zu installieren. Für den produktiven Betrieb empfehle ich ein Setup, das auf bestehende Virtualisierungs-Strukturen (VMware, Proxmox) aufsetzt.

1. Das Fundament (Compute)

3x Control Plane Nodes: Starten Sie nicht mit nur einem Master. Drei Nodes sind das Minimum für ein belastbares Quorum (etcd).
2-5 Worker Nodes: Hier laufen Ihre Anwendungen. Diese Ebene kann später problemlos horizontal wachsen.

2. Networking & Loadbalancing

Damit Ihre Dienste erreichbar sind, benötigen Sie einen stabilen Eingangspunkt:

Die bewährte Lösung: 2 VMs mit HAProxy und Keepalived. Diese stellen eine virtuelle IP (VIP) bereit und leiten den Traffic an die Control Plane (API) und die Worker (Ingress) weiter.
Die Cloud-Native Option: MetalLB. Dies simuliert einen Loadbalancer-Service.

Hinweis: Im professionellen Umfeld funktioniert MetalLB am besten im BGP-Modus, was jedoch eine entsprechende Unterstützung durch Ihre Netzwerk-Infrastruktur voraussetzt.

3. Ingress & Automatisierte Sicherheit

Als Ingress-Controller empfehle ich Traefik. Um den Day-2 Aufwand für SSL-Zertifikate zu eliminieren, ist der cert-manager unverzichtbar. Er automatisiert die Ausstellung und Erneuerung von TLS-Zertifikaten (via Let’s Encrypt oder interner PKI).

Observability: Wissen statt Raten

Ein Cluster ohne tiefen Einblick ist ein schwarzes Loch. Um den Betrieb stabil zu halten, setzen wir auf den bewährten Open-Source-Stack für maximale Transparenz:

Prometheus: Das Herzstück für das Sammeln von Metriken. Es überwacht die Performance des Clusters und der Anwendungen in Echtzeit.
Grafana: Die Visualisierungs-Ebene. Hier fließen alle Daten in Dashboards zusammen, die Ihnen auf einen Blick den Gesundheitszustand Ihrer Infrastruktur zeigen.
Loki: Das “Google für Ihre Logs”. Es ermöglicht eine effiziente Log-Analyse direkt in Grafana, ohne die Kosten- und Ressourcenfalle klassischer ELK-Stacks.

Ihr Vorteil: Fehlerquellen werden in Minuten statt Stunden identifiziert (MTTR - Mean Time To Repair).

Business Continuity: Backup & Storage

Ein Cluster ohne Backup-Strategie ist ein Risiko. Sie benötigen Werkzeuge, die “Applikations-bewusst” sichern:

Storage: Direkte Anbindung vorhandener Systeme (NetApp, vSphere, Ceph) via CSI oder Nutzung von Rook für verteiltes Storage auf den Workern.
Backup-Tools: Velero als starker Open-Source-Standard oder Veeam Kasten K10 für die nahtlose Integration in bestehende Enterprise-Backup-Umgebungen.

Der Weg in den Betrieb: GitOps statt manueller Klicks

Vermeiden Sie “Click-Ops”.

Start: Gießen Sie Deployments in Helm Charts oder Kustomize.
Ziel: Wechseln Sie nach der PoC-Phase zügig auf ein GitOps-Modell (z.B. mit ArgoCD oder Flux).

Der Vorteil: Der Cluster-Zustand liegt in einem Git-Repository. Das reduziert den Day-2 Aufwand massiv, da Änderungen nachvollziehbar sind und der Cluster im Ernstfall per Knopfdruck wiederhergestellt werden kann.

Fazit: Klein anfangen, groß denken

Kubernetes im eigenen RZ scheitert meist an zu hohen Ambitionen zu Beginn. Mein Rat: Klein anfangen und Stück für Stück erweitern. Nicht alles muss sofort auf Kubernetes. Starten Sie mit unkritischen Diensten, etablieren Sie Backup- und Monitoring-Prozesse und wachsen Sie mit der Erfahrung.

Gemeinsam den Grundstein legen

Die Theorie ist das eine, die Umsetzung in der eigenen Infrastruktur das andere. Um teure Fehlentscheidungen zu vermeiden, unterstütze ich Sie gerne direkt.

Mein Angebot: 1-Tages Kubernetes-Architektur-Workshop Wir analysieren Ihre Infrastruktur und entwerfen gemeinsam den Blueprint für Ihren Cluster – von der IP-Planung über Observability bis zur Backup-Strategie.

Interesse an einem stabilen Fundament? Kontaktieren Sie mich für ein unverbindliches Erstgespräch.