Slide 1
Slide 1 text
Japan Container DAYS v 18.12 @makocchi 1
runc だけじゃない
コンテナ low level runtime 徹底比較
Makoto Hasegawa | @makocchi
CyberAgent, Inc
Slide 2
Slide 2 text
Japan Container DAYS v 18.12 @makocchi 2
本日の資料は後ほど公開します
頑張って写真撮らなくても大丈夫！
Slide 3
Slide 3 text
Japan Container DAYS v 18.12 @makocchi 3
サイバーエージェント アドテク本部 所属
普段はデータセンター運用や Private Cloud(OpenStack)を
構築・運用している
最近では Private Cloud 上に
簡単に Kubernetes を展開できる基盤(AKE)を開発している
CKA (Certified Kubernetes Administrator) #150
CKAD (Certified Kubernetes Application Developper) #5
Japan Container Days v18.04
「Dockerだけじゃないコンテナ runtime 徹底比較」
TWITTER / @makocchi
Makoto Hasegawa
FACEBOOK / makocchi0923
Slide 4
Slide 4 text
Japan Container DAYS v 18.12 @makocchi 4
本題に入る前に・・・
Slide 5
Slide 5 text
Japan Container DAYS v 18.12 @makocchi 5
前回 (V18.04) のおさらい
「Dockerだけじゃないコンテナ runtime 徹底比較」
Slide 6
Slide 6 text
Japan Container DAYS v 18.12 @makocchi 6
https://www.youtube.com/watch?v=8jbJgI7Q6IU
前回のおさらい
コンテナ runtime は 2 つに分けて考えることが
できる (上位/下位 or High/Low etc)
OCI や CRI などのコンテナの規格が統一されて
きている
上位コンテナ runtime は Docker 以外にも
containerd や cri-o があり、自由に入れ替
えることができる
「Docker だけじゃないコンテナ runtime 徹底比較」
Slide 7
Slide 7 text
Japan Container DAYS v 18.12 @makocchi 7
OCI
前回のおさらい (用語的なもの)
CRI
CNI
CSI
CBI
runtime を語る上で欠かせない様々なコンテナの統一企画
CRI は Kubernetes が様々なhigh level コンテナ runtime に
対応する為に作られた統一規格
CNI は Network、CSI は Storage を pluggable に使う為の
規格
Kubernetes や CNCF で管理されてはいないが、
CBI(Container Builder Interface) なんていうのもある
OCI(Open Container Initiative)は「OCI v1.0」というコン
テナイメージ及びコンテナ runtime の標準化の仕様を策定した
Slide 8
Slide 8 text
Japan Container DAYS v 18.12 @makocchi 8
前回のお話では上位コンテナ runtime に焦点を当てて構造の違いやパフォーマンスの測定を行いました。
今日のお話は下位のコンテナ runtime に焦点を当ててお話をします。
Slide 9
Slide 9 text
Japan Container DAYS v 18.12 @makocchi 9
AGENDA
前回のおさらい
いろいろな low level runtime
low level runtime の動かし方
ベンチマークツールの紹介
ベンチマーク結果
まとめ
おまけ
Slide 10
Slide 10 text
Japan Container DAYS v 18.12 @makocchi 10
いろいろな low level runtime
定番からマニアックなものまで
Slide 11
Slide 11 text
Japan Container DAYS v 18.12 @makocchi 11
Hyper
runv
Clear Containers
cc-runtime
いろいろな low level runtime
Docker 社が開発した
libcontainer に基づく cli
後に OCI の管理となり Docker の手
を離れた
現在でも Docker の default は
runc が使われている
Docker’s default
runc
Hyper によって開発されたコンテナの
ように vm を起動させる cli
OCI に準拠
hyperkernel を使用することで
host kernel とは隔離性を担保して
いる
コンテナ向けに開発された Clear
Linux を使用
Intel VT をベースにしている
Slide 12
Slide 12 text
Japan Container DAYS v 18.12 @makocchi 12
ݩ IBM
runq
いろいろな low level runtime (まだあるよ)
runv と cc-runtime を元に開発さ
れた runtime
OpenStack Foundationがホストし
ている
Kata containers
kata-runtime
IBM によって開発されたが後に OSS
として公開
コンテナのように qemu が起動する
最小限のコードで構成されていてとても
シンプルで導入しやすい
Rust で実装された runtime
「go は名前空間の取扱が不十分な
のでコンテナ runtime には rust が適
している」らしい (※)
もちろん OCI 準拠
Oracle
railcar
(※) https://orablogs-jp.blogspot.com/2017/07/building-container-runtime-in-rust.html
Slide 13
Slide 13 text
Japan Container DAYS v 18.12 @makocchi 13
Nabla containers
runnc
いろいろな low level runtime (まだまだあるよ)
IBM Research によって開発されたセ
キュリティに重点を置いた runtime
Solo5 の unikernel を拡張している
ホスト側への system call が通常よ
りもかなり減っている
gVisor
runsc
Google が OSS として公開した
runtime
コンテナを sandbox 環境で実行しセ
キュリティを担保
ユーザー空間で可動する Sentry がコ
ンテナアプリケーションの syscall をイン
ターセプトして代わりに実行する
Slide 14
Slide 14 text
Japan Container DAYS v 18.12 @makocchi 14
Nabla containers
runnc
いろいろな low level runtime (まだまだあるよ)
IBM Research によって開発されたセ
キュリティに重点を置いた runtime
Solo5 の unikernel を拡張している
ホスト側への system call が通常よ
りもかなり減っている
gVisor
runsc
Google が OSS として公開した
runtime
コンテナを sandbox 環境で実行しセ
キュリティを担保
ユーザー空間で可動する Sentry がコ
ンテナアプリケーションの syscall をイン
ターセプトして代わりに実行する
ふかぼる！
Slide 15
Slide 15 text
Japan Container DAYS v 18.12 @makocchi 15
Nabla containers とは・・・・？
https://nabla-containers.github.io/
コンテナ環境の隔離を unikernel(Library OSとも言う) の
技術を用いて実現
unikernel とはアプリケーションの動作に必要な機能のみ実
装された OS で single process しか動かない
nabla-run tender は unikernel のアプリケーションからの
要求を受け、ホスト側の kernel の system call を発行
nabla-run tender は 7 種類の system call しか発行し
ない (read/write/exit_group/clock_gettime/
ppoll/pwrite64/pread64)
solo5 は Xen で可動する MirageOS を linux/kvm で動
くように porting したもの
Slide 16
Slide 16 text
Japan Container DAYS v 18.12 @makocchi 16
Nabla containers とは・・・・？
https://nabla-containers.github.io/
つまり unikernel で compile したアプリケーションじゃないと動かない
その為、通常の docker image は利用不可
unikernel でアプリケーションを作成するのはとても手間がかかる・・・めんどくさい
作成手順は「Tutorial: Building Rumprun Unikernels」が参考になります
https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikernels
Slide 17
Slide 17 text
Japan Container DAYS v 18.12 @makocchi 17
Nabla containers とは・・・・？
でもそんな事しなくても簡単に image 作れるように
demo を用意しているよ！
Slide 18
Slide 18 text
Japan Container DAYS v 18.12 @makocchi 18
nabla-containers/nabla-demo-apps
nabla containers 用の nodejs / python /
redis / go のアプリケーション用の image 作成の
demo(Dockerfile) が置かれている
FROM に nablact/nabla-xxx-base を使が使われて
いる (nabla-node-base とか nabla-go-base)
https://github.com/nabla-containers/nabla-demo-apps
Nabla containers とは・・・・？
nabla-containers/nabla-base-build
nabla-xxx-base の Dockerfile がある
https://github.com/nabla-containers/nabla-base-build
Slide 19
Slide 19 text
Japan Container DAYS v 18.12 @makocchi 19
Nabla containers とは・・・・？
sample の go の image
makocchi/go-httpd-nabla
$ sudo docker run -d -p 3000:3000 —runtime runnc makocchi/go-http-nabla
a5f16d31a6d625ee2f48b7a82b02e22ee42a127266cd9cc3a125bc7d7f9b5a6c
$ curl localhost:3000
Response 200 from go-http
Slide 20
Slide 20 text
Japan Container DAYS v 18.12 @makocchi 20
Nabla containers
runnc
いろいろな low level runtime (まだまだあるよ)
IBM Research によって開発されたセ
キュリティに重点を置いた runtime
Solo5 の unikernel を拡張している
ホスト側への system call が通常よ
りもかなり減っている
gVisor
runsc
Google が OSS として公開した
runtime
コンテナを sandbox 環境で実行しセ
キュリティを担保
ユーザー空間で可動する Sentry がコ
ンテナアプリケーションの syscall をイン
ターセプトして代わりに実行する
ふかぼる！
ふかぼった！
Slide 21
Slide 21 text
Japan Container DAYS v 18.12 @makocchi 21
gVisor とは・・・・？
https://github.com/google/gvisor
アプリケーションが呼び出した system call を gVisor(sentry) が
ptrace でキャプチャして制御する
ここでいう”制御”というのは filter しているとかではなく、go で
system call を再実装したものになる
当然まだ実装されていない system call があるのでアプリケーション
によっては動かなかったり予期しない動きをするかも
ptrace の他に kvm mode がある (experimental)
アプリケーションは sentry 内の goroutine として動作する
sentry 自体は file へのアクセスは行わず、gopher という別のプ
ロセスに処理を渡す (9P プロトコル)
GCP の GAE(Google App Engine)で使われている (Java8/
nodejs)
Slide 22
Slide 22 text
Japan Container DAYS v 18.12 @makocchi 22
gVisor とは・・・・？
gVisor あるある (/proc/version)
$ sudo docker exec gvisor_caontiner uname -a
Linux gvisor_caontiner 4.4 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 Linux
https://github.com/google/gvisor/blob/master/pkg/sentry/syscalls/linux/linux64.go#L37-L48
Slide 23
Slide 23 text
Japan Container DAYS v 18.12 @makocchi 23
gVisor とは・・・・？
gVisor あるある (dmesg)
$ sudo docker exec gvisor_caontiner dmesg
[ 0.000000] Starting gVisor...
[ 0.359579] Constructing home...
[ 0.406130] Searching for socket adapter...
[ 0.900918] Committing treasure map to memory...
[ 0.992631] Consulting tar man page...
[ 1.158857] Segmenting fault lines...
[ 1.620077] Digging up root...
[ 1.750860] Creating bureaucratic processes...
[ 1.861161] Mounting deweydecimalfs...
[ 2.071900] Preparing for the zombie uprising...
[ 2.429197] Checking naughty and nice process list...
[ 2.870710] Ready!
「Starting gVisor…」と「Ready!」は固定
その間の 10 行は random に生成されている
なのでコンテナ毎に異なる dmesg になっているはず
Time の部分も random
Slide 24
Slide 24 text
Japan Container DAYS v 18.12 @makocchi 24
gVisor とは・・・・？
dmesg の実装のところはここを見て下さい
よく見ると遊び心が満載
https://github.com/google/gvisor/blob/master/
pkg/sentry/kernel/syslog.go#L49-L76
Slide 25
Slide 25 text
Japan Container DAYS v 18.12 @makocchi 25
rkt
OCI ではなく appc という spec で可動する runtime
CoreOS によって開発されていた
現在は OCI に準拠するように開発が進んでいる
いろいろな low level runtime (番外編)
lxc
アプリケーションコンテナとは違い、システムコンテナとも言われる
Alibaba では OCI 準拠の runlxc というものを開発している(ぽい)
上位 runtime としては lxd が相当する
CRI 経由で lxc を起動する lxe なんていうのもある (※)
(※) https://github.com/automaticserver/lxe
Slide 26
Slide 26 text
Japan Container DAYS v 18.12 @makocchi 26
隔離性が高い
隔離性が低い
導入が容易
導入が複雑
runc
kata-runtime
runq
runsc
railcar
runnc
※あくまで主観
Slide 27
Slide 27 text
Japan Container DAYS v 18.12 @makocchi 27
いったい我々はどの low level runtime を使えばいいのだろうか？
runXX
Slide 28
Slide 28 text
Japan Container DAYS v 18.12 @makocchi 28
セキュリティに気を付けなければならない環境であれ
ば隔離性の高い runtime が必要になってくる
性能にシビアな環境であればコンテナの lifecycle
の性能がいいものを選択すべき
もちろん複数の runtime を混在させてもいい
求められる要件をしっかりと把握することが大切
様々な要件によって使うべき runtime は
変わってくる 導入のしやすさは？
セキュリティ要件は？
性能要件は？
いろいろな low level runtime (考察)
← ? →
← ? →
← ? →
Slide 29
Slide 29 text
Japan Container DAYS v 18.12 @makocchi 29
runtime B
0.21 ms
runtime A
0.16 ms
やっぱり気になってくるのが性能ですよね
Slide 30
Slide 30 text
Japan Container DAYS v 18.12 @makocchi 30
low level runtime の動かし方
Docker や containerd に頼らなくても
コンテナを動かすことができるようになろう
性能の話の前に・・・
Slide 31
Slide 31 text
Japan Container DAYS v 18.12 @makocchi 31
low level runtime の動かし方
runc 及び Docker を install しておく
Docker の image から rootfs を作成
今回は nginx の image を使ってみる
STEP 1 | rootfs の作成
$ mkdir -p runc/rootfs
$ sudo docker run --rm --detach --name nginx_runc nginx:latest
$ sudo docker export nginx_runc | tar xf - -C runc/rootfs
# nginx ىಈ༻ʹগ͠मਖ਼͓ͯ͘͠
$ sudo chown 101.101 runc/rootfs/var/cache/nginx/*
$ sudo chown root.root runc/rootfs/run/nginx.pid
# docker ίϯςφফ͓ͯ͘͠
$ sudo docker stop nginx_runc
Slide 32
Slide 32 text
Japan Container DAYS v 18.12 @makocchi 32
low level runtime の動かし方
runc の設定は config.json で行う
runc spec で自動生成される
$ cd runc
# config.json Λ࡞
$ runc spec
$ ls
config.json rootfs
作成された config.json は default 値なので nginx 用に編集が必要
STEP 2 | config.json の作成
Slide 33
Slide 33 text
Japan Container DAYS v 18.12 @makocchi 33
low level runtime の動かし方
編集箇所
---
"terminal": false, # true -> false
---
"args": [ # "sh" -> "nginx" ....
"nginx",
"-g",
"daemon off;"
],
---
"root": {
"path": "rootfs",
"readonly": false # true -> false
},
---
"capabilities": {
"*": [
"CAP_AUDIT_WRITE",
"CAP_KILL",
"CAP_NET_BIND_SERVICE",
"CAP_SETUID", # <- Ճ
"CAP_SETGID" # <- Ճ
],
---
Slide 34
Slide 34 text
Japan Container DAYS v 18.12 @makocchi 34
low level runtime の動かし方
コンテナを作成してみる
$ sudo runc create nginx_runc
# ޭ͢Ε list ͰදࣔͰ͖Δ
$ sudo runc list
ID PID STATUS BUNDLE CREATED OWNER
nginx_runc 31171 created /home/jkd/work/runc 2018-11-28T13:37:05.726327108Z root
実際にはまだ nginx は起動していないが PID 31171 と表示されている
STEP 3 | コンテナの作成
Slide 35
Slide 35 text
Japan Container DAYS v 18.12 @makocchi 35
low level runtime の動かし方
PID 31171 の正体は runc init
# pid 31171 init process
$ ps -ef | grep 31171
root 31171 1 0 13:43 ? 00:00:00 runc init
この後の runc start 後にこの init process は終了する
Slide 36
Slide 36 text
Japan Container DAYS v 18.12 @makocchi 36
low level runtime の動かし方
create したコンテナを起動してみる
$ sudo runc start nginx_runc
$ sudo runc list
ID PID STATUS BUNDLE CREATED OWNER
nginx_runc 31171 running /home/jkd/work/runc 2018-11-29T01:27:32.714914111Z root
$ ps -ef| grep 31171
root 31171 1 0 01:27 ? 00:00:00 nginx: master process nginx -g daemon off;
systemd+ 31190 31171 0 01:27 ? 00:00:00 nginx: worker process
起動完了！
STEP 4 | コンテナの起動
Slide 37
Slide 37 text
Japan Container DAYS v 18.12 @makocchi 37
low level runtime の動かし方
コンテナの停止は kill で行う
$ sudo runc kill nginx_runc
$ sudo runc list
ID PID STATUS BUNDLE CREATED OWNER
nginx_runc 0 stopped /home/jkd/work/runc 2018-11-29T01:27:32.714914111Z root
$ sudo runc delete nginx_runc
ID PID STATUS BUNDLE CREATED OWNER
お疲れ様でした！
STEP 5 | コンテナの停止
Slide 38
Slide 38 text
Japan Container DAYS v 18.12 @makocchi 38
low level runtime の動かし方 (rootless)
rootless で動かすこともできる
config.json に uidMappings や gidMappings の設定等が入る
その後は先程と同じような Operation が sudo 無しで可能
$ runc spec —rootless
$ runc create rootless_container
$ runc list
$ runc start rootless_container
…
…
Slide 39
Slide 39 text
Japan Container DAYS v 18.12 @makocchi 39
ベンチマークツールの紹介
ベンチマークツールはどんなものがあるのだろうか
Slide 40
Slide 40 text
Japan Container DAYS v 18.12 @makocchi 40
bucketbench
Docker client や runc を使ったコンテナの
lifecycle のベンチマークが取れる
設定ファイルは yaml 形式
driver を拡張すればいろいろ対応可能
ベンチマークツールの紹介
https://github.com/estesp/bucketbench
Slide 41
Slide 41 text
Japan Container DAYS v 18.12 @makocchi 41
cri-tools (critest)
CRI の interface を通じて benchmark をすること
ができる
コンテナの lifecycle だけではなくて pod/imgae の
操作にも対応している
ベンチマークツールの紹介
https://github.com/kubernetes-sigs/cri-tools
Slide 42
Slide 42 text
Japan Container DAYS v 18.12 @makocchi 42
結局自作しちゃった
やっぱこれが一番
今回は low level runtime を動かす際に皆さんが
もっとも使うことになるであろう Docker の client で
の操作時間を runtime 別に計測
と言っても単なる shell script
ベンチマークツールの紹介
今回コンテナの create と start で分けてベンチマーク
を取りたかったが、bucketbench は run しかサポート
していなかった
bucketbench は runc は対応しているが、runc にし
かないオプションを使うようになっていたり、全ての
runtime で統一して使うことが難しかった
critest は使用する image が busybox で固定
Iteration の回数も固定 (20)
timeout も固定 (2sec)
柔軟に使うのが大変だった
Slide 43
Slide 43 text
Japan Container DAYS v 18.12 @makocchi 43
ベンチマーク結果
お待たせしました
Slide 44
Slide 44 text
Japan Container DAYS v 18.12 @makocchi 44
Docker
18.09.0
Ubuntu
18.04.01
runtimes
7
ベンチマーク実行環境
Kernel 4.15.0-39-generic
Community Edition
runc
kata-runtime
railcar
runq
runsc (ptrace)
runsc (kvm)
runnc
Slide 45
Slide 45 text
Japan Container DAYS v 18.12 @makocchi 45
Docker create
runc
0.155
kata railcar runq runsc
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
0.148 0.152 0.152 0.153 0.151
ms
0.151
docker create は low level runtime によっ
てあまり差が出ない
若干 kata-runtime が早かったが誤差
Slide 46
Slide 46 text
Japan Container DAYS v 18.12 @makocchi 46
Docker START
runc
0.632
kata railcar runq runsc
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
2.24 0.544 0.543 0.509 0.520
ms
0.359
kata-runtime の起動は他の runtime に比べ
て時間がかかる
runnc(nabla containers) は若干起動が早い
結果となった
Slide 47
Slide 47 text
Japan Container DAYS v 18.12 @makocchi 47
Docker STOP (KILL)
runc
0.454
kata railcar runq runsc
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
0.594 0.588 0.442 0.447 0.521
ms
0.328
docker kill においても runnc が他に比べて少し
優位な結果となった
Slide 48
Slide 48 text
Japan Container DAYS v 18.12 @makocchi 48
Docker DELETE
runc
0.070
kata railcar runq runsc
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
0.070 0.069 0.070 0.070 0.069
ms
0.070
docker delete は横ばいで各種 runtime で差
がない結果となった
delete 命令だけ受け付けて、後で非同期で消
しているのかもしれない
Slide 49
Slide 49 text
Japan Container DAYS v 18.12 @makocchi 49
Docker create
runc
1.312
kata railcar runq runsc
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
3.037 1.355 1.207 1.180 1.264
ms
0.909
Docker START
Docker STOP (KILL)
Docker DELETE
一連の lifecycle 全てを組み合わせて total で
見てみると runnc が優位な結果となった
Slide 50
Slide 50 text
Japan Container DAYS v 18.12 @makocchi 50
いろいろな low level runtime (考察)
各 low level runtime での create や start の操作の performance はほぼ似通った結果となった
そもそもコンテナという軽量なアプリケーションを操作しているせいかもしれない
runnc (Nable containers) は全体的に操作の performance が良かった
隔離性もあるし、image が充実してくれば十分やっていけそう
Rust 製の railcar も他に遜色なく使える
Slide 51
Slide 51 text
Japan Container DAYS v 18.12 @makocchi 51
まとめ
あなたに合う runtime は見つかりましたか？
Slide 52
Slide 52 text
Japan Container DAYS v 18.12 @makocchi 52
特に何も考えてない人は
セキュリティを気にする人は
性能にこだわりたい人は
いろいろな low level runtime (まとめ)
runc で問題なし
特に性能が悪いわけでもなく、使い勝手がよい
Nabla container (runnc) が他に比べて性能が良い
Unikernel の image 作成の手間が気にならなければ
選択肢としては充分に考えられる
Host kernel を共有するタイプ (runc railcar) は選択肢から外れる
gVisor(runsc) や Nabla container(runnc) が候補に上がってくるが、Unikernel の image 作成が別途必要な runnc はちょっと
手間になるかもしれない
gVisor の場合には未実装の system call を使うアプリケーションは動かすことができないので、場合によってはが kata-runtime や
runq にする必要があるかもしれない
Slide 53
Slide 53 text
Japan Container DAYS v 18.12 @makocchi 53
runc だけじゃない
コンテナ low level runtime 徹底比較
Makoto Hasegawa | @makocchi
CyberAgent, Inc
Slide 54
Slide 54 text
Japan Container DAYS v 18.12 @makocchi 54
One more thing ..
Slide 55
Slide 55 text
Japan Container DAYS v 18.12 @makocchi 55
Docker だけじゃない
コンテナ high level runtime ちょっと比較
Makoto Hasegawa | @makocchi
CyberAgent, Inc
- extended -
Slide 56
Slide 56 text
Japan Container DAYS v 18.12 @makocchi 56
前回のおさらい再び
Docker client からの操作は dockerd を
経由して high level runtime の
containerd に渡り、最終的に low level
run time の runc 等が実行される
つまり containerd と直接お話してしまえば
オーバーヘッドは少なくなるはず (確信)
runc
containerd
dockerd
client
Slide 57
Slide 57 text
Japan Container DAYS v 18.12 @makocchi 57
今回のチャレンジ (ctr 編)
containerd は ctr という client から使う
ことができる
containerd 側で cri plugin が有効になっ
ていれば CRI で containerd と通信するこ
とができるようになり、その際には CRI 対応
のいろいろな client から使うことができる
(例えば kubelet)
runc
containerd
dockerd
ctr
client
ショートカット！
Slide 58
Slide 58 text
Japan Container DAYS v 18.12 @makocchi 58
create
0.155 ms
0.083 ms
dockerd を経由することによるオーバーヘッドは？
Docker client の操作と同じように ctr を使っ
て create/start/stop/delete の
lifecycle を計測
delete 以外は ctr の方がパフォーマンスが良い
Docker client からの delete 処理は、
daemon 側で受け付けた後に非同期で処理さ
れるのでは？と予想
Docker client
ctr client
Start
0.632 ms
0.346 ms
STOP (KILL)
0.454 ms
0.114 ms
DELETE
0.070 ms
0.241 ms
Slide 59
Slide 59 text
Japan Container DAYS v 18.12 @makocchi 59
https://podman.io/
Slide 60
Slide 60 text
Japan Container DAYS v 18.12 @makocchi
daemon を使わずにコンテナを管理することができる
CRI のインターフェイスを喋るわけではなく、low level runtime を操作する
もともとは CoreOS が開発していた
Docker のコマンドラインとほぼ同じ操作感 (run/ps/image/ … etc)
sudo docker run -p 8000:80 nginx
sudo podman run -p 8000:80 nginx
ps 時の表示のカラムも一緒
ちなみに似たような発想で image を作成することができる buildah というツールがある
60
podman is 何
Slide 61
Slide 61 text
Japan Container DAYS v 18.12 @makocchi 61
create
0.155 ms
0.083 ms
dockerd を経由することによるオーバーヘッドは？ (続き)
Docker client と同じように podman を使っ
てパフォーマンスを計測
podman は Docker client と比べると
start が若干パフォーマンスが良い
が、結局 ctr が強い
Docker client
ctr client
Start
0.632 ms
0.346 ms
STOP (KILL)
0.454 ms
0.114 ms
DELETE
0.070 ms
0.241 ms
podman
0.208 ms
0.470 ms
0.079 ms
0.265 ms
Slide 62
Slide 62 text
Japan Container DAYS v 18.12 @makocchi 62
コンテナ lifecycle total Docker client + runc 1.312 ms
ctr client + runc 0.786 ms
podman + runc 1.02 ms
dockerd を経由することによるオーバーヘッドは？ (続き)
create/start/stop/delete
ctr によるコンテナ操作が一番優秀
podman もそこそこ速い
Slide 63
Slide 63 text
Japan Container DAYS v 18.12 @makocchi 63
新興勢力 podman
RuntimeClass (alpha feature)
Containerd の安定感
いろいろな high/low level runtime (まとめ)
コンテナの操作が daemon 無しでできるので余計なプロセス
を立ち上げなくて良い点が良い
また、Docker コマンドをそのまま使えるのも Good!
RHEL 8 から標準で追加される
パフォーマンス、操作性共に問題なし
Docker 内部でずっと使われ続けているので安定感がある
最近は Docker の package も containerd が分離した状態
で作成されている (rpm/deb 等)
Kubernetes 1.12 から RuntmeClass という機能が実装されている (まだ alpha)
Feature gate で “RuntimeClass” を有効にして、CustomResourceDefinition を定義する
Pod 作成時に spec.runtimeClassName を指定して好みの runtime で Pod を起動させることができる
Slide 64
Slide 64 text
Japan Container DAYS v 18.12 @makocchi 64
おしらせ
今年もサイバーエージェントはブースを出しています。
おうち kubernetes が当たるかも？是非来て下さい。
まだ間に合うよ！
Container-SIG も Japan Container Daysに協賛しています。
登壇者随時募集しています。
Cloud Native 体験ができる！showKs ブースに是非来て下さい。
皆さんの参加を待っています！
Slide 65
Slide 65 text
Japan Container DAYS v 18.12 @makocchi 65
おしらせ
この後 16:40 から 2F reception にて TechMeeting があります
コンテナ runtime をテーマとしたディスカッション企画です
興味ある方は是非参加してください！
Slide 66
Slide 66 text
Japan Container DAYS v 18.12 @makocchi 66
runc だけじゃない
コンテナ low level runtime 徹底比較
Makoto Hasegawa | @makocchi
CyberAgent, Inc
ご清
聴
ありがとうございました！
！