We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Firecracker, should it work only with a single runtime?

Formale Metadaten

Titel
Firecracker, should it work only with a single runtime?
Serientitel
Anzahl der Teile
561
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Firecracker, an open-source project published by Amazon, opens up a lot of interesting perspective to the container ecosystem. For the diversity of Kubernetes ecosystem, we should also think about how we should get the new shape of containers integrated with all other high-level container runtimes, such as cri-o or rktlet. Firecracker, an open-source project published by Amazon, opens up a lot of interesting perspective to the container ecosystem. It opens up use cases between containers and VMs, making use of KVM without relying on heavyweight Qemu instances. Though its integration with the Kubernetes ecosystem has only started its first step, only with containerd. For the diversity of Kubernetes ecosystem, we should also think about how we should get the new shape of containers integrated with all other high-level container runtimes, such as cri-o or rktlet. In this talk, I would like to talk about alternative ways of integration for getting firecracker integrated with multiple container runtimes. A proof-of-concept for the concept can be also presented during the talk.