© Liashko/Shutterstock.com
Entwickler Magazin
Wie Virtuelle Maschinen auch im Kubernetes-Cluster laufen

Gegensätze, die sich anziehen

Kubernetes und Virtuelle Maschinen? Das klingt erst einmal wie ein Widerspruch. Doch bei genauerem Hinsehen finden sich durchaus Argumente dafür, neben den leichtgewichtigen Containern auch klassische Virtuelle Maschinen in einem Kubernetes-Cluster laufen zu lassen.

Marc Sluiter


Gerade lernen wir, dass man leichtgewichtige Container nutzen soll, da liest man auf einmal immer häufiger von Virtuellen Maschinen (Virtual Machines, VMs) im Kubernetes-Umfeld. Es hat mehrere Gründe, weshalb diese Kombination auch eine Daseinsberechtigung hat:

Man kann oder möchte aus Sicherheitsgründen nicht auf die Hypervisor-basierte Isolierung von VMs verzichten.Man benötigt eine andere Kernelversion oder gar ein anderes Betriebssystem als der Host zur Verfügung stellt. Oder vorhandene VMs lassen sich aus anderen technischen Gründen, oder schlicht mangels Zeit, nicht ohne Weiteres zu Containern migrieren. Trotzdem möchte man nur einen Kubernetes-basierten Infrastrukturstack betreiben und sowohl Container als auch VMs über das gleiche API steuern.

Diesen beiden sehr unterschiedlichen Problemstellungen führen zu zwei unterschiedlichen Lösungsansätzen, wie man VMs in einem Kubernetes-Cluster nutzen kann: Entweder man verpackt Container beim Starten in eine Virtuelle Maschine, ohne dass der User davon etwas merkt. Diesen Ansatz verfolgt z. B. das Projekt Kata Containers [1]. Oder man ermöglicht den Betrieb von vorhandenen VMs. Diesen Ansatz verfolgt das Projekt KubeVirt [2]. Im Folgenden wollen wir uns das Projekt KubeVirt genauer anschauen.

Aber Kubernetes kennt doch nur Container?

Kubernetes orchestriert von Haus aus nur Container. Wie bekommt man also seine Virtuellen Maschinen in einen Kubernetes-Cluster? Wie konfiguriert man sie, und wie werden sie letztendlich gestartet? Und das ganze möglichst Kubernetes-native? Grundsätzlich gibt es auch hierbei zwei Möglichkeiten, die vorhandene Funktionalität von Kubernetes mit nativen Methoden zu erweitern:

API Aggregation: Bei der API Aggregation implementiert man einen eigenen API-Server; Aufrufe an die neuen Ressourcen werden vom vorhandenen API-Server delegiert. Das bietet eine sehr hohe Flexibilität, ist aber auch aufwendig zu implementieren [3].

Custom Resource Definitions (CRD): Bei dieser Methode definiert man seine eigenen Kubernetes-Ressourcen, die dann genauso wie die existierenden Kubernetes-Ressourcen über den originalen API-Server angesprochen werden. In einem Controller reagiert man dann auf Änderungen an den CRDs und implementiert die gewünschte Funktionalität [4].

Kubevirt geht den zuletzt genannten Weg. Es werden neue Ressourcen registriert, in denen die die Eigenschaften der Virtuellen Maschine definiert werden und die den Status der laufenden VM wiedergeben, ähnlich wie in den nativen Deployment...

Entwickler Magazin
Wie Virtuelle Maschinen auch im Kubernetes-Cluster laufen

Gegensätze, die sich anziehen

Kubernetes und Virtuelle Maschinen? Das klingt erst einmal wie ein Widerspruch. Doch bei genauerem Hinsehen finden sich durchaus Argumente dafür, neben den leichtgewichtigen Containern auch klassische Virtuelle Maschinen in einem Kubernetes-Cluster laufen zu lassen.

Marc Sluiter


Gerade lernen wir, dass man leichtgewichtige Container nutzen soll, da liest man auf einmal immer häufiger von Virtuellen Maschinen (Virtual Machines, VMs) im Kubernetes-Umfeld. Es hat mehrere Gründe, weshalb diese Kombination auch eine Daseinsberechtigung hat:

Man kann oder möchte aus Sicherheitsgründen nicht auf die Hypervisor-basierte Isolierung von VMs verzichten.Man benötigt eine andere Kernelversion oder gar ein anderes Betriebssystem als der Host zur Verfügung stellt. Oder vorhandene VMs lassen sich aus anderen technischen Gründen, oder schlicht mangels Zeit, nicht ohne Weiteres zu Containern migrieren. Trotzdem möchte man nur einen Kubernetes-basierten Infrastrukturstack betreiben und sowohl Container als auch VMs über das gleiche API steuern.

Diesen beiden sehr unterschiedlichen Problemstellungen führen zu zwei unterschiedlichen Lösungsansätzen, wie man VMs in einem Kubernetes-Cluster nutzen kann: Entweder man verpackt Container beim Starten in eine Virtuelle Maschine, ohne dass der User davon etwas merkt. Diesen Ansatz verfolgt z. B. das Projekt Kata Containers [1]. Oder man ermöglicht den Betrieb von vorhandenen VMs. Diesen Ansatz verfolgt das Projekt KubeVirt [2]. Im Folgenden wollen wir uns das Projekt KubeVirt genauer anschauen.

Aber Kubernetes kennt doch nur Container?

Kubernetes orchestriert von Haus aus nur Container. Wie bekommt man also seine Virtuellen Maschinen in einen Kubernetes-Cluster? Wie konfiguriert man sie, und wie werden sie letztendlich gestartet? Und das ganze möglichst Kubernetes-native? Grundsätzlich gibt es auch hierbei zwei Möglichkeiten, die vorhandene Funktionalität von Kubernetes mit nativen Methoden zu erweitern:

API Aggregation: Bei der API Aggregation implementiert man einen eigenen API-Server; Aufrufe an die neuen Ressourcen werden vom vorhandenen API-Server delegiert. Das bietet eine sehr hohe Flexibilität, ist aber auch aufwendig zu implementieren [3].

Custom Resource Definitions (CRD): Bei dieser Methode definiert man seine eigenen Kubernetes-Ressourcen, die dann genauso wie die existierenden Kubernetes-Ressourcen über den originalen API-Server angesprochen werden. In einem Controller reagiert man dann auf Änderungen an den CRDs und implementiert die gewünschte Funktionalität [4].

Kubevirt geht den zuletzt genannten Weg. Es werden neue Ressourcen registriert, in denen die die Eigenschaften der Virtuellen Maschine definiert werden und die den Status der laufenden VM wiedergeben, ähnlich wie in den nativen Deployment...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang