Shim-API reduziert Komponenten

Kata Container 1.5 unterstützen den AWS-Hypervisor Firecracker

| Redakteur: Ulrike Ostler

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)

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.

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.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45709161 / Virtualisierung)