Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コンテナランタイムはじめの一歩 / Container Runtime 101
Search
Kohei Ota
August 22, 2020
Technology
9
4.1k
コンテナランタイムはじめの一歩 / Container Runtime 101
Kohei Ota
August 22, 2020
Tweet
Share
More Decks by Kohei Ota
See All by Kohei Ota
CloudNative Meets WebAssembly: Exploring Wasm's Potential to Replace Containers
inductor
3
1.3k
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
91
Cracking the KubeCon CfP
inductor
3
410
KubeCon Recap -Platform migration at Scale-
inductor
1
930
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
430
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
26
6k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
740
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.2k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
19
5.9k
Other Decks in Technology
See All in Technology
IaC運用を楽にするためにCDK Pipelinesを導入したけど、思い通りにいかなかった話
smt7174
1
110
CI/CDやテスト自動化の開発プロジェクトへの適用
megascus
3
740
最速最小からはじめるデータプロダクト / Data Product MVP
amaotone
5
720
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
3.6k
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
15
3.9k
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
端末が簡単にリモートから操作されるデモを通じて ソフトウェアサプライチェーン攻撃対策の重要性を理解しよう
kitaji0306
0
170
急成長中のWINTICKETにおける品質と開発スピードと向き合ったQA戦略と今後の展望 / winticket-autify
cyberagentdevelopers
PRO
1
160
Aurora_BlueGreenDeploymentsやってみた
tsukasa_ishimaru
1
120
新R25、乃木坂46 Mobileなどのファンビジネスを支えるマルチテナンシーなプラットフォームの全体像 / cam-multi-cloud
cyberagentdevelopers
PRO
1
130
AWS re:Inventを徹底的に楽しむためのTips / Tips for thoroughly enjoying AWS re:Invent
yuj1osm
1
540
新卒1年目が向き合う生成AI事業の開発を加速させる技術選定 / ai-web-launcher
cyberagentdevelopers
PRO
7
1.5k
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
222
8.9k
It's Worth the Effort
3n
183
27k
A Tale of Four Properties
chriscoyier
156
23k
Designing Experiences People Love
moore
138
23k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Facilitating Awesome Meetings
lara
49
6k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
39
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.1k
Music & Morning Musume
bryan
46
6.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
680
Being A Developer After 40
akosma
86
590k
Transcript
コンテナランタイム はじめの一歩 Container Runtime Meetup #2 Presented by @inductor
自己紹介
自己紹介 名前: 太田 航平 (@inductor) 所属: HPE (Hewlett Packard Enterprise)
役職: ソリューションアーキテクト (Cloud Native and DevOps) Docker MeetupとかCloud Native Daysの運営、謎のアンバサダー業 好きなこと: 無限にスケールする(無限にスケールするとは言ってない)インフラ
コンテナの仕組み
コンテナの仕組み 雑に言えばすごいchroot → 特定のディレクトリをルートディレクトリに見立てて仕切りを作る技術 例: ホスト上の /var/docker/container1 をルートにしてそれ以下で別のOSが動くため の環境を作るみたいなことができる 隔離したファイルシステムに対してnamespaceで分離したユーザー、プロセス、NWな
どを割り当て、cgroupsで利用できるリソース量を制限すると、まるでVMみたいなもの をプロセスの単位で作れるみたいなやつ
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d
コンテナの仕組み / /home /var /tmp /var/a /var/b /var/c /tmp/d /
/ / / pivot_root pivot_root pivot_root pivot_root あるディレクトリをルートに見せかける pivot_root
コンテナの仕組み / /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
コンテナの仕組み / /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
/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 プロセス起動!
/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 プロセス起動! これ1つ1つがコンテナ
/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 プロセス起動! これ1つ1つがコンテナ これがコンテナイメージね
コンテナランタイムは何してる?
一連の作業を全部やってくれる
コンテナランタイムの役割 • 高レベルランタイム(containerd, CRI-Oなど) ◦ CRI(gRPC over Unix socket)でKubernetes/Dockerと会話するプロセス(Daemonとして常駐) ◦
コンテナイメージの管理 ◦ 低レベルランタイムのバイナリを実行してコンテナを生成させる • 低レベルランタイム(runC, runsc(gVisor), runnc(Nabla)など) ◦ Daemonではなくバイナリで、高レベルランタイムによって実行される ◦ OCI Specのconfig.jsonを高レベルランタイムから受け取ってコンテナを生成 ◦ Linux namespaceやcgroupの命令を実際に行う
コンテナランタイムの役割(Docker) dockerd docker pull docker run REST API containerd gRPC
runC OCI(containerd内でJSON のコンフィグを渡しながらバ イナリを直接実行) OCI High level runtime Low level runtime
コンテナランタイムの役割(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
コンテナランタイムの役割(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
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)
Dockerが使う低レベルランタイム runCの仕組み
runCの仕組み ホストマシン Linuxカーネル コンテナ コンテナ コンテナ runC Docker & CRI
ファイルシステムの展開 プロセスの初期化 イメージの管理
runCの仕組み ホストOS、カーネルはマシンごとに共通 DockerまたはCRIから受けた命令をもとにカーネルに命令を送ってコンテナの実態で あるリソースの隔離を行い、アプリケーションを実行する 普通にやるとホストOSの特権が必要 → runCの脆弱性が見つかる=とても危ない
runCとは違うアプローチで 同じことが実現できないか
AWSが作ったFirecrackerと Googleが作ったgVisorの仕組み
microVMベースのFirecracker
microVMとは 軽量かつ起動が高速で、動的に生成削除されるVMのこと → マイクロ仮想化(Micro-Virtualization)技術で使われるVM Amazonが作っているFirecrackerはmicroVMの思想で作られたOSS → Rust製で125ms程度の速さで起動するのが特徴
microVMの仕組み ホストOS microVM microVM microVM Firecracker CLI or REST Client
ゲストOS ゲストOS ゲストOS ホストカーネルを利用して KVMベースのマシンを起動
コンテナでの利用例 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/
コンテナでの利用例 ホストOS microVM microVM microVM Firecracker + runC + containerd
CLI or REST Client ゲストOS ゲストOS ゲストOS コンテナ コンテナ コンテナ ホストカーネルを利用して KVMベースのマシンを起動
microVMのメリット・デメリット 既存のVM技術と比べリソースの割当が柔軟で動的 → REST APIでVMの操作が可能、起動が高速なのでスケールも速い VMであることに変わりはないのでホスト環境との隔離性が高い VMレイヤの起動オーバーヘッドなどが無視できない要件の環境だと厳しい
「サンドボックス」のgVisor
gVisorとは Googleが作ったコンテナランタイム ptrace/KVM版があるが、今回はptraceに関してだけ紹介 Linux上でgVisorを動かすと、「ゲストカーネル」が展開される コンテナでシステムコールが呼ばれると、ptraceでそれをフックし、seccompで呼び出 せるシステムコールをフィルタして、gVisorがフックしたシステムコールを置換して代理 実行する(気になる人はSentryプロセスについて調べよう)
gVisorの仕組み ホストOS コンテナ コンテナ コンテナ gVisorのゲストカーネル
コンテナにカーネルのふりをする Linux上のプロセスがgVisor
他にはないの?
(時間があれば)Unikernelの紹介
Unikernelとは Library OSを用いて特定のアプリケーションに必要なコンポーネントだけを内包した空 間を分離する技術 → カーネルで使わない機能すら排除して、余計なものを入れないという考え方 Library OS、それすなわち、OSがライブラリとして機能する(必要なものだけを入れたも のになる)という本当に最低限の動作環境なのでセキュア・軽量・高速
コンテナでの利用例 IBMが作っているNabla ContainersプロジェクトではUnikernelを採用 低レベルコンテナランタイムとしてRunncを使う → Seccompで使えるシステムコールを制限 → Library OSを使って必要なコンポーネントのみを入れる Unikernelの特性上通常のDockerイメージが使えない
→ ランタイムが使うunikernelのバイナリをイメージに組み込む必要があるため ここからはRunnc(Nabla Containers)前提で話を進めます
Unikernelの仕組み ホストOS Runnc ホスト上のnabla run tender が専用にコンパイルされたア プリのバイナリを読み出して 実行
Unikernelのメリット・デメリット VMと違い環境の分離までは行わずにプロセスとしてコンテナが動くので軽量かつ高 速 不要なカーネルの機能は含まれないため、ホストとの接地点が少ない Unikernelの技術自体の知名度が低く、知見があまりない + Runncというものを導入するハードルの高さ イメージのビルド環境が特殊でフォーマットの互換性もない
Appendix: gVisorとの違い gVisor(Runsc)はユーザー領域にカーネルを再実装したものを展開し、 あたかもそれがシステム領域であるかのように動作する仕組み Unikernelと違ってDockerベースのイメージが動き、Containerdも動作するが、その 下にいるgVisorがLinuxカーネルのフリをして動くことによってホストとの環境を分離 している
まとめ Dockerで使われるrunCには特権を渡す必要がありコンテナ間の隔離性が低いなど の問題がある → 安全で高速な代替のランタイム開発のきっかけになった MicroVMでは隔離性は高いが起動時の遅延がシビアになりやすい gVisorではLinuxカーネルとの互換性が重要な場合の動作保証が難しい Unikernelでは高いパフォーマンスと隔離性の代わりに汎用性が低くなりやすい 要件に合わせていろいろなスタックを組み合わせて使うことで様々な問題を解決する アプローチが現在進行系で(アカデミックな場でも)提案されている
参考資料 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
では、ここからのセッションを お楽しみください!