Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

今話題のいろいろなコンテナランタイムを比較してみた

5,507 views

Published on

Docker Meetup Tokyo #26での発表資料です。
いろいろなコンテナランタイムについて、機能、セキュリティ、パフォーマンス、開発動向に着目して比較調査および性能測定を行ないました。

unikernelベースのイメージの作り方などの技術的な話題は付録にも記載しましたが、近々、別の形でもまとめようと考えています。

[留意]
本資料中の性能測定は、コンテナランタイムのCRI命令処理(Podやコンテナの作成から削除までの各ステップのCRI命令)の性能を測定したものです。
それらCRI命令への処理はあくまでもコンテナランタイムが行うことのごく一部に過ぎず、それ単体ではコンテナランタイムそのものの性能を決定し得えないことに留意ください。

Published in: Software
  • Be the first to comment

今話題のいろいろなコンテナランタイムを比較してみた

  1. 1. Copyright©2018 NTT corp. All Rights Reserved. 今話題のいろいろな コンテナランタイムを比較してみた 2018/11/21 日本電信電話株式会社 ソフトウェアイノベーションセンタ 徳永 航平 Docker Meetup Tokyo #26
  2. 2. 2Copyright©2018 NTT corp. All Rights Reserved. 自己紹介 名前 徳永 航平 所属 NTT ソフトウェアイノベーションセンタ 年次 1年目 興味 コンテナ仮想化技術 特に、コンテナランタイム領域 勉強中
  3. 3. 3Copyright©2018 NTT corp. All Rights Reserved. ランタイム毎に異なる特徴 群雄割拠なコンテナランタイム領域 Pod Containers セキュリティ 機能 パフォーマンス kubelet 開発動向
  4. 4. 4Copyright©2018 NTT corp. All Rights Reserved. 本資料における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/]
  5. 5. 5Copyright©2018 NTT corp. All Rights Reserved. 今回比較する項目 Pod 低レイヤランタイム (OCIランタイム) 実行 kubelet CRI socket 高レイヤランタイム Containers 低レイヤランタイム パフォーマンス 開発動向機能 セキュリティ パフォーマンス 開発動向 高レイヤランタイム 各ランタイムの 機能を定性比較 それぞれの隔離 手法を定性比較 基本操作を計測 し定量比較 githubのコミッ ト数推移を比較 githubのコミッ ト数推移を比較 基本操作を計測 し定量比較
  6. 6. 6Copyright©2018 NTT corp. All Rights Reserved. 測定ツール スペック 測定項目 測定用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 低レイヤランタイム (OCIランタイム) 実行 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]
  7. 7. 7Copyright©2018 NTT corp. All Rights Reserved. 目次 Pod Containers 低レイヤランタイム (OCIランタイム) 実行 kubelet CRI socket 高レイヤランタイム 1. 高レイヤランタイムの比較 2. 低レイヤランタイムの比較 3. まとめ
  8. 8. 8Copyright©2018 NTT corp. All Rights Reserved. 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 設定 コンテナ 生成 直近約1年のコミット数推移 [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取得
  9. 9. 9Copyright©2018 NTT corp. All Rights Reserved. 直近約1年のコミット数推移 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取得
  10. 10. 10Copyright©2018 NTT corp. All Rights Reserved. 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] 直近約1年のコミット数推移  CNCFプロジェクト。CoreOS主導で開発が開始。  Pod指向、低レイヤランタイム機能を内包。  rkt自身はCRIを見張るデーモンではなく、rktlet がその役割を担う。rktはsystemd経由で起動。 [https://github.com/rkt/rkt/graphs/commit-activity] 2018.11.21取得
  11. 11. 11Copyright©2018 NTT corp. All Rights Reserved. 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
  12. 12. 12Copyright©2018 NTT corp. All Rights Reserved. 高レイヤランタイム(+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 秒
  13. 13. 13Copyright©2018 NTT corp. All Rights Reserved. CRI plugin 高レイヤランタイムのまとめ Pod OCI shim CNI pause Containers conmon conmon Pod infra CNI OCI conmon conmonContainers Pod apps stage1 systemd  Moby,CNCFプロジェ クトとして開発が盛ん。  イメージのpushやGo APIなど多機能である。  パフォーマンスは概ね 高いが、Pod・コンテ ナの起動および停止に 時 間 が か か る 。  k8s SIG主導で、開発 は比較的盛んである。  CRI実装に必要な必要 最低限の機能を持つ。  パフォーマンスは概ね 高いが、Podの起動停 止、コンテナの作成停 止 に 時 間 が かか る 。  開発は最近あまり盛ん ではなくなりつつある。  stage1-imageに応 じてnamespaceやVM など様々な隔離手法を 選択することができる。  CRI経由では全体的に 低 パ フ ォ ー マン ス 。 Pod生成用 イメージ
  14. 14. 14Copyright©2018 NTT corp. All Rights Reserved. 目次 Pod Containers 低レイヤランタイム (OCIランタイム) 実行 kubelet CRI socket 高レイヤランタイム 1. 高レイヤランタイムの比較 2. 低レイヤランタイムの比較 3. まとめ
  15. 15. 15Copyright©2018 NTT corp. All Rights Reserved. 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 直近約1年のコミット数推移 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取得
  16. 16. 16Copyright©2018 NTT corp. All Rights Reserved. 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] 直近約1年のコミット数推移 2018.11.21取得 [https://github.com/google/gvisor/graphs/commit-activity]
  17. 17. 17Copyright©2018 NTT corp. All Rights Reserved. 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] 直近約1年のコミット数推移 2018.11.21取得 [https://github.com/nabla-containers/runnc/graphs/commit-activity]
  18. 18. 18Copyright©2018 NTT corp. All Rights Reserved. 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] 直近約1年のコミット数推移 2018.11.21取得 [https://github.com/kata-containers/runtime/graphs/commit-activity]
  19. 19. 19Copyright©2018 NTT corp. All Rights Reserved. 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が起動する + + +
  20. 20. 20Copyright©2018 NTT corp. All Rights Reserved. コンテナのパフォーマンス比較 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) +
  21. 21. 21Copyright©2018 NTT corp. All Rights Reserved. パフォーマンス総合ランキング 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)
  22. 22. 22Copyright©2018 NTT corp. All Rights Reserved. 低レイヤランタイムのまとめ 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
  23. 23. 23Copyright©2018 NTT corp. All Rights Reserved. 目次 Pod Containers 低レイヤランタイム (OCIランタイム) 実行 kubelet CRI socket 高レイヤランタイム 1. 高レイヤランタイムの比較 2. 低レイヤランタイムの比較 3. まとめ
  24. 24. 24Copyright©2018 NTT corp. All Rights Reserved. 紹介したコンテナランタイムの一覧 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 conmon conmonContainers runc kata- runtimerunsc runnc 低レイヤランタイム 高レイヤランタイム CRI
  25. 25. 25Copyright©2018 NTT corp. All Rights Reserved. 付録1:使用ツールの一覧と留意点  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
  26. 26. 26Copyright©2018 NTT corp. All Rights Reserved. 付録2:性能測定用イメージの作成手順 #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"] 本測定では、リスト1に示すプログラムのみを実行するscratchイメージを使用しました。 リスト1:loop.c リスト2:通常のイメージ生成用Dockerfile リスト3:runncイメージ生成用Dockerfile runnc以外のランタイムに使用するイメージとして、リスト1のプログラムを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)でリスト1をコンパイルしました。 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

×