Kata Container 1.5 unterstützen den AWS-Hypervisor Firecracker

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 (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.

Whitepaper Empfehlung

Open Source in der Datacenter-Administration Teil 1

Open Source in der Datacenter-Administration Teil 2

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.