This slider was created by Wangxu.

2. • 首先，让我们介绍一下Kata Contianer到底是什么
• Kata Contianer是一个安全的Container Runtime， 类似于RunC一样的东西
• 使用了轻量级虚拟化技术
• 使用的体验上来说，更像容器
• 可以做到虚拟机级别的隔离，使用了硬件虚拟化的技术。
• まずKataContainerは何でしょうかを紹介させていただきます。
• KataContainerは安全性が高いのRunCのようなRuntimeです。
• 軽量的な仮想化技術を利用されています。
• 利用方法と感覚はコンテナと似てます。
• Hardwareの仮想化技術を利用しているため、仮想マシンレベルの隔てる(へ
だてる)ことをできました。

3. • 接下来是一张图是介绍传统的Container技术，
• 通过Namespace，Cgroups进行隔离、共享了Host的kernel
• この画像をご覧ください。以前のContainer技術を説明しています。
• NamespaceとCgroupsで隔てて、Hostのkernelを共有しています。

4. • Kata里面每个容器都会有一个自己的Kernel，他们使用虚拟虚拟化技术进行
隔离
• 如果应用本身被攻击或者入侵的情况下，最坏的情况下，只会进入到本身被
隔离的Kernel，不会对其他Kata Container产生影响。
• Katacontainerは仮想化技術で隔てるため、独立的なKernelが存在していま
す。
• 最悪の場合、アプリが侵入された時にも、隔てられたKernelだけ侵入され
ます。そのたのKataContainerに影響を及びません。

5. • 回顾一下，Kata Container的创建历史。
• 在2015年的时候，Inter的Clear Container和RunV同时Open Source，大家几
乎同时考虑到使用虚拟化技术，做一个隔离度更高的容器。
• 于是在2017年的12月份两个项目就宣布合并成同一个项目。这样就可以让社
区里面考虑使用虚化技术作隔离的想法，可以融合到同一个项目中。
• 这样就避免了两个项目的差异化，因为两个项目本身的理念是非常一致的。
并且将两个项目合并到同一个项目中去，也方便大家做选择。
• 这个项目在合并之初就是和OpenStack Foundation紧密合作，成为了
OpenStack的第一个Pilot项目。
• 在2019年4月，正式成为了Openstack Fundation 的第二个正式项目。
• 今KataContainerの歴史をご覧ください。
• 2015年の時、Inter社が開発したClear ContainerとHyper.sh社開発したRunV
が同時にOpen Sourceしました。
• みなさんはほぼ同じ時間で、仮想化技術を利用して、隔離レベル高いコン
テナを作成することを考えました。
• 利用者は仮想化コンテナ技術の要望を同じプロジェクトに溶け込むため、
2017年12月2つプロジェクトは一つになったことをアナウンスしました。
• 今回KataContainerへ進化する原因はいくつがあります。まず、2つプロジ
ェクトの異なることを避けたいと考えました。かつ、2つプロジェクトの考
えることがすごく似でるので、一つプロジェクトになったら、利用者も選
択しやすいことを考えました。
• KataContainerは最初にOpenStack Fundationと連携して、更にOpenStack
の初めるPilotプロジェクトになりました。
• 2019年4月、Openstack Fundationの二番目のOffical プロジェクトになりま

6. • Kata项目是一个转折，他的相关的一系列开源项目不仅仅是自己的发展。本
身也是随着容器化的潮流，同时对容器体系带来了巨大影响。
• 2015的时候，cncf项目rkt，成为Kubernetes第二个支持的runtime项目。
• hyper.sh加入了到了云原生社区，对Hypervisor提供了原生支持，此时我们
Kubernetes已经支持了两个容器项目，存在很多重复代码。
• 当时没有Plugin机制，很多代码混在一起，项目变得臃肿并且难以维护。如
果再加入对新的Runtime支持，那么重复的代码会继续增加。
• Kata プロジェクトと関連しているプロジェクトは自身の発展だけじゃなく
て、コンテナのトレントをフローして、コンテナにも巨大的な影響をあげ
ました。
• 2015年、kubernetesはCNCFのRKTを正式にサポートしました。
• hyper.shはクラウドNative Communityに参加して、Hypervisorのサポート
することをしました。Kubenretseは2つコンテナプロジェクトをサポートし
たため、沢山重複コードも存在しました。
• あの時、KubernetesのPlugin機能もまだできていません。一コードが混ぜ
で、メンテナンスが難しくになりました。もし新しいRuntimeを追加した
ら、重複コードが更に増えると思いました。

7. • 社区对这种情况作出了调整，定义了新的接口，也就是现在的CRI。
• 在定义CRI的时候，就已经开始考虑类似于katacontainer这种不是以
Namespace进行隔离，而是以虚拟机进行隔离的容器技术。
• 所以CRI也可以支持gVisor和Kata这样的容器技术。containerd就是这样的一
个CRI实现，kubernetes通过他们运行不同的container runtime。
• Commuity はこの状況を改善するために、CRIと言う新しいインタフェース
を定義して、追加しました。
• CRIが最初定義する時、すでに、KataContainerのようなNamesapceで隔て
ることじゃなくて、仮想化技術で隔てることを考えました。
• だから、CRIはgVisorとKataのようなコンテナ技術もサポートできています。
Containerdは色々ことを考えたCRIの一つプロジェクトです。Kubernetes
はCRIインタフェースで様々なコンテナRuntimeを起動できています。

8. • CRI实际上是把docker的各种能力，包括对podsandbox的创建和删除，查看，
以及podsandbox里面container的创建，还有EXEC与image的一些操作，都
包含在里面了。
• 这个是以当时的Kubernetes和docker为蓝本，开发的以container为中心的可
扩展接口。
• 有了这个接口就可以让不同的container引擎启动不同类型的容器。
• CRIはDockerの各機能を参考して、色々機能を実現しました。例えば、
PodSandboxの作成、確認と削除とか、及ぶPodSandboxのコンテナの作成、
EXEC操作とImageの操作も含めています。
• あの時のKubernetesとdockerを考えた、containerを中心にして拡張したイ
ンタフェースを開発しました。
• このインタフェースを利用して、様々なContainerを動けることを実現でき
ました。

9. • 在 Kata Containers 项目刚刚 Announce 的时候，运行中的容器就是一组进
程，PID是容器的唯一标识。
• 为了和 runc 兼容， Kata Containers 不得不使用一个 shim 也就是 kata-shim，
来模拟一个 runc container，接受信号，处理 I/O 流。
• 这样，加上 pause container，N 个 Container 的 Kubernetes Pod 就会有
N+1 个 containerd-shim 进程和 N+1 个 kata-shim 进程。
• 这么多的辅助进程，不仅不简洁，也带来了很大开销。
• KataContainerプロジェクトはアナウンスしたばっかりの時、動けてるコン
テナはProceesグループです。PIDはコンテナのゆいいつ標識（ひょうしき）
です。
• RunCと合わせるため、KataContainerはkata-shimで、RunC containerを模
擬して、信号を受けて、IO streamを処理しました。
• そうして、Pause Containerを含めて、N個のContainerのPodが、N+1個の
Container-shim processとN+1個のkata-shimが存在しまいました。
• 沢山の補助Processが存在し、繁雑（はんざつ）の上、性能のほうがも下げ
ると思います。
9

10. • 我们知道（念上面的 quote），David Wheeler 说过，计算机科学中的所有问
题都可以通过增加一个间接层来解决，当然，除了间接层过多的问题。
• 现在，我们在容器中就经常遇到这种间接层过多的情况。
• Kata 面临的问题在去年下半年开始被解决。
• David Wheelerはこの話したことがあります。コンピューター科学の問題は
間接層（かんせつ）を追加する方法で解決できます。しかし、間接層が増
えて、多すぎる恐れがあります。
• 現在、我々はコンテナを利用する時、この間接層が多すぎこと状況をよく
ありました。
• Kataの色々問題を去年の年末から解決始めました。
10

11. • 随着 Kata Containers 和 gVisor 先后开源，社区逐渐接受，namespaces不
再是容器的唯一形态。
• 在 Kata 或 gVisor 这类有额外隔离层的容器技术中，在宿主机上并没有一个
唯一的PID来代表一个容器。
• 于是在新的 containerd shim API 中，containerd-shim 被定义为一个接口，
交给 runtime 来实现。
• 新的 kata shimv2 实现可以实现每个 Pod 一个 shim，不再需要很多辅助的
kata-shim 进程了。
• 这部分功能在去年年底被 merge，并且已经在年初的 kata 1.5 版本中
release 了。
• 这是Kata项目对整个容器社区的推动的一个例子。
• Kata Container と gVisor がOpen Sourceになった機会で、Communityはコ
ンテナを隔離する技術がNamespacesだけじゃなくことを認めっています。
• Kata Container や gVisor のような隔離層があるコンテナ技術、Hostでコン
テナが一つコンテナに唯一PIDで代表（だいひょう）することがありません
でした。
• なので、新しいContainerd Shim APIで、containerd-shimがインタフェース
として定義されて、runtimeに実現されます。
• 新しいKata shimv2は各Podに独立のshimを提供します。補助kata-shimも
要らなくなりました。
• この部分は去年の年末にMergeされて、ことしのkata 1.5バージョンでリリ
ースする時、公開しました。
• これはkataプロジェクトがコンテナcommuityへ良い影響を及ぶと思われて
います。

12. • 另一个例子是AWS在去年11月开源了FireCracker项目
• FireCracker可以被看作是一个用rust写的Qemu，它没有各种模拟硬件模型，
所以非常轻小
• 但对于多数云上的应用来说，这已经够了
• 从1.5版本开始，Kata Containers支持了FireCracker，对于可以使用
FireCracker的情况，这可以显著地降低开销。
• 不过，并不是所有情形都可以使用FireCracker，有些需要访问硬件的场景下，
还是需要使用Qemu
• まだ一つ例があります。去年の11月にAWS社はFireCrackerプロジェクトを
公開しました。
• FireCrackerはRust言語でQEMUの機能を実現したプロジェクトと思われて
ます。Hardwareを模擬されていないため、すごく軽かったです。
• 大部分のCloud Native アプリに対して、十分だったと思います。
• kata 1.5バージョンからFireCrackerをサポートされています。FireCracker
を利用する場合、リソースの利用率をすごく下げます。
• ただ、FireCrackerはすべてケースで利用できるわけない、Hardwareへアク
セスする場合、QEMUの利用が必要です。

13. • 随着 Kata、gVisor 的发展，这种为不同 workload 使用不同 runtime 的需求
逐渐增长出来
• Kubernetes 从 1.12 开始引入了 RuntimeClass 的概念
• 用户可以在 PodSpec 里指定自己的 runtime 选择
• 在 RuntimeClass 被引入之前，不同的CRI实现定义了各不相同的 annotation
来支持类似的功能
• 现在它已经成为标准API的一部分，containerd 和 CRI-O 都可以支持
RuntimeClass
• KataとgVisorの発展して、workloadによって異なるruntimeを利用する要望
が順々出ています。
• Kubernetes1.12から RuntimeClass概念を導入しました
• ユーザーはPodSpecの中に、自分のRuntimeを選択できます。
• RuntimeClassの概念を引き込むまえ、この対して、CRIはannotationの定義
でRuntimeを選択できるような機能をすでに実現しました。
• 現在、RuntimeClassは標準APIになりました。containerdとCRI-Oは
RuntimeClassをサポートしています。

14. • 比如这里，一些可信应用，甚至是集群服务的组件，可以用 RuntimeClass指
定用 runc 运行
• 一些轻量级的用户应用，指定用 Kata 运行，并配置使用 FireCracker 作为
VMM
• 另一些可能是需要 passthrough GPU 的用户应用，则用 Kata 放在 Qemu 里
运行
• 例えば、一部分信頼できるアプリ、更にクラスタのコンポーネントも
RuntimeClassを指定して、Runcで動けます。
• 軽いアプリはKataとFireCracker組み合わせて、動けます。
• まだ一部分GPUを利用するアプリはKataとQEMUと組み合わせて、実現で
きます。

15. • 下面我们来看两个Demo
• 次、2つDemoを見せてください。
15

16. • Kata 是一个积极开发中的项目，这里是项目的各种访问方式，欢迎大家来参
与
• kata は積極的に開発されているプロジェクトです。こちらはプロジェクト
のアクセス方式です。皆様のご意見をいただくとか、参加することを大歓
迎(かんげい)です。
16

17. • 这里是 Kata 的一些开发方式
• 首先是近期的，shim v2 目前在 containerd 中有良好的支持，CRI-O 的支持
尚在开发中
• 对于网络的优化也是一部分
• 9p 是此前 kata 使用的文件系统访问方式，但是 9p 有很多问题，既有性能问
题，也有一些 POSIX 的兼容性问题
• 目前我们和 RedHat 合作，将 virtio-fs 作为新的 Kata 的文件系统访问方式
• 目前在 1.7 版本中已经带有 virtio-fs 的实验性支持了，我们希望在三四个月
内让它达到产品可用的状态
• Kata 的中期和长期目标聚焦在进一步提升安全性、易用性和灵活性上。
• こちらはKataの開発方式です
• まず、shim v2はcontainerdによくサポートされています。CRI-Oに対する
サポートがまだ開発中です。
• ネットワークのチューニングも開発中です。
• Kataは9p を利用して、ファイルシステムのアクセスしています。しかし、
9pが性能の問題があるつつ、POSIXの兼用性（けんようせい）の問題もあ
ります。
• 今RedHatと連携して、virtio-fsをKataの新しいファイルシステムのアクセス
コンポーネントとして利用されています。
• 現在1.7バージョンでvirtio-fsをテストしています。三四月内に、動けるよう
に努力しています。
• Kataは中長期の目標は安全性、使いやすさと柔軟性（じゅうなんせい）ア
ップします

18. 谢谢大家
ご清聴ありがとうございました。
18