jkd 20181205 About low level runtimes

Transcript

1. Japan Container DAYS v 18.12 @makocchi 1 runc だけじゃない コンテナ

   low level runtime 徹底比較 Makoto Hasegawa | @makocchi CyberAgent, Inc

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

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

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

5. Japan Container DAYS v 18.12 @makocchi 5 前回 (V18.04) のおさらい

   「Dockerだけじゃないコンテナ runtime 徹底比較」

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

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

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

   今日のお話は下位のコンテナ runtime に焦点を当ててお話をします。

9. Japan Container DAYS v 18.12 @makocchi 9 AGENDA 前回のおさらい いろいろな

   low level runtime low level runtime の動かし方 ベンチマークツールの紹介 ベンチマーク結果 まとめ おまけ

10. Japan Container DAYS v 18.12 @makocchi 10 いろいろな low level

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

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

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

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

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

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

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

17. Japan Container DAYS v 18.12 @makocchi 17 Nabla containers とは・・・・？

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

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

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

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

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)

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

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

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

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

26. Japan Container DAYS v 18.12 @makocchi 26 隔離性が高い 隔離性が低い 導入が容易

    導入が複雑 runc kata-runtime runq runsc railcar runnc ※あくまで主観

27. Japan Container DAYS v 18.12 @makocchi 27 いったい我々はどの low level

    runtime を使えばいいのだろうか？ runXX

28. Japan Container DAYS v 18.12 @makocchi 28 セキュリティに気を付けなければならない環境であれ ば隔離性の高い runtime

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

29. Japan Container DAYS v 18.12 @makocchi 29 runtime B 0.21

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

30. Japan Container DAYS v 18.12 @makocchi 30 low level runtime

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

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

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

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

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

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

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

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

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 … …

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

40. Japan Container DAYS v 18.12 @makocchi 40 bucketbench Docker client

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

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

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

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

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

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

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

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

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

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

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 も他に遜色なく使える

51. Japan Container DAYS v 18.12 @makocchi 51 まとめ あなたに合う runtime

    は見つかりましたか？

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

53. Japan Container DAYS v 18.12 @makocchi 53 runc だけじゃない コンテナ

    low level runtime 徹底比較 Makoto Hasegawa | @makocchi CyberAgent, Inc

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

    ..

55. Japan Container DAYS v 18.12 @makocchi 55 Docker だけじゃない コンテナ

    high level runtime ちょっと比較 Makoto Hasegawa | @makocchi CyberAgent, Inc - extended -

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

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 ショートカット！

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

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

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 何

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

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

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

64. Japan Container DAYS v 18.12 @makocchi 64 おしらせ 今年もサイバーエージェントはブースを出しています。 おうち

    kubernetes が当たるかも？是非来て下さい。 まだ間に合うよ！ Container-SIG も Japan Container Daysに協賛しています。 登壇者随時募集しています。 Cloud Native 体験ができる！showKs ブースに是非来て下さい。 皆さんの参加を待っています！

65. Japan Container DAYS v 18.12 @makocchi 65 おしらせ この後 16:40

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

66. Japan Container DAYS v 18.12 @makocchi 66 runc だけじゃない コンテナ

    low level runtime 徹底比較 Makoto Hasegawa | @makocchi CyberAgent, Inc ご清 聴 ありがとうございました！ ！