こんにちは、コヘ・トクナガです。コンテナディのレビアとノンコアサッププロジェクトのSargi-de Snapshorterのメンテナーです。今日はアキヒロスダから参加しました。コンテナディプロジェクトのメンテナーです。今日はコンテナディのレビアを紹介します。まずコンテナディの紹介をします。コンテナディはコンテナランタイムプロジェクトです。5th CNCF Graduated Projectです。コンテナディはコンテナランタイムプロジェクトの資料を紹介することができます。コンテナロンのプロセッシュ、イメージ、ファイアスステース、メラデータ、資料デヴェンデンシーを紹介します。その後、クリーンのインターフェイスをアップアップすることができます。コンテナディのインターナーのコンテナディのレッドを紹介します。コンテナディはタイトルで高劣化されているそうです。コンテナディの society一つのプロジェクトが新たに目前のコンテナディをクリーンでしてくれています。そして同じケーキのファイアススターテーでコンテナ脱出されている快速作限 neighbours,アツア枚とか錯誤の行動でも経験人それはコメディを約束しました。この脱出がスタイトスの価値を取り組むことができます。コンテナディはコンテナディを使っています。コンテナディはDoccaの使用ができます。コンテナディはコンテナディの利用が33%で、サーフェイについての2人で1人で使用します。コンテナディはマネージドサービスで使用されています。さらにオープンソースのプロジェクトで、GKE AWS Farget AKS AKSのサービスで使用されています。Docca Mobile Build Kitのデザインで、K3S、Kine Mini Cube、Cube Spray、Mikro KS、K3S、ファクションのサービスで使用されています。このデザインで使用されているなら、コンテナディはコンテナディを使用されています。コンテナディはコンテナディの利用ができます。コンテナディは3つの利用ができます。CRI Runtime on Kubernetesで使用されています。Doccaのコンテナディと、Valious Container-based Toolsで使用されています。みんなに見てみましょう。コンテナディの利用ができます。CRI Runtime on Kubernetesで使用されています。このデザインでコンテナディはコンテナディを使用されています。Cubelet映像を撮影されており、CubeletのCubeletがコンテナディの利用ができます。ランタイムを使用しています。ランシー、ジーファイザー、キャラコンテナー、エトセツアを使用しています。CRIランタイムのCFACスタンダードを使用しています。Cuban 80のサービスやCuban 80のディスビューションを使用しています。コンテナーを使用しています。コンテナーを使用しています。元才のコンテナーを使用しています。バナナulisの動画を使用していたコンテナGEINGはコンテナディ汁に設定しています。コンテナディウイギターを使用しています。重算工程コンテナディのアプリ私だけは、パンテナデイしています。キюバル80では、デイパー使用しています。コンテナディのセンスはコンテナディ飾力を減るためにステ色のコンテナディ幅を使うフ 1900 D Listというコンテナディに使用してみます。Generor Container Management tool is also used as a general container management tool.Several applications are developed based on container.They include Build Kit, Fasty, Node Card, and Poach container.Container API is commonly used by these tools.Container provides Go Client Library and Utilities for container-based container management.Applications can use them for integrating to container.ContainerD can also be extended using plugins without re-compilation as discussed later.As shown in the previous slides,ContainerD manages images, containers, and paths.So, how is it done?Let's take a look at ContainerD's internal components.ContainerD has client-server architecture.It provides APIs and container management functionalities to the client.ContainerD Project provides Go Client Library for easily integrate to ContainerD.Client calls server via ContainerD API through Unix socket.In addition to ContainerD API,ContainerD also provides CRI for Kubernetes as well.Cubelet calls ContainerD's functionality via CRI.ContainerD supports various low-level runtimes,including Run-C,Gvizor, and Cader containers.It also supports no OCI runtimes, including Firecracker.ContainerD is highly extensible, so users can customize its functionality using various low-level plugins, custom services, or custom client library.We will discuss about extensibility in more detail later.ContainerD Project provides ContainerD API Client Library.It is called smart client and contains rich container-related utilities, including ContainerD API bindings,Container Registry Client, pulling and pushing images, image unpacker, and creating OCI config for OCI runtimes.Using the client library, there are several ContainerD client implementations in community.CTL is a CLI client for ContainerD.This is developed in ContainerD Project.It's like a ContainerD API wrapper instead of container management utilities,as mainly used for debugging of ContainerD or trying new features.That card is a Docker-compatible CLI for ContainerD.Because of the compatibility, it's easy to use for Docker users.In addition to Docker-compatible features, it also provides ContainerD's cutting-edge features,including lazyplink and image encryption.We will discuss about null card in more detail later with AkiHero.As mentioned in previous slides, various ContainerD-based tools are developed as ContainerD Client in community,Devalaging Client Library, and ContainerD API.ContainerD Tava or Core provides container management functionality to the client via GLPC API.ContainerD Core is implemented as a set of microservices,and the set of APIs of these services are provided to the client as ContainerD API.For example, as shown in the figure, there are several services like container service for container metadata management,image service for image metadata management,task service for performing container execution,and CRY service that implements CRY.Among these services, there is a shared metadata underneath.It's bboard-based key-value tool.It stores metadata of containers, images, contents, file systems, snapshots, etc.It also manages reference graph of these resources for performing garbage correction.CRY for Kubernetes is also implemented as a microservice in ContainerD.Initially CRY is implemented as a separated client binary,but it's currently built into ContainerD Core,and the codebase is also merged to ContainerD repository since ContainerD 1.5.As shown in the figure,CRY service provides image service API and runtime service API defined by CRY.These functionalities are implemented based on other container services and external plugins.As external plugins, CRY plugin, and NRI plugin are currently used.CNI plugin is used for network interface preparation for pods,and NRI plugin is used for managing node resources like C-group.Because CRY service relies on other services, it contains container-d client calls for talking to other container-d services and plugins.Based on these services, CRY implements pods, containers, and images management.In ContainerD Core, there are several services that provide low-level role of container management.ContainerStore is a store for image contents, including manifest and layers.It stores these contents as its basis, so without decompression or extraction.These contents are content-addressable, and killed by the content digest.SnapShot also manages image contents, but it focuses on the file system snapshots.SnapShots are extracted in stacked view of containers with file system layers.SnapShots are created by Snapshot and passed to OCR runtimes as root file system of containers.There are several Snapshot implementation power-backing file system.OverlayFaceSnapShot is one of the most used one,but there are also other implementations,like butterFaceSnapShot, AGUFiceSnapShot, and FuseBaseSnapShot, etc.RuntimeService executes low-level runtimes via SIM.SIM is a wrapper-demo for OCR runtime and manages the container's life cycle and logging.Different from one-shot OCR runtime CLS,SIM is a long-running process that has the same lifetime with the container,so it's well-structured runtimes that need to manage stateful resourceslike virtual machine of care containers.This figure shows how an image is executed as a container in container D.Connecting to the registry and downloading image contents are clients' responsibility.Registry-related utilities are implemented in the container D smart client library.Once the client pulls image contents,it stores the contents to container D course content store as its basis,so without decompression or extraction.ImageLayer contents stored in the content store are decompressed and extracted by DiffServiceand the stacked root file system view is managed by Snapshot.ClientLibrary provides unpacker utility for this process.then Snapshots are used by task and runtime service and passed to OCI runtimesand they are used as containers root file system.TaskService can be used via container API bindings by the client.As discussed in previous slides,containerD is highly extensible.Let's look at how it's done and some examples of extension for leveraging containerD.You can extend containerD by plugging external binaries into containerD without recompilation.Go plugins can also be used.There are two types of external binary plugins.One is the plugin talks to containerD via a NIC socket,Proxy Snapshot and Proxy Content Store are this type of plugins.Another is a plugin as an executable binary.StreamProcessor and Shim are this type of plugins.ContainerD API is also extensible by implementing your own custom service.For example,FirecrackerContainerD has new APIs called Control API by their own control service.From next slides,let me introduce some examples to extend containerD using these plugins.Using plugins,you can enable lazyplink on containerD.RemoteSnapshot plugin is the plugin enables this feature.RemoteSnapshot allows containerD to perform lazyplink of images from arbitrary remote store.Lazyplink here means containerD can start up containers without waiting for the entire image contents being locally available.Instead,necessary chunks of image contents are put on demand.As shown in the following figure,remoteSnapshot plugin has a responsibility to fetch image contents from the backend storeand provide containerD's root file system snapshots to containerD.As mentioned in the previous slides,snapshoter can plug into containerD via NIC socket,so no recompilation is required.There are several remote snapshot implementations in community.For example,Starside Snapshoter is a remote snapshoter developed as a non-cost project of containerD.This enables containerD to lazyplink images from the standard registry.containerD handles image layers for creating container's root file system.The image layer formats are defined by OCI image spec and GZIF,Z-standard and plainter layers are currently supported.However,not limited to OCI layers,containerD can handle arbitrary layer formats like encrypted layers,even if they are not supported by the OCI image spec.The plugin enables this string processor.As shown in the following figure,DifService can recognize several string processors.This service converts image layers that are loaded from the registry into root file system snapshots with chaining these string processors.Each string processor converts the media type of the layer into another.DifService can handle arbitrary media type of layers as long as the corresponding string processor is plugged into DifService.For example,ImageCryptStringProcessor enables containerD to handle encrypted image layers.StringProcessor binary can be plugged into containerD as a separated binary,so recompilation is not needed.containerD can integrate to arbitrary low-level runtimes.Low-level runtimes are not limited to OCI runtime,but no OCI runtime like FireCroak can also integrate to containerD.The plugin enables this is called Shim.Shim works as a thin wrapper of low-level runtimes.Each low-level runtime can integrate to containerD by implementing their Shim following the defined Shim API.Runtime Shim provided by containerD project also supports plugable logging destination feature.This enables Shim to stream container logs into arbitrary destination like FIFO and pipe external binary and file.From next slide,Akihiro will talk about the containerD client.Hi, my name is Akihiro Suda.I'm a maintainer of containerD.In my part,I'll explain how to implement your own containerD client for fun and profit.To implement your own containerD client,first,you need to choose API from two APIs.The first one is containerD's native API,and the second one is CRY API.The native API is used by several projects,including DockerMobi,Musicit,Prosd,NerdCTL,and other cyber-party projects.On the other hand,CRY API is used by Kubernetes. These APIs are similar,and both of them use CRPC over UniqueSocket as the transportation mechanism.But there are several notable differences.For example,the native API is container-oriented,while CRY API is part-oriented.So,the native API does not have first-class support for part-objects.The native API has several complexities compared to CRY API.But the selling point of the native API is that it has more flexibility and features such as pushing images to registries.So,it's hard to tell which one is better.But I suggest using the native API of containerD,because you probably want to be able to use all the features of containerD.But if you prefer simplicity,you may want to take a look into CRY API first.To use these APIs,in theory,you should use any programming language.However,in practice,you have to use GoLanguage for the containerD native API.Because the native API model depends on the smart client library that is implemented in GoLanguage,especially for putting images from a registry.So,contrary,it's really hard to use other languages such as Rust or Python to implement your own client.We welcome contribution for supporting more languages.The next topic is an example of containerD client.We can find example at htbs.constrash-constrash.io-docs-geting-solid.In this example,you first create a client object using containerD.new with the demo state at thrash-run-constrash-constrash-constrash-constrash.soc.And then,you create a CTX object that is associated with a containerD namespace string.And then,you further read this image from local hub using client.pull.Then,you will create container named ready server with several options,contrary.with image,contrary.with new snapshot,contrary.with new spec.And we have more with-with-with options such as OCI.with process arcs for specifying the command line strings to be executed in the container.And OCI.with mounts for mounting data volumes.And OCI.with memory limit for limiting memory resources.And sec.com.with profile for specifying a sec.com profile.At this point,your container is almost functional.But in addition to the client,you will have to implement OCI hooks and also,blogger binary in most cases.OCI hook is a custom command that is called on the host on creation and duration of the container.OCI hook is typically used for setting up and hearing down CNI bridge networks and port map configurations.Using OCI hooks is optional,but necessary if you want your containers to be restarted automatically or post-reboot.This is complex,so I will show the quote on the screen,but you can find an example quote in the United CTL repo.And if you want to see the logs of the container or transfer the logs to FluentG or something else,you also have to specify a logger binary.The United CTL repo has an example quote for showing logs as JSON files.Actually,United CTL is almost full implementation of Docker,except SwarmStuff.It was spun out from the code of CTL,but it has more practical features compared to CTL,such as automatic restarting of containers,and forwarding,roading,and rudeness mode.And it also supports basic print using surges and substitutes,and also decryption of OCI encrypt images.We carefully designed the source code of United CTL to be readable to beginners.So,you may copy the source code of United CTL as a starter pack to create your own client application.The last topic is the updates in container D 1.5 and future plan.The version 1.5 of container D is expected to be released by the end of April.This talk was recorded in early April,and version 1.5 was not released at the time of recording,but I guess it will be released by the time of broadcasting.This new release supports ZSTD as an image compression algorithm in addition to JDip.This algorithm is much faster than traditional JD.Program 1.5 also adds support for NRI,Node Resource Interface.NRI is similar to CI,contrary networking interface,but NRI is for managing resources,such as C-group stuff.In this release,we also enabled decryption of OCI encrypt by default.OCI encrypt itself had been supported since version 1.3,but you had to provide a custom configuration file to use OCI encrypt in previous releases.And we also recently put United CTL into the container D as a subproject.This is a Docker compatible CLI.I talked about this just a minute ago.And in this release,we also merged the repo of the CLR plugin into the main repo.This change is not visible to end users,but this monorepo model simplifies the process for contributing to controller D.We also switched away from vendor.conf into Go modules in this release.So next is future plan.In the next release,we are planning to support file system quarter such as XFS quarterfor the root file system of the containers.We are also planning to support username spacesfor CLI,so that Kubernetes can launch port as a non-user that is different from the user account of container D.This is similar to rootless containers,which means running everything including container D as a non-user,but this is different from rootless containers,and does not conflict easily.We are also planning to support ports as first class objects.And we are also planning to aggregate the port image for port sandboxes.We also need to have more documentations,and we need your help.The last topic is recent updates of subproject plugins.Last year,Dragonfly released NIGAS Substructor plugin for container D.Nigas Substructor is similar to Sargent Substructor,and enables basic print,as well as teleportation of images.But Nigas uses a file format that is incompatible with OCI tables.And Alibaba recently released Ovalay-VD Substructor plugin.VD means block devices.Ovalay-VD is similar to Ovalay-FS,but uses Isocache block devices.We also have several new runtime plugins.Rangue by Tanaki Hajime-san is a runtime who running Linux containers on macOS使用LKL Linux kernel library.Rangue by Samuel Karp is a runtime for running pre-BSD jails as OCI containers.Let me recap this session.Continuity is a de facto standard runtime for Kubernetes,but not only for Kubernetes.It's used by TokarMobi,BereKit,Puzzly,and several other projects.Continuity is designed to be extensible with plugins.We have many plugins such as runtime plugins,sub-shutter plugins,shorian processor plugins,and loading plugins.And recently we added a new sub-project called NaroCTL.This is like Tokar,but with full features of Contrandee.This is also like CTR,but with full user experience of Tokar.That's all.Thanks.