コンテナランタイムはじめの一歩 / Container Runtime 101

by Kohei Ota

Slide 1

Slide 1 text

コンテナランタイムはじめの一歩 Container Runtime Meetup #2 Presented by @inductor

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

自己紹介名前: 太田航平 (@inductor) 所属: HPE (Hewlett Packard Enterprise) 役職: ソリューションアーキテクト (Cloud Native and DevOps) Docker MeetupとかCloud Native Daysの運営、謎のアンバサダー業好きなこと: 無限にスケールする(無限にスケールするとは言ってない)インフラ

Slide 4

Slide 4 text

コンテナの仕組み

Slide 5

Slide 5 text

コンテナの仕組み雑に言えばすごいchroot → 特定のディレクトリをルートディレクトリに見立てて仕切りを作る技術例: ホスト上の /var/docker/container1 をルートにしてそれ以下で別のOSが動くための環境を作るみたいなことができる隔離したファイルシステムに対してnamespaceで分離したユーザー、プロセス、NWなどを割り当て、cgroupsで利用できるリソース量を制限すると、まるでVMみたいなものをプロセスの単位で作れるみたいなやつ

Slide 6

Slide 6 text

コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d

Slide 7

Slide 7 text

コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d / / / / pivot_root pivot_root pivot_root pivot_root あるディレクトリをルートに見せかける pivot_root

Slide 8

Slide 8 text

コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d / / / / namespace namespace namespace namespace ユーザーIDやNW、プロセス空間などを分離する namespace root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24

Slide 9

Slide 9 text

コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d / / / / アプリケーションが動作するために必要なファイルたちを tar.gz形式でパッケージングしてこいつらの上にのっけて ... root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB nginx on Ubuntu Node on Alpine Ruby on CentOS Debian

Slide 10

Slide 10 text

/var /tmp コンテナの仕組み / /home /var/a /var/b /var/c /tmp/d / / / / 展開したファイルシステムの実行ファイルをプロセスとして起動！ 1CPU 2GB 1CPU 2GB 1CPU 2GB 2CPU 4GB nginx on Ubuntu Node on Alpine Ruby on CentOS Debian root 10.0.0.1/24 root 10.0.0.2/24 root 10.0.0.3/24 root 10.0.0.3/24 プロセス起動！

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

コンテナランタイムは何してる？

Slide 14

Slide 14 text

一連の作業を全部やってくれる

Slide 15

Slide 15 text

コンテナランタイムの役割 ● 高レベルランタイム(containerd, CRI-Oなど) ○ CRI(gRPC over Unix socket)でKubernetes/Dockerと会話するプロセス(Daemonとして常駐) ○ コンテナイメージの管理 ○ 低レベルランタイムのバイナリを実行してコンテナを生成させる ● 低レベルランタイム(runC, runsc(gVisor), runnc(Nabla)など) ○ Daemonではなくバイナリで、高レベルランタイムによって実行される ○ OCI Specのconﬁg.jsonを高レベルランタイムから受け取ってコンテナを生成 ○ Linux namespaceやcgroupの命令を実際に行う

Slide 16

Slide 16 text

コンテナランタイムの役割(Docker) dockerd docker pull docker run REST API containerd gRPC runC OCI(containerd内でJSON のコンフィグを渡しながらバイナリを直接実行) OCI High level runtime Low level runtime

Slide 17

Slide 17 text

コンテナランタイムの役割(Kubernetes) Kubernetes kubectl run kubectl apply REST API containerd CRI (gRPC) kube-api-serverとかetcdとか kubeletとかいろいろ含む ※CRIは各ノード上のkubeletが喋る runC OCI(containerd内でJSON のコンフィグを渡しながらバイナリを直接実行) OCI High level runtime Low level runtime

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Appendix: CRIとOCI Spec ● CRI ○ CNCF(というかKubernetes)が標準化したランタイム規格 ○ Kubernetesと低レベルランタイムが通信するための API仕様(gRPCによるスキーマ定義 ) ○ CRIはOCI SpecのJSONを生成して低レベルランタイムにコンテナの作成等を依頼する ● OCI ○ OCI(Open Container Initiative)が標準化したコンテナの規格 ○ CRIから受け取ったJSON Specでコンテナを生成(Linuxカーネルのシステムコールの実行含 ) ○ runCなどの持つ機能を標準化 (OCI Runtime Spec) ○ コンテナイメージ仕様の標準化 (OCI Image Spec)

Slide 20

Slide 20 text

Dockerが使う低レベルランタイム runCの仕組み

Slide 21

Slide 21 text

runCの仕組みホストマシン Linuxカーネルコンテナコンテナコンテナ runC Docker & CRI ファイルシステムの展開プロセスの初期化イメージの管理

Slide 22

Slide 22 text

runCの仕組みホストOS、カーネルはマシンごとに共通 DockerまたはCRIから受けた命令をもとにカーネルに命令を送ってコンテナの実態であるリソースの隔離を行い、アプリケーションを実行する普通にやるとホストOSの特権が必要 → runCの脆弱性が見つかる＝とても危ない

Slide 23

Slide 23 text

runCとは違うアプローチで同じことが実現できないか

Slide 24

Slide 24 text

AWSが作ったFirecrackerと Googleが作ったgVisorの仕組み

Slide 25

Slide 25 text

microVMベースのFirecracker

Slide 26

Slide 26 text

microVMとは軽量かつ起動が高速で、動的に生成削除されるVMのこと → マイクロ仮想化(Micro-Virtualization)技術で使われるVM Amazonが作っているFirecrackerはmicroVMの思想で作られたOSS → Rust製で125ms程度の速さで起動するのが特徴

Slide 27

Slide 27 text

microVMの仕組みホストOS microVM microVM microVM Firecracker CLI or REST Client ゲストOS ゲストOS ゲストOS ホストカーネルを利用して KVMベースのマシンを起動

Slide 28

Slide 28 text

コンテナでの利用例 Firecracker-containerd と組み合わせる → Firecracker上のrunCとcontainerdを組み合わせて動かすためのOSS 軽量なVM + Dockerよりも軽量なcontainerdの組み合わせによって Dockerイメージを動かすことができる Fargateと呼ばれるAWSの仮想化技術もこれに準拠したものが使われている Ref. https://aws.amazon.com/jp/blogs/news/under-the-hood-fargate-data-plane/

Slide 29

Slide 29 text

コンテナでの利用例ホストOS microVM microVM microVM Firecracker + runC + containerd CLI or REST Client ゲストOS ゲストOS ゲストOS コンテナコンテナコンテナホストカーネルを利用して KVMベースのマシンを起動

Slide 30

Slide 30 text

microVMのメリット・デメリット既存のVM技術と比べリソースの割当が柔軟で動的 → REST APIでVMの操作が可能、起動が高速なのでスケールも速い VMであることに変わりはないのでホスト環境との隔離性が高い VMレイヤの起動オーバーヘッドなどが無視できない要件の環境だと厳しい

Slide 31

Slide 31 text

「サンドボックス」のgVisor

Slide 32

Slide 32 text

gVisorとは Googleが作ったコンテナランタイム ptrace/KVM版があるが、今回はptraceに関してだけ紹介 Linux上でgVisorを動かすと、「ゲストカーネル」が展開されるコンテナでシステムコールが呼ばれると、ptraceでそれをフックし、seccompで呼び出せるシステムコールをフィルタして、gVisorがフックしたシステムコールを置換して代理実行する(気になる人はSentryプロセスについて調べよう)

Slide 33

Slide 33 text

gVisorの仕組みホストOS コンテナコンテナコンテナ gVisorのゲストカーネル

Slide 34

Slide 34 text

コンテナにカーネルのふりをする Linux上のプロセスがgVisor

Slide 35

Slide 35 text

他にはないの？

Slide 36

Slide 36 text

（時間があれば）Unikernelの紹介

Slide 37

Slide 37 text

Unikernelとは Library OSを用いて特定のアプリケーションに必要なコンポーネントだけを内包した空間を分離する技術 → カーネルで使わない機能すら排除して、余計なものを入れないという考え方 Library OS、それすなわち、OSがライブラリとして機能する(必要なものだけを入れたものになる)という本当に最低限の動作環境なのでセキュア・軽量・高速

Slide 38

Slide 38 text

コンテナでの利用例 IBMが作っているNabla ContainersプロジェクトではUnikernelを採用低レベルコンテナランタイムとしてRunncを使う → Seccompで使えるシステムコールを制限 → Library OSを使って必要なコンポーネントのみを入れる Unikernelの特性上通常のDockerイメージが使えない → ランタイムが使うunikernelのバイナリをイメージに組み込む必要があるためここからはRunnc(Nabla Containers)前提で話を進めます

Slide 39

Slide 39 text

Unikernelの仕組みホストOS Runnc ホスト上のnabla run tender が専用にコンパイルされたアプリのバイナリを読み出して実行

Slide 40

Slide 40 text

Unikernelのメリット・デメリット VMと違い環境の分離までは行わずにプロセスとしてコンテナが動くので軽量かつ高速不要なカーネルの機能は含まれないため、ホストとの接地点が少ない Unikernelの技術自体の知名度が低く、知見があまりない + Runncというものを導入するハードルの高さイメージのビルド環境が特殊でフォーマットの互換性もない

Slide 41

Slide 41 text

Appendix: gVisorとの違い gVisor(Runsc)はユーザー領域にカーネルを再実装したものを展開し、あたかもそれがシステム領域であるかのように動作する仕組み Unikernelと違ってDockerベースのイメージが動き、Containerdも動作するが、その下にいるgVisorがLinuxカーネルのフリをして動くことによってホストとの環境を分離している

Slide 42

Slide 42 text

まとめ Dockerで使われるrunCには特権を渡す必要がありコンテナ間の隔離性が低いなどの問題がある → 安全で高速な代替のランタイム開発のきっかけになった MicroVMでは隔離性は高いが起動時の遅延がシビアになりやすい gVisorではLinuxカーネルとの互換性が重要な場合の動作保証が難しい Unikernelでは高いパフォーマンスと隔離性の代わりに汎用性が低くなりやすい要件に合わせていろいろなスタックを組み合わせて使うことで様々な問題を解決するアプローチが現在進行系で（アカデミックな場でも）提案されている

Slide 43

Slide 43 text

参考資料 KubeCon 報告：コンテナランタイムやFirecrackerの話題ひととおり振り返ってみよう by 徳永航平さん https://www.slideshare.net/KoheiTokunaga/kubecon-firecracker makocchiさんのスライドいろいろ https://speakerdeck.com/makocchi/ A Linux in Unikernel Clothing @ EuroSys '20 Firecracker: Lightweight Virtualization for Serverless Applications

Slide 44

Slide 44 text

では、ここからのセッションをお楽しみください！