 안녕하세요 여러분 오늘은 파이오크랄과 컨테이너 런타임 매니저를 이야기할 거예요 제 이름은 동수 탁입니다 저는 캠프웍에 일하고 있습니다 베스트인 베린에서 일하고 있습니다 저는 컨테이너 런타임에서 일하고 있습니다 그리고 저는 블랙칼리노크와 큐브스판에서 일하고 있습니다 모든 오픈소스 프로젝트입니다 작년에 제 коллег 알반드와 함께 일하고 있었습니다 특히 오시아 런타임 tools and distribution specs 그래서 저는 컨테이너 런타임에서 일하고 있습니다 그래서 오픈소스 프로젝트도 재미있게 보입니다 컨테이너 런타임에서 일하고 있습니다 그래서 오늘 파이오크랄과 컨테이너 런타임에서 일하고 있습니다 아주 최근 프로젝트에 2시간이나 2분이나 지내고 있습니다 그래서 24시간이나 지내고 있습니다 그리고 이게 전체적인 베린과 컨테이너 런타임에 좋은 밸런스입니다 왜냐하면 많은 사람들이 베린과 컨테이너 런타임에서 일하고 있습니다 그리고 이게 전체적인 베린과 컨테이너 런타임에서 일하고 있습니다 그리고 이게 전체적인 베린과 컨테이너 런타임에서 일하고 있습니다 그래서 제가 생각하는 이유는 아나조넨 인테라이터는 워스트 VMM에서 일하고 있습니다 yesterday there was a talk about there maybe I'm not expert about the Rust VMM you can ask one of the Rust VMM members This is a simple example of how you can run firecracker and how to launch the microvm first you run firecracker dm without the api socket option you can just skip this option omit this and run it then the temp firecracker dot socket will be the default a unique socket that firecracker listens on and after that you can specify two very important requirements the first one is about specifying kernel image and the second one is about the rootfis image so you have to prepare two different images on your local machine and you have to specify for the first one the root source you are there for the second one the rootfis drives slash rootfis you are there the other ones are very similar to each other and yeah that's it so this is a basic preparation for running firecracker after that after all preparations were done you can actually start the microvm which is also done by this Rust fire api through the unique socket this is instant start action so you have to specify actions in the url and you do specify action type to instant start then the microvm will boot I will show this in the later demo so this is not actually human friendly at all and maybe you would think about an easier way so many people have been already working on it so integration with container managers the first one is obviously continuity which is pretty widely used and widely known under firecracker vm, microvm organization there is get repository firecracker continuity repo this repository is about implementing three different components agent, snapshotter and runtime and after that you need to install the container's despecialization into your local directory that will enable the container to be integrated with firecracker and this depends on the TTRPC interface of the container so if you are interested in you can look into this project and very recently there is another attempt to integrate kata container with firecracker you can visit this project this is already merged and you can use it already and very clean implementation I can recommend it and on the other hand this heavily relies on existing kata container interface like hypervisor and so on it's not like a lightweight approach I would say I was thinking about a very simple way how to integrate in a simple way so cryo would be the best approach for me that's what I thought so what's cryo? cryo achieves both container runtime standard which are OCI and CRI OCI is simply speaking this is a spec for open container initiatives its reference implementation is runcy maybe if you are running Docker in your local machine for example then you are already running runcy because 99% of usage is running runcy for OCI runtime so cryo already implements this and on the other hand Kubernetes itself 1.8 or newer already has container runtime interface which is CRI this is done for supporting both container runtime Docker and Rocket and this is typical standard for container runtime and that wants to be integrated with Kubernetes and cryo itself achieves CRI and at the same time it's relatively simple compared to container D or any other solutions so that's what I chose to implement and cryo itself does not have any command line tools so maybe the best way to install cryo control another command line tool cryo control is a part of cryo tools repo so you can visit this repo this provides a very simple and similar command line interface shown to users as runcy or Docker so my goal is to make runtime add-on in cryo for firecracker currently cryo has a single runtime which is v1 and should be renamed to OCI in the future and the second approach which is written in this precast which is for supporting VM-based container runtime this is still in progress not much yet but it improves internal interface of cryo so what I want to do is to take similar approach as this VM-based container runtime inside cryo and at the same time I'm not doing anything like connecting to the VM-based container runtime but I'm just running firecracker so under the scene that's what I want to do for doing that I'm relying on firecracker's Go SDK this is also a very good and thin layer between the firecracker itself and container runtimes and third-party applications firecracker is written in Rust so I like Rust but honestly I'm not good at programming Rust so Go SDK is a very good approach solution for me it allows me to write a third-party application using Go language and then it's easy to be integrated with existing container runtimes because most container runtimes are written in Go and it provides low-level cable and functionalities in an easy way so you can take a look at this report so I can show you a simple diagram on the left side cryoDemon should be running with my own firecracker runtime add-on and on the right side firecrackerDemon should be running in the background so each DEMON listens to its own unique socket so what I do is actually running cryoCtrl command line tool from my command line then it should connect to cryo's unique socket and send specific commands to that unique socket then cryo interprets this command based on firecracker Go SDK then sends the commands to firecracker backend and firecracker backend also listens to its own unique socket whenever it receives the command it spawns a new microVN so if you do this process multiple times or 10 times or 100 times then the firecracker DEMON would spawn microVNs 10 times or 100 times so arbitrary times you can do it as you want current proof of concept is available as open source branch is kimpfwork slash cryo slash my branch name and this basically reads config file for setting up kernel and rootf is for firecracker and this can be also done manually but it should be human-friendly and configurable so I had to add it also whenever starting container for example so cryo runtime would also tell firecracker to spawn a new process microVN process this branch itself is partly working but it's still in heavy development so in the future maybe it might be changing so yeah in the future I'm going to clean up something and make a pull request to the upstream report on the other hand there is a simple tool for creating kernel and rootf's image so as I shown a little before there is an example for setting up kernel image and rootf's so you should really have two different images not a single image so I had to create these two different images using a simple tool based on the simple paragraph file to create vm.lib.bin and rootf's.exe this is not no special thing so this is just a stock kernel no special patches and this is normal rootf's file image based on the x4 file system I'm going to show demo first of all I'm going to show just plain simple firecracker demo in that process cryo is not involved at all after that the second step is integrating with cryo and configuring and running cryo crycontrol commands and so on and the first demo is just running a firecracker so this is my local repository including just an upstream firecracker repo so there is this is a binary file that I want to run and these are two different images one is a kernel and the other one is rootf's so first of all I want to clean up the existing file and after that I want to run s is running now check if it's really running s is running and also Unix socket is active listening the first preparation is specifying kernel image so it will send a specific command kernel root image path and boot arguments so these things can be specified in an arbitrary way so you can just configure as you want also you need to specify this boot source URL and put with this put method s204 result is good so it has worked you cannot see it right now now the second preparation is about rootf's see? this looks similar but you have to specify here with drive slash rootf's and you have to specify absolute path to existing rootf's image yes it has worked still I'm seeing nothing this is normal so until I really start and send an instant start action so you don't see anything until the preparation this is just a normal process the final step is actually sending instant start looks similar but this is the URL has actions and action type is instant start yes this is normal and you can see now the microwave VM has already booted this is just normal unstable image corner is also that one from debium unstable it's been booted you can see anything if you want and I specified total memory to 128 bytes so you can see the memory usage like that and if I just type reboot then the microwave VM would be gone and you will not see anything microwave VM yeah it's gone yeah that's all so it's a very simple example and actually you are able to specify many other parameters for example second block device or another virtual net interface I will skip this demo here but maybe you will get the idea now thanks second part of demo is about integration with cryo so this is cryo repository and my custom branch and there is a binary file cryo demo I'm going to run it with some configuration file which is pretty fine like that or like that so for example if I look into this configuration file then you will see the normal configuration so it will pull an image from k.io and run some commands using the environment variables and this is just normal cryo config and I'm going to run cryo demo also on the other terminal I'm going to send several cry control command it's running you can see demo is running and there are no sandbox part available also no container is available the first command is creating and running sandbox part so before running actual container you need to specify a sandbox config this is the first step now the part is ready now the cryo demo shows several messages and this is mostly about sending an instant start messages it's communication between cryo and firecracker demo you can see cryo demo is running also cryo demo will be running now the second step is creating a container using that port sandbox port what I did was actually using this existing port id specify two different configs one is container config and the second one is sandbox config so far I have just one container running which is in the created state not actually running now but you can see also that this action was done and with that created container I'm going to start the container actually it started I'm going to run just ps you can see that is now in running state now cryo demo is also saying that it has done something about this and it got 204 status and I'm going to stop the container first and container I'm going to delete the container that has succeeded now you can see the container is now gone yes no container at all but you can see still the port is running and the firecracker demo is only running just once because the second instance was already removed now I'm going to remove the port itself again stop it stop and the port is gone yes this is a known issue so I'm going to figure out in the next few days anyway this should actually kill the existing firecracker demo so I'm going to just remove this terminated yes that's the end of my demo thanks for listening to talk and I'm going to quickly go over the future work so I'm going to publish this re-branch as an actual precast and get some feedback from the existing maintainers there are also missing features like attach or exit so I'm going to follow up with that and also that's a good idea to do the similar work for example rocket lab this is to be discussed that's it so we can do one question and you were the first one I have a question specifically to firecracker itself don't understand what makes it limited to microvm and short life why cannot be a general hyperversal I think general firecracker is designed to be living just for a short period and for example serverless workloads that was the purpose of firecracker that's what it does the job in the best shape sure you can also adapt and use firecracker for other use cases and I think it's not impossible but on the other hand firecracker extreme maintainers would think about this firecracker wants to keep it very simple and minimal so if you want to use it as a container for example or another feature then it might be a little because firecracker maintainers would not think about that does that answer for your opinion thank you