狠狠撸

Copyright?2018 NTT corp. All Rights Reserved.
今話題のいろいろな
コンテナランタイムを比較してみた
2018/11/21
日本電信電話株式会社
ソフトウェアイノベーションセンタ
徳永航平
Docker Meetup Tokyo #26

2Copyright?2018 NTT corp. All Rights Reserved.
自己紹介
名前徳永航平
所属 NTT ソフトウェアイノベーションセンタ
年次 1年目
興味
コンテナ仮想化技術
特に、コンテナランタイム領域
勉強中

ランタイム毎に異なる特徴
群雄割拠なコンテナランタイム領域
Pod
Containers
セキュリティ
機能
パフォーマンス
kubelet
開発動向

本資料におけるkubelet以下のレイヤ区別
? kubeletからのPod生成などの指示を処理する。
? kubeletとはunix socket経由のgRPCで通信。その
インタフェースはCRIと呼ばれる。
? コンテナ作成は低レイヤランタイム使用(rkt除く)。
? 高レイヤランタイム/Dockerの指示でコンテナ作成。
? OCIという標準仕様あり。
? セキュリティの担保のため、様々なランタイムが隔
離手法を提案しており群雄割拠。 Pod
低レイヤランタイム
(OCIランタイム)
実行
kubelet
CRI socket
高レイヤランタイム
高レイヤ(High-level)ランタイム
低レイヤ(OCI、Low-level)ランタイム
runc
Nabla Containers
gVisor
Kata Containers
Containers
unix
socket
[The Kubernetes Authors. "Introducing Container Runtime Interface (CRI) in ;Kubernetes -
Kubernetes". https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/]

今回比較する項目
Pod
実行
kubelet
CRI socket
Containers
パフォーマンス開発動向機能
セキュリティパフォーマンス開発動向
各ランタイムの
機能を定性比較
それぞれの隔離
手法を定性比較
基本操作を計測
し定量比較
githubのコミッ
ト数推移を比較
githubのコミッ
ト数推移を比較
基本操作を計測
し定量比較

測定ツールスペック
測定項目測定用image
パフォーマンスはCRI経由で測定
? k8s Node SIGのランタ
イムテスト用ツール
? CLIからCRI命令発行可
? critestには各CRI命令の
性能測定機能あり
Stop
while(1)
printf ("%d?n", i++);
下記のscratch image
※ runnc用にはrumprunを用い
unikernelとしてクロスコンパ
イル(付録に詳細記載)
critoolsを使用
※containerd+runscにはgVisor
プロジェクトのテスト用shim使
用(付録に詳細記載)
Pod/コンテナのlifecycle
Pod
実行
CRI socket
critools
Containers
×100
32 × Intel(R) Xeon(R) CPU
E5-2667 v3 @ 3.20GHz
65864456 kB
Ubuntu 16.04（Linux ubuntu
4.4.0-139-generic）
? CPU:
? メモリ:
? OS:
詳細な測定仕様については付録スライドを参照ください。
[https://github.com/kubernetes-sigs/cri-tools]

目次
Pod
Containers
実行
kubelet
CRI socket
1. 高レイヤランタイムの比較
2. 低レイヤランタイムの比較
3. まとめ

containerdの概要
Pod Container
Image その他
作成削除
管理管理
OCIランタイム制御
push pull
展開
Go API
機能の概要
pouch containerでも
利用されている
? MobyプロジェクトおよびCNCFプロジェクト。
? もともとDocker Engineの一部であり、コンテナ
実行を担ってきた。今も使われている。
? CRI対応のプラグインによりCRI経由で操作可能。
CRI
plugin
Pod
OCI
shim
CNI
CRI socket
kubelet
pause
Containers
NW
設定コンテナ
生成
直近約１年のコミット数推移
[The containerd authors.“containerd - An industry-standard container runtime with an emphasis on simplicity, robustness and portability”.
https://containerd.io/; The Containerd Authors.“Architecture of The CRI Plugin”. https://github.com/containerd/cri/blob/master/docs/architecture.md;
PouchContainer team. "ctrd".https://github.com/alibaba/pouch/blob/master/ctrd/README.md]
[https://github.com/containerd/containerd][https://github.com/containerd/containerd/graphs/commit-activity]
2018.11.21取得

CRI-Oの概要
Pod Container
Image その他
作成削除
管理管理
OCIランタイム制御
pull
展開
機能の概要
conmon
conmon
Pod
NW
設定
infra
CNI OCI
CRI socket
kubelet
CNI
ログ収集
?監視
conmon conmonContainers
コンテナ
生成
[CRI-O Contributors. “cri-o”.http://cri-o.io/; CRI-O Contributors. “Monitoring”.http://cri-
o.io/#monitoring; Antoine Beaupré. “CRI-O: the minimal runtime”.
https://lwn.net/Articles/741897/]
[https://github.com/kubernetes-sigs/cri-o]
? KubernetesのNode SIGのプロジェクト。Red
Hat主導で立ち上げられた。
? CRI指向、Pod指向で設計されている。
? conmonデーモンが各コンテナを監視する。
[https://github.com/kubernetes-sigs/cri-o/graphs/commit-activity]
2018.11.21取得

rktの概要
Pod Container
Image その他
作成削除
管理管理
pull
展開
機能の概要
作成削除
Stage1による
セキュリティ担保
Pod
apps
v1alpha1
(k8s＜1.10)
systemd
-run
Pod
生成
stage1
service
として
起動
systemd
CRI socket
kubelet
app
追加/削除
Pod生成用
イメージ
[Red Hat, Inc.. “rkt, a security-minded, standards-based container engine”. https://coreos.com/rkt/; The Kubernetes Authors. “Proposal: Design of the rkt +
Kubernetes CRI”. https://github.com/kubernetes-incubator/rktlet/blob/master/docs/initial-design.md; Red Hat, Inc..
"Architecture".https://coreos.com/rkt/docs/latest/devel/architecture.html]
[https://github.com/rkt/rkt]
? CNCFプロジェクト。CoreOS主導で開発が開始。
? Pod指向、低レイヤランタイム機能を内包。
? rkt自身はCRIを見張るデーモンではなく、rktlet
がその役割を担う。rktはsystemd経由で起動。
[https://github.com/rkt/rkt/graphs/commit-activity]
2018.11.21取得

Podのパフォーマンス比較
2.483
0.283
0.28
0.029
0
0.001
0.074
0.27
0.281
0.205
0.005
0.016
0 0.5 1 1.5 2 2.5 3
RunPodSandbox PodSandboxStatus
StopPodSandbox RemovePodSandbox
高レイヤランタイム(+runc)のPodライフサイクルパフォーマンス
秒
+coreos
+runc
+runc

高レイヤランタイム(+runc)のコンテナライフサイクルパフォーマンス
コンテナのパフォーマンス比較
0.237
0.035
0.09
0.083
0.126
0.016
0.03
0.001
0.002
0.072
0.128
0.151
0.426
0.004
0.014
0 0.1 0.2 0.3 0.4 0.5
CreateContainer StartContainer ContainerStatus
StopContainer RemoveContainer
+coreos
+runc
+runc
Stop
秒

CRI
plugin
高レイヤランタイムのまとめ
Pod
OCI
shim
CNI
pause
Containers
conmon
conmon
Pod
infra
CNI OCI
Pod
apps
stage1
systemd
? Moby,CNCFプロジェ
クトとして開発が盛ん。
? イメージのpushやGo
APIなど多機能である。
? パフォーマンスは概ね
高いが、Pod?コンテ
ナの起動および停止に
時間がかかる。
? k8s SIG主導で、開発
は比較的盛んである。
? CRI実装に必要な必要
最低限の機能を持つ。
? パフォーマンスは概ね
高いが、Podの起動停
止、コンテナの作成停
止に時間がかかる。
? 開発は最近あまり盛ん
ではなくなりつつある。
? stage1-imageに応
じてnamespaceやVM
など様々な隔離手法を
選択することができる。
? CRI経由では全体的に
低パフォーマンス。
Pod生成用
イメージ

目次
Pod
Containers
実行
kubelet
CRI socket
3. まとめ

runcの概要
? OCIによる、OCIランタイムのリファレンス的実装。
? Linuxのリソース分離やセキュリティ機能を活用してプロセスの実行環境隔離を実現。
? 前身は、Dockerの一部だったlibcontainerで、DockerがOCP(現OCI)発足の際に譲渡。
? rootless実行モードも備えている。
namespaces
PID、UTS、IPC、マウ
ントポイント、ネット
ワーク、ユーザ、
cgroupsについてシス
テムのリソースを隔離
各コンテナごとに見える
ファイルシステムを制限
pivot_root
Linuxの
セキュリティ機構
memory,cpu,cpuset,
pids…などのハード
ウェアリソースを
subsystem単位でコン
テナごとに隔離?管理
AppArmor,SELinux,s
eccompを用いてコン
テナの動作をセキュア
なものに制限
process
runc
runc
Host kernel
cgroups
[Open Container Initiative. “Open Container Initiative Runtime Specification”. https://github.com/opencontainers/runtime-
spec/blob/master/spec.md; runc Contributors. “Container Specification - v1”.
https://github.com/opencontainers/runc/blob/master/libcontainer/SPEC.md]
[https://github.com/opencontainers/runc] [https://github.com/opencontainers/runc/graphs/commit-activity]
2018.11.21取得

runscの概要
sentry
(user space kernel)
Linuxシステムコールの
ユーザ空間での実装。
p t r a c e あるいは
kvm(experimental)で
システムコールをキャプ
チャして、ハンドルする。
sentryのシステムコール
はseccompで約50種程
度に制限される。
gofer
sentryとは独立したプロ
セスとして動作し、
sentryの代わりにファイ
ルへのアクセスを担う。
go
go
go
sentry
go runtime
+ gofer
seccomp
goroutine
各アプリケーションは
goroutineとして動作。
goランタイムがユーザ空
間上でスケジューリング。
? Googleが開発中のランタイム。ユーザ空間カーネルにより環境を隔離。
? 2つのプロセス(sentry?gofer)が協調して動作し、カーネルを模倣する。
? アプリケーションが発行するシステムコールはsentryがキャプチャしハンドルする。
? sentry自体はseccompにより限定されたシステムコールのみを発行する。
runsc(gVisor)
Host kernel
[Google LLC. “Background”. https://github.com/google/gvisor/blob/master/pkg/sentry/kernel/README.md#background;
Google LLC. https://github.com/google/gvisor/blob/master/runsc/boot/filter/config.go#L27]
[https://github.com/google/gvisor]
2018.11.21取得
[https://github.com/google/gvisor/graphs/commit-activity]

runncの概要
nabla-run tender
solo5 unikernelの低レイ
ヤ層コンポーネント。
unikernelからは関数呼び
出しで要求を受ける。
tender自身は7種のシス
テムコールのみを発行。
前段バイナリ
前段のバイナリがrootfs
に対応するisoイメージ
を生成したりNWのセッ
トアップをしたりする。
pauseコンテナ実行の際
はrunnc自らpauseする。
solo5 unikernel
rumprun(NetBSD)や
miregeOS等のunikernel
イメージ。solo5向けに
クロスコンパイルする。
Host kernel
nabla-run
seccomp
App
runnc
-cont
runnc
glue
solo5 API
unikernelからtenderへ
の要求発行API。solo5
プロジェクトが開発。
? IBMによるランタイム。unikernel技術を応用して実行環境を分離。
? rumprun等でsolo5向けにクロスコンパイルしたunikernelを実行可能。
? 本来HWやXenにあたるハイパバイザレイヤ以下をコンテナランタイムに置換えた。
? アプリケーションが発行する要求はユーザ空間でランタイムがハンドル。
runnc(Nabla Containers)
[Nabla Containers Contributors. “Nabla Containers”. https://nabla-containers.github.io/; James Bottomley‘s
random Pages. “A New Method of Containment: IBM Nabla Containers”.
https://blog.hansenpartnership.com/a-new-method-of-containment-ibm-nabla-containers/]
[https://github.com/nabla-containers/runnc]
2018.11.21取得
[https://github.com/nabla-containers/runnc/graphs/commit-activity]

kata-runtimeの概要
Pod（VM）
PodとしてLinux込みの
V M が作成される。
VM内でコンテナが起動。
agent
VM内でコンテナ管理する
デーモン。libcontainer
でコンテナ環境を作成。
runcの大部分を再利用。
proxy
VM内のagentと他のコ
ンポーネントのgrpc通信
用virtioを中継。vsockの
場合は多コネクション張
れるのでproxyは不要。Linux(KVM)
Linux
agent
C
C
C
proxyVM
shim
runtime
virtio
shim
VM内のコンテナを可視
化するためにVM内のコ
ンテナを模倣。I/Oやシ
グナルをフォワードする。
? OpenStack Foundationのプロジェクト。軽量なVMにより環境を分離する。
? PodごとにVMを作成し、ホストやPod間でカーネルを共有しない。
? 原理的には、他のアプローチに比べホストOSに対する隔離が強いと考えられる。
? VM上でPodを起動する際にはnested virtualizationになる。
kata-runtime(Kata Containers)
[The OpenStack Foundation. “Kata Containers - The speed of containers, the security of VMs”. https://katacontainers.io/; Kata
Containers Contributors. “Kata Containers Architecture”. https://github.com/kata-
containers/documentation/blob/master/architecture.md]
[https://github.com/kata-containers]
2018.11.21取得
[https://github.com/kata-containers/runtime/graphs/commit-activity]

Podのパフォーマンス比較
0.283
0.355
0.16
1.129
0
0
0
0
0.27
0.396
0.282
0.319
0.005
0.004
0.005
0.004
0 0.2 0.4 0.6 0.8 1 1.2
RunPodSandbox PodSandboxStatus
StopPodSandbox RemovePodSandbox
秒
低レイヤランタイム(+containerd)のPodライフサイクルパフォーマンス
runc
+
runsc
(ptrace)
runnc
kata-
runtime このフェーズでVMが起動する
+
+
+

コンテナのパフォーマンス比較
0.035
0.036
0.039
0.037
0.126
0.113
0.06
0.11
0.001
0.001
0.001
0.001
0.128
0.308
0.143
0.273
0.004
0.005
0.005
0.004
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35
CreateContainer StartContainer ContainerStatus
StopContainer RemoveContainer
低レイヤランタイム(+containerd)のコンテナライフサイクルパフォーマンス
Stop
秒
runc
+
runnc
kata-
runtime
+
+
runsc
(ptrace)
+

パフォーマンス総合ランキング
0.695
0.851
0.852
0.865
1.053
1.218
1.877
2.005
3.639
0 1 2 3 4
ランタイムの全組み合わせでの全操作合計時間のパフォーマンス
秒
runc
runnc
kata-
runtime
kata-
runtime
runc
runnc
runsc
(ptrace)
coreos
+
+
+
+
+
+
+
+
+
runsc
(ptrace)

低レイヤランタイムのまとめ
process
go
go
go
sentry
go runtime
+
seccomp
nabla-run
seccomp
App
glue
Linux
agent
C
C
C
VM
Linuxのセキュリ
ティ機構の活用や
rootless実行に
よりアプリケー
ションからシステ
ムへの影響最小化。
高パフォーマンス。
runc katarunsc runnc
限定的なシステム
コール発行(50種
程度)。syscallの
インターセプトに
よるオーバヘッド
はあるがパフォー
マンスは概ね良好。
限定的なシステム
コール発行(7種)。
パフォーマンスも
runcと同程度か
それ以上に高い。
unikernelベース
のimageが実行可。
Pod毎にVMを起
動。原理的には他
手法よりカーネル
からの隔離は強い
だろう。しかし
Pod(≒VM)の起動
に時間がかかる。
カーネル共有ユーザ空間カーネル unikernel VM

目次
Pod
Containers
実行
kubelet
CRI socket
3. まとめ

紹介したコンテナランタイムの一覧
Pod
apps
stage1
Pod生成用
イメージ
process
go
go
go
sentry
go runtime
+
seccomp
nabla-run
seccomp
App
glue
Linux
agent
C
C
C
VM
CRI
plugin
shim
systemd
CRI socket
kubelet
Pod
pause
Containers
conmon
conmon
Pod
infra
runc
kata-
runtimerunsc runnc
高レイヤランタイム CRI

付録１:使用ツールの一覧と留意点
? containerd[https://github.com/containerd/containerd]：v1.2.0
? containerd config defaultコマンドによるデフォルト設定を適用。(snapshotter：overlayfs)
? CRI-O[https://github.com/kubernetes-sigs/cri-o]：1.12.1-dev(Git revision: 62527471ba71719eb790c6feed152f956aa8a03d)
? make install.configによるデフォルト設定を適用。(storage_driver：overlayfs)
? rkt[https://github.com/rkt/rkt]：1.30.0
? rktlet[https://github.com/kubernetes-incubator/rktlet]：0.1.0
? runc[https://github.com/opencontainers/runc]：1.0.0-rc4
? runsc[https://github.com/google/gvisor]：Git revision: 704b56a40d0a041a4e6f814c3dbb1f9ec15f9002
? gvisor_containerd_shim：2018/11/05 取得。測定時現在の本環境では、CRI経由の場合runsc + containerd-shimの組み合わせでは正常に
動作しませんでした。そこで、本測定ではgVisorプロジェクトでrunscのテストに用いられる専用shimを使用しました。この専用shimはバイナ
リ形式で頒布されています。shimの頒布URLについては以下を参照ください。なお、containerd側でconfig.toml中の「runtime_root」を
「/tmp/test-containerd/runsc」に変更する必要があります。詳細はgVisorのテスト関連コードをご覧ください。
? https://github.com/google/gvisor/blob/704b56a40d0a041a4e6f814c3dbb1f9ec15f9002/kokoro/run_tests.sh#L79
? runnc[https://github.com/nabla-containers/runnc]：1.0.1
? kara-runtime[https://github.com/kata-containers]：1.3.0
? critools[https://github.com/kubernetes-sigs/cri-tools]
? v1alpha2 APIに対応しないrktのみ、旧バージョンのcritoolsを使う必要がありました。
? rkt以外：1.12.0
? rkt：1.0.0-alpha.0
? 測定に使用するイメージ (デフォルトは1.12.0版でbusybox:1.28、1.0.0-alpha.0版でbusybox:1.26)の変更とベンチマーク実行回数
(デフォルトは20回)の変更には、ソースを修正する必要がありました。
? イメージの変更： /pkg/framework/util.go: 53行目
? イメージ内での実行コマンド(Dockerにおけるentrypoint)の指定：/pkg/framework/util.go:184行目
? ベンチマーク実行回数：/pkg/benchmark/pod.go:29行目
? rumprun[https://github.com/nabla-containers/rumprun.git]：solo5ブランチ使用。
? Git revision: 8b01b37edf9d2e54a043641d5552bdf1add3225f
? buildrump.sh submoduleのGit revision: ff34576345f912761619b0fe7a0295b8dc22a016
? src-netbsd submoduleのGit revision: b8b951e911a2fc555848a2785a9998bc128530b6
? 本測定環境では以下のissueへのパッチをrumprunアップストリームから取り込む必要がありました。
? issue: https://github.com/rumpkernel/rumprun/issues/122
? パッチ: https://github.com/NetBSD/src/commit/713e2f607aad1cfffe1d814843fe7df5d1780bfc#diff-
7a238ffcc3c5bd264217ae97b4c893df
? issue: https://github.com/rumpkernel/rumprun/pull/118
? パッチ: https://github.com/rumpkernel/rumprun/commit/94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c

付録２:性能測定用イメージの作成手順
#include <stdio.h>
void main()
{
int i = 0;
while(1) {
printf ("%d?n", i++);
}
}
FROM scratch
ADD loop /
ENTRYPOINT ["/loop"]
FROM scratch
ADD loop.nabla /
ENTRYPOINT ["/loop.nabla"]
本測定では、リスト１に示すプログラムのみを実行するscratchイメージを使用しました。
リスト１：loop.c リスト２：通常のイメージ生成用Dockerfile
リスト3：runncイメージ生成用Dockerfile
runnc以外のランタイムに使用するイメージとして、リスト１のプログラムをgcc 7.3.0に-staticオプションを付与してコン
パイルし、リスト2に示すDockerfileでイメージを生成しました。
runncではunikernelベースのイメージのみ使用可能です。前項スライドに示したsolo5ブランチ版のrumprunを用い、以下の
ようにunikernelを生成しました。なお、手順にはrumprunのチュートリアルページを参考にしました。
https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikernels
? まず、solo5 unikernelとnabla-run間のグルーコードを用意します。下記のソースツリーをクローンおよびmakeし、生成
されたkernel/ukvm/solo5.oを「libsolo5_seccomp.a」にリネームしてパスを通しました。
? https://github.com/nabla-containers/solo5.git
? Git rev: 625bbb3b61e85128cd8fa6a46239ffa4bd2cb2e8
? 以下のコマンドでクロスコンパイラを生成しました。
CC=cc ./build-rr.sh solo5 -- -F CFLAGS=-Wimplicit-fallthrough=0
? 得られたクロスコンパイラ(/rumprun-solo5/bin/x86_64-rumprun-netbsd-gcc)でリスト１をコンパイルしました。
x86_64-rumprun-netbsd-gcc -o loop.out loop.c
? 以下のコマンドで、グルーコードがリンクされたunikernelを得ました。最後にDockerfileでイメージを生成しました。
rumprun-bake solo5_ukvm_seccomp loop.nabla loop.out
? この時、unikernel名に接尾辞「.nabla」を付与しなかった場合、runncの実行時にエラーが発生するようです。
? https://github.com/nabla-containers/runnc/blob/master/libcontainer/init_nabla.go#L40

狠狠撸

今话题のいろいろなコンテナランタイムを比较してみた

More Related Content

今话题のいろいろなコンテナランタイムを比较してみた