Mobile-Menu

Shim-API reduziert Komponenten Kata Container 1.5 unterstützen den AWS-Hypervisor Firecracker

Redakteur: Ulrike Ostler

Die gerade veröffentlichte Version 1.5 von „Kata Containers“, unterstützt den kürzlich geöffneten „Firecracker“-Hypervisor von AWS, die s390x-Architektur von IBM sowie eine neue Methode zur Integration mit dem „containerd“-Projekt.

Anbieter zum Thema

DataCore Software GmbH
AixpertSoft GmbH
Schwarz IT KG
Die Version 1.5 von Kata Containers unterstützt nun den AWS-Hypervisor „Firecracker“; dazu gibt es ein Video: https://asciinema.org/a/219790
Die Version 1.5 von Kata Containers unterstützt nun den AWS-Hypervisor „Firecracker“; dazu gibt es ein Video: https://asciinema.org/a/219790
(Bild: OpenStack Foundation)

Im vergangenen Juni begann Contributor Michael Crosby mit einer Diskussion, die das Hinzufügen einer „Shim“-API zu containerd betraf, um VM-basierte Laufzeitumgebungen besser zu unterstützen. Das Release 1.5 von Kata Containers beinhaltet nun eine erste Implementierung, die dieser Shim-API entspricht.

Kubernetes-Integration mit Shim v2 - sie vereinfacht die Integration von Kata Containers mit Containerd
Kubernetes-Integration mit Shim v2 - sie vereinfacht die Integration von Kata Containers mit Containerd
(Bild: OpenStack Foundation)

Die Firecracker-Unterstützung

Amazon Web Services gab im vergangenen November bekannt, dass der Code für den Hypervisor Firecracker freigegeben wird. Für die Kata-Community ist das deswegen interessant, weil sich damit eine minimalistische Hypervisor-Lösung für die einfachen Anwendungsfälle anbietet.

Um diese Konfiguration zu erreichen, muss der Cluster so konfiguriert sein, dass er entweder „CRI-O“ oder Containerd verwendet und die „RuntimeClass“-Funktion von Kubernetes. Mit der Konfiguration von RuntimeClass sowohl in Kubernetes als auch in CRI-O können Endbenutzer die Art der Isolierung auswählen, die sie pro Workload wünschen.
Um diese Konfiguration zu erreichen, muss der Cluster so konfiguriert sein, dass er entweder „CRI-O“ oder Containerd verwendet und die „RuntimeClass“-Funktion von Kubernetes. Mit der Konfiguration von RuntimeClass sowohl in Kubernetes als auch in CRI-O können Endbenutzer die Art der Isolierung auswählen, die sie pro Workload wünschen.
(Bild: OpenStack Foundation)

Die Version 1.5 von Kata Containers bietet nun die von Usern geforderte Unterstützung. Sie ist damit eine Ergänzung zur Nutzung von „QEMU“. Ein typischer Anwendungsfall wäre, „runc“, „kata-qemu“, die QEMU-Konfiguration der Kata-Runtime, und „kata-fc“, die Firecracker-Konfiguration der Kata-Runtime, in einem einzigen Cluster zu verwenden, siehe Abbildung:

Der Firecracker-Hypervisor ist minimalistisch; das heißt also, dass es bei der Verwendung von Kata plus Firecracker immer wieder Funktionslücken auftreten. Dazu gehört die Unfähigkeit, Speicher- und CPU-Definitionen für einen Pod dynamisch anzupassen. Da Firecracker nur blockbasierte Storage-Treiber und Volumes unterstützen kann, ist ein „devicemapper“ erforderlich. Diese Funktion ist jedoch in Kubernetes und CRI-O sowie in der Docker-Version 18.06 verfügbar.

Unterstützung der s390x-Architektur

Zu erwähnen bleibt noch, dass Community-Mitglieder von IBM der Kata-Version 1.5 die Unterstützung von „IBM Z-Series“ beschert haben.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Artikelfiles und Artikellinks

(ID:45709161)

Weiterführende Inhalte