Jenseits der Virtualisierung – Warum echte Unabhängigkeit Cloud-Native denkt
Viele Unternehmen glauben, sie seien modern, nur weil sie ihre Server virtualisieren. Doch die Zukunft liegt nicht in der Virtualisierung, sondern in der Orchestrierung.
SerieDigitale Souveränität
Teil 5 von 6
Viele Unternehmen glauben, sie seien modern, nur weil sie ihre Server virtualisieren. In Wirklichkeit schleppen sie damit die Infrastruktur der 2000er in Container der 2020er. Wer digitale Unabhängigkeit will, muss tiefer gehen – unter die Hypervisor-Schicht.
Denn die Zukunft liegt nicht in der Virtualisierung, sondern in der Orchestrierung.
1. Virtualisierung – eine Übergangstechnologie, die zu lange blieb
Virtualisierung war einmal revolutionär. VMware, Hyper-V oder Xen machten es möglich, Hardware effizienter zu nutzen, Ressourcen zu teilen und Systeme voneinander zu isolieren.
Aber sie waren nie dafür gedacht, dynamische, skalierbare Workloads zu betreiben, wie sie moderne Software braucht. Jede VM ist im Grunde ein Mini-Server – mit eigenem Kernel, Betriebssystem und Speicherverbrauch.
Die Grenzen der Virtualisierung
Diese Architektur funktioniert, solange man statische Anwendungen betreibt. Sobald man aber tausende Microservices orchestrieren will, wird sie zur Bremse:
- Startzeiten im Minutenbereich statt Sekunden.
- Ineffiziente Ressourcennutzung durch Overhead.
- Schwerfällige Migration, selbst in der Cloud.
Kurz: Virtualisierung war eine Brücke – aber Europa steht immer noch drauf, anstatt endlich rüberzugehen.
2. Kubernetes – das Betriebssystem der Cloud
Kubernetes ist nicht einfach ein Tool, es ist ein Paradigmenwechsel. Es abstrahiert Anwendungen von der Infrastruktur – egal, ob darunter ein Server, ein Rechenzentrum oder ein halbes Land steht.
Neu bei Kubernetes? Eine umfassende Einführung findest du in unserem Artikel Kubernetes erklärt – Was Container-Orchestrierung wirklich bedeutet.
Statt virtuelle Maschinen zu verwalten, verwaltet Kubernetes Container – leichtgewichtige, portable Einheiten, die nur das enthalten, was wirklich gebraucht wird.
Warum Container souveräner sind
Das ist nicht nur effizienter, sondern auch souveräner:
- Container sind hardware-agnostisch.
- Sie können auf Bare Metal, Private Clouds oder Public Clouds laufen.
- Der Orchestrator ist austauschbar – solange die API bleibt, bleibt die Portabilität.
Damit verschiebt sich die Kontrolle von der Hardware- zur Softwareebene. Wer Kubernetes beherrscht, braucht keinen VMware-Konzern, um Systeme zu skalieren.
Exkurs: Die Erfinder von Kubernetes – Innovation aus Notwendigkeit
Kubernetes entstand 2014 bei Google aus einem konkreten Bedarf heraus. Das Unternehmen betrieb intern seit über einem Jahrzehnt ein System namens Borg, später Omega, um Millionen von Containern über Tausende Server zu orchestrieren. Diese Systeme waren zentral für Googles Fähigkeit, globale Dienste wie Gmail, YouTube oder die Suchmaschine zu skalieren.
Joe Beda, Brendan Burns und Craig McLuckie – drei Google-Ingenieure – erkannten, dass diese Art von Orchestrierung nicht nur Google, sondern der gesamten Industrie fehlt. Sie begannen, die Konzepte von Borg in ein Open-Source-Projekt zu übersetzen, das jeder nutzen kann: Kubernetes (griechisch für „Steuermann”).
Was sie schufen, war mehr als ein Tool – es war eine neue Denkweise über Infrastruktur. Kubernetes machte Cloud-Native überhaupt erst möglich, indem es eine einheitliche API für Container-Orchestrierung schuf, unabhängig von der darunterliegenden Hardware oder Cloud-Plattform.
Ohne Kubernetes gäbe es heute keine moderne Microservices-Architektur, keine effiziente KI-Infrastruktur, keine schnellen CI/CD-Pipelines. Es ist eines der stärksten und nachhaltigsten Open-Source-Projekte, das je entstanden ist – und es bleibt vollständig offen und herstellerneutral unter der Cloud Native Computing Foundation (CNCF).
Diese Innovation aus Notwendigkeit hat die gesamte Industrie verändert. Kubernetes ist nicht nur Werkzeug, sondern Fundament – für Cloud-Native, für KI-Workloads, für digitale Souveränität.
3. Kubernetes braucht keine VM – aber es kann mit ihr leben
Ein verbreiteter Irrglaube: Kubernetes sei auf Hypervisoren angewiesen. Stimmt nicht. Kubernetes kann direkt auf Bare Metal laufen, ganz ohne Virtualisierung.
Beispiele für Bare-Metal-Kubernetes
- k3s, k0s oder MicroK8s laufen leichtgewichtig direkt auf physischen Servern.
- Projekte wie Metal³, Tinkerbell oder MaaS ermöglichen automatisierte Bare-Metal-Provisionierung.
- Talos Linux geht noch weiter: ein minimalistisches, immutables OS, das speziell für Kubernetes gebaut wurde1 – kein SSH, kein Shell-Zugang, kein Paketmanager. Vollständig API-gesteuert via gRPC, mit nur unter 50 Binaries (zum Vergleich: Ubuntu hat über 2700).2 Keine menschliche Hand dazwischen.
Diese Systeme zeigen, dass man Virtualisierung gar nicht braucht, um moderne Cloud-native Workloads zu betreiben. Im Gegenteil – jede weggelassene Schicht bedeutet weniger Abhängigkeit, weniger Lizenz, weniger Fehlerquelle.
4. Container ersetzen VMs – wenn Software dafür gebaut ist
Natürlich lässt sich nicht alles von heute auf morgen „containerisieren”. Legacy-Software erwartet oft eine VM-Umgebung mit persistentem Storage, Netzwerkadaptern und klassischen Daemons.
Aber: Wer bereit ist, seine Anwendungen neu zu denken, erreicht technische Freiheit. Containerisierte Anwendungen starten in Sekunden, skalieren automatisch, lassen sich über Cluster verteilen und versionieren wie Code.
Technische Voraussetzungen
Dafür braucht es:
- StatefulSets und Persistent Volumes für Zustandsbehaftung.
- Operators für Lifecycle-Management komplexer Systeme (z. B. Datenbanken).
- Service Meshes (Istio, Linkerd) für sichere Kommunikation.
Der Aufwand ist anfangs höher – aber das Ergebnis ist Architektur-Souveränität. Die Abhängigkeit verschiebt sich vom Anbieter zur eigenen Kompetenz.
5. Bare Metal + Kubernetes = europäische Autarkie
Wenn man Cloud-Souveränität technisch übersetzt, ergibt sich eine klare Formel:
Hardware im eigenen Recht + Open Source Orchestrierung + standardisierte APIs = Kontrolle
Diese Formel lässt sich heute vollständig mit europäischen Ressourcen umsetzen:
- Bare Metal in europäischen Rechenzentren (z. B. OVH, Hetzner, Scaleway).
- Kubernetes (oder k3s/k0s) als Orchestrierungsschicht.
- OpenTofu, Ansible für Infrastrukturautomatisierung.
- Keycloak, Prometheus, Grafana für Authentifizierung und Monitoring.
- MinIO oder Ceph als unabhängiger Storage.
Das Ganze läuft ohne proprietäre Hypervisor, ohne Lizenzen und ohne Cloud Act.
6. Warum das mehr ist als Technik
Sich auf Kubernetes einzulassen heißt: Verantwortung übernehmen. Man ersetzt externe Abhängigkeit durch interne Kompetenz. Man baut keine Mauern, sondern Wissen.
Die Investition in Know-how ist die eigentliche digitale Verteidigung. Denn wer seine Systeme selbst orchestrieren kann, braucht keine Plattformanbieter, die ihm Zugriff gewähren.
Cloud-native Technologien sind also nicht nur modern – sie sind politisch relevant. Sie sind der Beweis, dass Fortschritt und Souveränität keine Gegensätze sind.
Unabhängigkeit ist ein Architektur-Entscheid
Virtualisierung war gestern das Mittel zur Effizienzsteigerung. Kubernetes ist heute das Mittel zur Selbstbestimmung.
Wer sich traut, seine Software und Infrastruktur an diesen Gedanken anzupassen, löst gleich zwei Probleme: Er wird unabhängiger – und er wird zukunftsfähig.
Die Zukunft gehört nicht denen, die die meisten VMs starten. Sondern denen, die sie nicht mehr brauchen.
Diese Serie wird fortgesetzt.
Quellen
Weiterführende Links:
- Kubernetes Documentation
- k3s – Lightweight Kubernetes
- Talos Linux – Kubernetes Operating System
- Metal³ – Bare Metal Host Provisioning for Kubernetes
- CNCF Landscape – Cloud Native Technologies
- StatefulSets in Kubernetes
- Service Mesh Comparison
Footnotes
-
Talos Linux: The Kubernetes Operating System – Minimalistisches, immutables OS speziell für Kubernetes, API-gesteuert ohne SSH ↩
-
The New Stack: No SSH? What Is Talos – Talos mit unter 50 Binaries vs. Ubuntu über 2780, vollständig API-gesteuert via gRPC ↩