Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

makocchi
December 05, 2018
4.9k

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

Japan Container Days v18.12 の発表資料です
「runc だけじゃないコンテナ low level runtime 徹底比較」

合わせて読みたい
「Docker だけじゃないコンテナ runtime 徹底比較」
https://speakerdeck.com/makocchi/about-container-runtimes-japan-container-days-v18-dot-04

makocchi

December 05, 2018
Tweet

More Decks by makocchi

Transcript

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

    View full-size slide

  2. Japan Container DAYS v 18.12 @makocchi 2
    本日の資料は後ほど公開します
    頑張って写真撮らなくても大丈夫!

    View full-size slide

  3. 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

    View full-size slide

  4. Japan Container DAYS v 18.12 @makocchi 4
    本題に入る前に・・・

    View full-size slide

  5. Japan Container DAYS v 18.12 @makocchi 5
    前回 (V18.04) のおさらい
    「Dockerだけじゃないコンテナ runtime 徹底比較」

    View full-size slide

  6. 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 徹底比較」

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. Japan Container DAYS v 18.12 @makocchi 9
    AGENDA
    前回のおさらい
    いろいろな low level runtime
    low level runtime の動かし方
    ベンチマークツールの紹介
    ベンチマーク結果
    まとめ
    おまけ

    View full-size slide

  10. Japan Container DAYS v 18.12 @makocchi 10
    いろいろな low level runtime
    定番からマニアックなものまで

    View full-size slide

  11. 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 をベースにしている

    View full-size slide

  12. 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

    View full-size slide

  13. 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 をイン
    ターセプトして代わりに実行する

    View full-size slide

  14. 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 をイン
    ターセプトして代わりに実行する
    ふかぼる!

    View full-size slide

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

    View full-size slide

  16. 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

    View full-size slide

  17. Japan Container DAYS v 18.12 @makocchi 17
    Nabla containers とは・・・・?
    でもそんな事しなくても簡単に image 作れるように
    demo を用意しているよ!

    View full-size slide

  18. 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

    View full-size slide

  19. 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

    View full-size slide

  20. 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 をイン
    ターセプトして代わりに実行する
    ふかぼる!
    ふかぼった!

    View full-size slide

  21. 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)

    View full-size slide

  22. 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

    View full-size slide

  23. 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

    View full-size slide

  24. Japan Container DAYS v 18.12 @makocchi 24
    gVisor とは・・・・?
    dmesg の実装のところはここを見て下さい
    よく見ると遊び心が満載
    https://github.com/google/gvisor/blob/master/
    pkg/sentry/kernel/syslog.go#L49-L76

    View full-size slide

  25. 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

    View full-size slide

  26. Japan Container DAYS v 18.12 @makocchi 26
    隔離性が高い
    隔離性が低い
    導入が容易
    導入が複雑
    runc
    kata-runtime
    runq
    runsc
    railcar
    runnc
    ※あくまで主観

    View full-size slide

  27. Japan Container DAYS v 18.12 @makocchi 27
    いったい我々はどの low level runtime を使えばいいのだろうか?
    runXX

    View full-size slide

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

    View full-size slide

  29. Japan Container DAYS v 18.12 @makocchi 29
    runtime B
    0.21 ms
    runtime A
    0.16 ms
    やっぱり気になってくるのが性能ですよね

    View full-size slide

  30. Japan Container DAYS v 18.12 @makocchi 30
    low level runtime の動かし方
    Docker や containerd に頼らなくても
    コンテナを動かすことができるようになろう
    性能の話の前に・・・

    View full-size slide

  31. 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

    View full-size slide

  32. 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 の作成

    View full-size slide

  33. 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" # <- ௥Ճ
    ],
    ---

    View full-size slide

  34. 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 | コンテナの作成

    View full-size slide

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

    View full-size slide

  36. 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 | コンテナの起動

    View full-size slide

  37. 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 | コンテナの停止

    View full-size slide

  38. 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


    View full-size slide

  39. Japan Container DAYS v 18.12 @makocchi 39
    ベンチマークツールの紹介
    ベンチマークツールはどんなものがあるのだろうか

    View full-size slide

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

    View full-size slide

  41. Japan Container DAYS v 18.12 @makocchi 41
    cri-tools (critest)
    CRI の interface を通じて benchmark をすること
    ができる
    コンテナの lifecycle だけではなくて pod/imgae の
    操作にも対応している
    ベンチマークツールの紹介
    https://github.com/kubernetes-sigs/cri-tools

    View full-size slide

  42. 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)
    柔軟に使うのが大変だった

    View full-size slide

  43. Japan Container DAYS v 18.12 @makocchi 43
    ベンチマーク結果
    お待たせしました

    View full-size slide

  44. 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

    View full-size slide

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

    View full-size slide

  46. 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) は若干起動が早い
    結果となった

    View full-size slide

  47. 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 が他に比べて少し
    優位な結果となった

    View full-size slide

  48. 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 命令だけ受け付けて、後で非同期で消
    しているのかもしれない

    View full-size slide

  49. 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 が優位な結果となった

    View full-size slide

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

    View full-size slide

  51. Japan Container DAYS v 18.12 @makocchi 51
    まとめ
    あなたに合う runtime は見つかりましたか?

    View full-size slide

  52. 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 にする必要があるかもしれない

    View full-size slide

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

    View full-size slide

  54. Japan Container DAYS v 18.12 @makocchi 54
    One more thing ..

    View full-size slide

  55. Japan Container DAYS v 18.12 @makocchi 55
    Docker だけじゃない
    コンテナ high level runtime ちょっと比較
    Makoto Hasegawa | @makocchi
    CyberAgent, Inc
    - extended -

    View full-size slide

  56. 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

    View full-size slide

  57. 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
    ショートカット!

    View full-size slide

  58. 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

    View full-size slide

  59. Japan Container DAYS v 18.12 @makocchi 59
    https://podman.io/

    View full-size slide

  60. 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 full-size slide

  61. 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

    View full-size slide

  62. 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 もそこそこ速い

    View full-size slide

  63. 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 を起動させることができる

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    ありがとうございました!

    View full-size slide