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?

Formal Metadata

Title
Firecracker, should it work only with a single runtime?
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
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.