runc だけじゃないコンテナ low level runtime 徹底比較

Japan Container DAYS v 18.12 @makocchi 1
runc だけじゃない
コンテナ low level runtime 徹底比較
Makoto Hasegawa | @makocchi
CyberAgent, Inc

View Slide

本日の資料は後ほど公開します
頑張って写真撮らなくても大丈夫！

View Slide

サイバーエージェントアドテク本部所属
普段はデータセンター運用や 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

View Slide

本題に入る前に・・・

View Slide

前回 (V18.04) のおさらい
「Dockerだけじゃないコンテナ runtime 徹底比較」

View Slide

https://www.youtube.com/watch?v=8jbJgI7Q6IU
前回のおさらい
コンテナ runtime は 2 つに分けて考えることが
できる (上位/下位 or High/Low etc)
OCI や CRI などのコンテナの規格が統一されて
きている
上位コンテナ runtime は Docker 以外にも
containerd や cri-o があり、自由に入れ替
えることができる
「Docker だけじゃないコンテナ runtime 徹底比較」

View Slide

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 の標準化の仕様を策定した

View Slide

前回のお話では上位コンテナ runtime に焦点を当てて構造の違いやパフォーマンスの測定を行いました。
今日のお話は下位のコンテナ runtime に焦点を当ててお話をします。

View Slide

AGENDA
前回のおさらい
いろいろな low level runtime
low level runtime の動かし方
ベンチマークツールの紹介
ベンチマーク結果
まとめ
おまけ

View Slide

定番からマニアックなものまで

View Slide

Hyper
runv
Clear Containers
cc-runtime
Docker 社が開発した
libcontainer に基づく cli
後に OCI の管理となり Docker の手
を離れた
現在でも Docker の default は
runc が使われている
Docker’s default
runc
Hyper によって開発されたコンテナの
ように vm を起動させる cli
OCI に準拠
hyperkernel を使用することで
host kernel とは隔離性を担保して
いる
コンテナ向けに開発された Clear
Linux を使用
Intel VT をベースにしている

View Slide

ݩ 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

View Slide

Nabla containers
runnc
いろいろな low level runtime (まだまだあるよ)
IBM Research によって開発されたセ
キュリティに重点を置いた runtime
Solo5 の unikernel を拡張している
ホスト側への system call が通常よ
りもかなり減っている
gVisor
runsc
Google が OSS として公開した
runtime
コンテナを sandbox 環境で実行しセ
キュリティを担保
ユーザー空間で可動する Sentry がコ
ンテナアプリケーションの syscall をイン
ターセプトして代わりに実行する

View Slide

Nabla containers
runnc
gVisor
runsc
runtime
ふかぼる！

View Slide

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 したもの

View Slide

https://nabla-containers.github.io/
つまり unikernel で compile したアプリケーションじゃないと動かない
その為、通常の docker image は利用不可
unikernel でアプリケーションを作成するのはとても手間がかかる・・・めんどくさい
作成手順は「Tutorial: Building Rumprun Unikernels」が参考になります
https://github.com/rumpkernel/wiki/wiki/Tutorial:-Building-Rumprun-Unikernels

View Slide

でもそんな事しなくても簡単に image 作れるように
demo を用意しているよ！

View Slide

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-base-build
nabla-xxx-base の Dockerfile がある
https://github.com/nabla-containers/nabla-base-build

View Slide

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

View Slide

Nabla containers
runnc
gVisor
runsc
runtime
ふかぼる！
ふかぼった！

View Slide

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)

View Slide

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

View Slide

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

View Slide

dmesg の実装のところはここを見て下さい
よく見ると遊び心が満載
https://github.com/google/gvisor/blob/master/
pkg/sentry/kernel/syslog.go#L49-L76

View Slide

rkt
OCI ではなく appc という spec で可動する runtime
CoreOS によって開発されていた
現在は OCI に準拠するように開発が進んでいる
いろいろな low level runtime (番外編)
lxc
アプリケーションコンテナとは違い、システムコンテナとも言われる
Alibaba では OCI 準拠の runlxc というものを開発している(ぽい)
上位 runtime としては lxd が相当する
CRI 経由で lxc を起動する lxe なんていうのもある (※)
(※) https://github.com/automaticserver/lxe

View Slide

隔離性が高い
隔離性が低い
導入が容易
導入が複雑
runc
kata-runtime
runq
runsc
railcar
runnc
※あくまで主観

View Slide

いったい我々はどの low level runtime を使えばいいのだろうか？
runXX

View Slide

セキュリティに気を付けなければならない環境であれ
ば隔離性の高い runtime が必要になってくる
性能にシビアな環境であればコンテナの lifecycle
の性能がいいものを選択すべき
もちろん複数の runtime を混在させてもいい
求められる要件をしっかりと把握することが大切
様々な要件によって使うべき runtime は
変わってくる導入のしやすさは？
セキュリティ要件は？
性能要件は？
いろいろな low level runtime (考察)
← ? →
← ? →
← ? →

View Slide

runtime B
0.21 ms
runtime A
0.16 ms
やっぱり気になってくるのが性能ですよね

View Slide

Docker や containerd に頼らなくても
コンテナを動かすことができるようになろう
性能の話の前に・・・

View Slide

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

View Slide

runc の設定は config.json で行う
runc spec で自動生成される
$ cd runc
# config.json Λ࡞੒
$ runc spec
$ ls
config.json rootfs
作成された config.json は default 値なので nginx 用に編集が必要
STEP 2 | config.json の作成

View Slide

編集箇所
---
"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" # ],
---

View Slide

コンテナを作成してみる
$ 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 | コンテナの作成

View Slide

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 は終了する

View Slide

create したコンテナを起動してみる
$ sudo runc start nginx_runc
$ sudo runc list
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 | コンテナの起動

View Slide

コンテナの停止は kill で行う
$ sudo runc kill nginx_runc
$ sudo runc list
nginx_runc 0 stopped /home/jkd/work/runc 2018-11-29T01:27:32.714914111Z root
$ sudo runc delete nginx_runc
お疲れ様でした！
STEP 5 | コンテナの停止

View Slide

low level runtime の動かし方 (rootless)
rootless で動かすこともできる
config.json に uidMappings や gidMappings の設定等が入る
その後は先程と同じような Operation が sudo 無しで可能
$ runc spec —rootless
$ runc create rootless_container
$ runc list
$ runc start rootless_container
…
…

View Slide

ベンチマークツールはどんなものがあるのだろうか

View Slide

bucketbench
Docker client や runc を使ったコンテナの
lifecycle のベンチマークが取れる
設定ファイルは yaml 形式
driver を拡張すればいろいろ対応可能
https://github.com/estesp/bucketbench

View Slide

cri-tools (critest)
CRI の interface を通じて benchmark をすること
ができる
コンテナの lifecycle だけではなくて pod/imgae の
操作にも対応している
https://github.com/kubernetes-sigs/cri-tools

View Slide

結局自作しちゃった
やっぱこれが一番
今回は low level runtime を動かす際に皆さんが
もっとも使うことになるであろう Docker の client で
の操作時間を runtime 別に計測
と言っても単なる shell script
今回コンテナの create と start で分けてベンチマーク
を取りたかったが、bucketbench は run しかサポート
していなかった
bucketbench は runc は対応しているが、runc にし
かないオプションを使うようになっていたり、全ての
runtime で統一して使うことが難しかった
critest は使用する image が busybox で固定
Iteration の回数も固定 (20)
timeout も固定 (2sec)
柔軟に使うのが大変だった

View Slide

ベンチマーク結果
お待たせしました

View Slide

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

View Slide

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 が早かったが誤差

View Slide

Docker START
runc
0.632
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
2.24 0.544 0.543 0.509 0.520
ms
0.359
kata-runtime の起動は他の runtime に比べ
て時間がかかる
runnc(nabla containers) は若干起動が早い
結果となった

View Slide

Docker STOP (KILL)
runc
0.454
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
0.594 0.588 0.442 0.447 0.521
ms
0.328
docker kill においても runnc が他に比べて少し
優位な結果となった

View Slide

Docker DELETE
runc
0.070
(ptrace)
runsc
(kvm)
ベンチマーク
runnc
0.070 0.069 0.070 0.070 0.069
ms
0.070
docker delete は横ばいで各種 runtime で差
がない結果となった
delete 命令だけ受け付けて、後で非同期で消
しているのかもしれない

View Slide

Docker create
runc
1.312
(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 が優位な結果となった

View Slide

いろいろな low level runtime (考察)
各 low level runtime での create や start の操作の performance はほぼ似通った結果となった
そもそもコンテナという軽量なアプリケーションを操作しているせいかもしれない
runnc (Nable containers) は全体的に操作の performance が良かった
隔離性もあるし、image が充実してくれば十分やっていけそう
Rust 製の railcar も他に遜色なく使える

View Slide

まとめ
あなたに合う runtime は見つかりましたか？

View Slide

特に何も考えてない人は
セキュリティを気にする人は
性能にこだわりたい人は
いろいろな 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 にする必要があるかもしれない

View Slide

CyberAgent, Inc

View Slide

One more thing ..

View Slide

Docker だけじゃない
コンテナ high level runtime ちょっと比較
CyberAgent, Inc
- extended -

View Slide

前回のおさらい再び
Docker client からの操作は dockerd を
経由して high level runtime の
containerd に渡り、最終的に low level
run time の runc 等が実行される
つまり containerd と直接お話してしまえば
オーバーヘッドは少なくなるはず (確信)
runc
containerd
dockerd
client

View Slide

今回のチャレンジ (ctr 編)
containerd は ctr という client から使う
ことができる
containerd 側で cri plugin が有効になっ
ていれば CRI で containerd と通信するこ
とができるようになり、その際には CRI 対応
のいろいろな client から使うことができる
(例えば kubelet)
runc
containerd
dockerd
ctr
client
ショートカット！

View Slide

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

View Slide

https://podman.io/

View Slide

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 何

View Slide

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

View Slide

コンテナ 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 もそこそこ速い

View Slide

新興勢力 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 を起動させることができる

View Slide

おしらせ
今年もサイバーエージェントはブースを出しています。
おうち kubernetes が当たるかも？是非来て下さい。
まだ間に合うよ！
Container-SIG も Japan Container Daysに協賛しています。
登壇者随時募集しています。
Cloud Native 体験ができる！showKs ブースに是非来て下さい。
皆さんの参加を待っています！

View Slide

おしらせ
この後 16:40 から 2F reception にて TechMeeting があります
コンテナ runtime をテーマとしたディスカッション企画です
興味ある方は是非参加してください！

View Slide

CyberAgent, Inc
ご清
聴
ありがとうございました！
！

View Slide

runc だけじゃないコンテナ low level runtime 徹底比較

runc だけじゃないコンテナ low level runtime 徹底比較

makocchi

More Decks by makocchi

Featured

Transcript