Oracle Cloud Hangout Cafe - コンテナ・ランタイムの未来

Oracle Cloud Hangout Cafe（おちゃかふぇ）のセッションスライドです。
#ochacafe

(セッションの録画)
https://youtu.be/fqvs8jEDLWE

(イベントページ)
https://ochacafe.connpass.com/event/197023/

Transcript

1. コンテナランタイムの未来 Oracle Cloud Hangout Cafe 3 #6 Takuya Niita Oracle Corporation Japan Dec 23, 2020 コンテナランタイムの今までとこれから
2. 2 Copyright © 2020, Oracle and/or its affiliates. 1. コンテナランタイムとは 2. いろんなコンテナランタイムをのぞいてみる 3. コンテナランタイムの使い分け 4. デモ 5. まとめ アジェンダ
3. • 仁井田 拓也 • 日本オラクル株式会社 テクノロジー・クラウド・エンジニアリング本部 • 前職は某SIer • Oracle歴：1年8か月 • Cloud Native歴：1年半 • Kubernetesもここ1年で触り始めました • CKA取得 • ジブリ大好き • OCHaCafeは3回目の登壇 自己紹介 Copyright © 2020, Oracle and/or its affiliates. 3 @takuya_0301
4. コンテナランタイムとは Takuya Niita Oracle Corporation Japan Dec 23, 2020 Copyright © 2020, Oracle and/or its affiliates. 4 Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来
5. コンテナ型仮想化 • 軽量・高速な仮想マシン • カーネル部分をホストOSと共有するため軽量 • オーバヘッドが少なく高パフォーマンス • 高い可搬性 • 環境毎の差異をコンテナが吸収 • アプリケーションが最終的にどこにデプロイされても 一貫性を保証 • 効率的なローカル開発環境の構築 • テスト品質の向上 • CI/CDツールとの親和性 そもそもコンテナとは Copyright © 2020, Oracle and/or its affiliates. 5 コンテナ型仮想化 H/W ホストOS Bin/Lib アプリA Bin/Lib アプリB Bin/Lib アプリC Bin/Lib アプリD コンテナ管理基盤
6. 参考：仮想化実現方式の違い ハイパーバイザー型 vs コンテナ型 Copyright © 2020, Oracle and/or its affiliates. 6 ハイパーバイザー型 コンテナ型 仮想化の実現方式 仮想マシン(VM)は、OSの完全なコピー(ゲストOS)を保持する VM毎に、OSをインストールする必要がある カーネル部分をホストOSと共有するため、 VM毎に、OSをインストールする必要は無い 性能 ゲストOSの起動を伴う上、H/Wエミュレートのオーバーヘッ ド有り ホストOSから見るとアプリケーションのプロセス起動のみ H/Wエミュレートによるオーバーヘッドはほぼ無い ゲストイメージ サイズ 仮想マシンにゲストOSを含むためマシンイメージが大きく、 ストレージの容量が大きい (数十GB～) ゲストOSのイメージを所持する必要がなく、 ストレージの容量が小さい (数MB～) OSの種類 複数のゲストOSを選択可能 (Linux,Windows,その他) ホストOSに依存、異なるOSのシステムは動かせない Bin/Lib アプリA Bin/Lib ゲストOS ゲストOS アプリB アプリC ハイパーバイザー型 軽 量 高 速 コンテナ型 H/W ホストOS Bin/Lib アプリA Bin/Lib アプリB Bin/Lib アプリC Bin/Lib アプリD コンテナ管理基盤 H/W ホストOS ハイパーバイザー
7. Docker • 2013年に登場 • Docker社が開発したコンテナ型の仮想環境を作成、 配布、実行するプラットフォーム • コンテナを動かす環境だけではなく、コンテナを配 布するためのプラットフォーム(Docker Hub)も提 供 • Docker社は2019年にMirantis社に買収 コンテナランタイムのデファクトスタンダード みんなが知るコンテナランタイムといえば・・・ Copyright © 2020, Oracle and/or its affiliates. 7
8. Namespace • Linuxのホスト上に作成される新たに分離されたリソー ス(ネットワークやプロセスなど)空間を作り出す技術 • 上記技術によって作成されたリソース空間のことを 指す場合もある • ホストが持っているリソース空間とは別のリソース空間 を作成可能 • 基本的にはNamespaceは自身の情報しか見えない (他のNamespaceと共有すれば見える) • 具体例) • マウント名前空間 • マウントの集合、操作の隔離 • ネットワーク名前空間 • ネットワークデバイス、アドレス、ポートの隔離 Dockerはどのような仕組みで動くのか(Namespace) Copyright © 2020, Oracle and/or its affiliates. 8 H/W ホストOS Namespace Namespace Namespace マ ウ ン ト プ ロ セ ス ネ ッ ト ワ ー ク マ ウ ン ト プ ロ セ ス ネ ッ ト ワ ー ク マ ウ ン ト プ ロ セ ス ネ ッ ト ワ ー ク 隔離されたリソース空間
9. Dockerはどのような仕組みで動くのか(Namespace) Copyright © 2020, Oracle and/or its affiliates. 9 [opc@client ~]$ ls -l /proc/$$/ns total 0 lrwxrwxrwx. 1 opc opc 0 Nov 16 07:58 ipc -> ipc:[4026531839] lrwxrwxrwx. 1 opc opc 0 Nov 16 07:58 mnt -> mnt:[4026531840] lrwxrwxrwx. 1 opc opc 0 Nov 16 07:58 net -> net:[4026531993] lrwxrwxrwx. 1 opc opc 0 Nov 16 07:58 pid -> pid:[4026531836] lrwxrwxrwx. 1 opc opc 0 Nov 16 07:58 user -> user:[4026531837] lrwxrwxrwx. 1 opc opc 0 Nov 16 07:58 uts -> uts:[4026531838] /proc/プロセスID(カレントシェルのPID)/ns配下を確認することで対象リソースを確認可能 基本的には、mount、UTS、IPC、PID、ネットワークおよびユーザの6つが対象 ※UTS(UNIX Time Sharing)：ホスト名とNISドメイン名を管理 ※IPC(Inter Process Communication)：プロセス間で行われるデータ交換(共有メモリ、セマフォなど) $$はカレントシェルのPIDの意味
10. cgroup(control group) • プロセスをグループ化して，そのグループ内に存在する プロセスに対して共通の管理を実施 • ホストOSが持つCPUやメモリなどのリソースに対し て、グループごとに制限 • 2006年9月にGoogleのエンジニアによって最初の パッチが投稿され，2.6.24カーネルでマージ • cgroupは階層的に構成され、子groupは親groupの 属性を継承 • cgroupfsという特別なファイルシステムをマウントし て利用(操作感は通常のファイルシステムと同様) • 自由度は高いが、複数階層構造不可、サブシステム 間(リソース)の連携、など柔軟性や複雑さが課題 Dockerはどのような仕組みで動くのか(cgroup(v1)) Copyright © 2020, Oracle and/or its affiliates. 10 /sys/fs/cgroup CPU メモリ ディスクIO cgroup1 cgroup2 cgroup3 cgroup4 cgroup5 cgroup6 ・・・ ・・・ ・・・ サブシステム
11. Dockerはどのような仕組みで動くのか(cgroup) Copyright © 2020, Oracle and/or its affiliates. 11 [opc@client ~]$ ls -l /sys/fs/cgroup/cpu/ -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.stat -rw-r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage_all -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage_percpu -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage_percpu_sys -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage_percpu_user -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage_sys -r--r--r--. 1 root root 0 Nov 18 05:26 cpuacct.usage_user -rw-r--r--. 1 root root 0 Nov 18 05:26 cpu.cfs_period_us -rw-r--r--. 1 root root 0 Nov 18 05:26 cpu.cfs_quota_us -rw-r--r--. 1 root root 0 Nov 18 05:26 cpu.rt_period_us -rw-r--r--. 1 root root 0 Nov 18 05:26 cpu.rt_runtime_us -rw-r--r--. 1 root root 0 Nov 18 05:26 cpu.shares -r--r--r--. 1 root root 0 Nov 18 05:26 cpu.stat cgroupの配下はサブシステム構造 左例の場合 cpuサブシステム(cpu.*) cpuacctサブシステム(cpuacct.*) ※cpuサブシステム：cgroupに対してCPUの割り 当て ※cpuacct.*： cgroup内のプロセスが使用した CPU時間のレポート cgroupを作成するとこの階層にディレクトリが作成 され、リソースが割り当てられる 例えば、test01というcgroupを作成した場合、 test01というディレクトリが作成され、その配下に割 り当てられたリソース情報が出力される ・ ・ ・
12. cgroup v2 • cgroup v1の課題であった柔軟性や複雑さを解決す るために開発 • v2は4.5カーネルで正式機能 • 以下の特徴を持つ • 単一階層構造 • サブシステム間の連携 • プロセス単位での制御 • プロセスが所属できるのは末端のcgroupのみ • サブシステムの制御はcgroupごと • 操作感はv1と同様であり、v1との共存も可能 • 現時点ではKubernetesやdockerを含めた様々なコ ンテナ技術は未サポートか正式サポートしていない • v2をサポートしようと動いている最中 参考：cgroup v2 Copyright © 2020, Oracle and/or its affiliates. 12 /sys/fs/cgroup cgroup1 cgroup2 cgroup3 cgroup5 ・・・ CPU cgroup4 CPU メモリ 親のCPU割当設定を 引き継ぎ、メモリ割 当設定が追加される
13. Storage • Copy on Writeと呼ばれる方式でコンテナイメージ間 の差分を扱うことで、無駄なくコンテナイメージを管理 • Device Mapper/Btrfs/Aufsを利用して実現 Networking • Dockerでネットワーク通信を利用するための機能 • veth/bridge/iptablesを利用して実現 Security • Dockerでセキュリティを担保するための機能 • Capability/SELinux/seccompを利用して実現 Dockerはどのような仕組みで動くのか(その他機能) Copyright © 2020, Oracle and/or its affiliates. 13 Linux Kernel Storage Network Security cgroups Namespace
14. Namespace • コンテナごとにマウントポイント、ホスト名、プロセスID、 ユーザ、ネットワークなどをコンテナとして隔離 • コンテナごとに独立したファイルシステム、ホスト名、ネット ワークが実現でき、他のコンテナに対するリソースには基本 的に干渉不可 cgroup • コンテナごとにCPU、メモリやディスクI/Oなどのリソース を割当 • Dockerコマンドで言えば、「--cpu-share」オプションや 「--memory」オプションによるリソース割当を実現 Dockerはどのような仕組みで動くのか(まとめ) Copyright © 2020, Oracle and/or its affiliates. 14 Host Kernel cgroup cgroup Container1 (namespace) Container2 (namespace) Linux Kernelの機能で実現しているので、 ホスト(Kernel)から見るとただのプロセス
15. chroot • カレントディレクトリに起点となるルート ディレクトリを変更する操作 • 以降は、変更したディレクトリ配下にのみ アクセスが可能 • 外側のディレクトリにはアクセス不可 • 特権を分離してOSを保護する役割もあり、 セキュリティが向上 • ただし、ネットワークやプロセスはコント ロール不可 参考：コンテナとよく一緒に語られる技術 − chroot − Copyright © 2020, Oracle and/or its affiliates. 15 [opc@client ~]$ sudo chroot /home/opc/chroot_test/ bash-4.3# bash-4.3# pwd / bash-4.3# exit [opc@client ~]$ / home opc chroot_test / bin chrootコマンド実 行
16. LXC(Linux Containers) • 仮想化技術(KVM)などを利用することなく、隔離され たLinuxシステム（Linuxコンテナ）を構築するOS レベル仮想化のソフトウェア • 仮想化のレベルとしてはchroot < LXC < 仮想マ シンのイメージ • アプリケーションではなく単純に隔離した環境を構 築したいだけなら、コンテナよりも優れる • 起動するイメージはOSのフルイメージ • initやsystemdも動作 • cgroupやchrootなどを利用 • コマンドは、lxc-create/lxc-startなどDockerコマン ドと類似 • 初期のDockerでは実行ドライバとしてLXCが利用 されていた 参考：コンテナとよく一緒に語られる技術 − LXC(Linux Containers) − Copyright © 2020, Oracle and/or its affiliates. 16 H/W ホストOS LXC アプリ LXC LXC LXC アプリ アプリ アプリ
17. Kubernetesコンポーネントの復習 KubernetesにおけるDocker Copyright © 2020, Oracle and/or its affiliates. 17 >_ kubectl API Server Scheduler kubelet Container runtime Controller Manager Masterノード Workerノード etcd この部分に 注目！！
18. dockershim • ブリッジの役割を果たしてkubeletとの通信を実施 • DockerがContainer Runtime Interface(後述) に対応していないため • Kubernetesのin-treeパッケージとして開発 • kubernetes/pkg/kubelet/dockershim containerd • 高レベルランタイム(後述)の一種 • Dockerと直接対話し、低レベルランタイムと連携 する役割 runC • 低レベルランタイム(後述)の一種 • 実際にKernelを操作する役割 KubernetesにおけるDocker Copyright © 2020, Oracle and/or its affiliates. 18 kubelet dockershim docker containerd runC Kubernetes Docker
19. Docker一強から選べる時代へ • コンテナランタイムのデファクトスタンダードであった DockerがKubernetesで利用できる唯一のコンテナラ ンタイム • Kubernetes上で利用するとしても、単純にコンテ ナランタイムとして利用するとしても、Docker以外 の選択肢を考慮する必要性 • Docker社以外の企業(CoreOS社など)はDockerと 別にコンテナランタイムの標準化を実施しようとしていた • コンテナプラットフォームのエコシステムに対する将 来像が不安視されつつあった • Kubernetes v1.20ではランタイムとしてのDockerが deprecateに(in-tree dockershimの廃止) • Dockerイメージ自体は今後も利用可能 Docker以外の選択肢 Copyright © 2020, Oracle and/or its affiliates. 19 標準仕様の策定 ＆ Docker以外のランタイムの登場
20. いろんなコンテナランタイムをのぞいてみる Takuya Niita Oracle Corporation Japan Dec 23, 2020 Copyright © 2020, Oracle and/or its affiliates. 20 Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来
21. Open Container Initiative(OCI) • https://opencontainers.org • コンテナのフォーマットランタイムの標準仕様策定を目 的として、2015年6月設立されたイニチアチブ • Docker、Google、IBM、Oracle、 Microsoft、Red Hat、AWS、The Linux Foundationなどの大手テクノロジー企業が参加 • 2017年に「OCI v1.0」として最初の標準仕様 を発表 • この仕様に対応することで、コンテナランタイムやコンテ ナイメージの可搬性を保証 • 設立以前にCoreOS社がDocker社とは別のコンテナ に関する標準仕様を策定しようとしていた • OCIの発足により、両社を含めた複数企業で標 準仕様を作成していく動きになった コンテナランタイムを支える標準仕様 – OCI – Copyright © 2020, Oracle and/or its affiliates. 21
22. Runtime Specification • https://github.com/opencontainers/runtime- spec • コンテナランタイムの標準仕様 • 現在の主要なコンテナランタイムは全てこの標準 仕様に準拠している • Linuxコンテナの標準仕様だけでなく、 Solaris/Windows/Virtual Machine上のコンテナ ランタイムの仕様についても定められている • 最新v1.0.2(2020/12現在) Image Format Specification • https://github.com/opencontainers/image- spec • コンテナイメージの標準仕様 • 主に以下の仕様が定められている • Image Manifest • Image Index • Image Layout • Filesystem Layoutなど • 最新v1.0.1(2020/12現在) コンテナランタイムを支える標準仕様 – OCI v1.0 – Copyright © 2020, Oracle and/or its affiliates. 22 これらの標準仕様に従ってDockerのプラットフォームがいくつかの要素に分割。 Docker社はDockerのコンテナ管理機能を分離し、CNCF(Cloud Native Computing Foundation)に寄贈。 その後、CNCFはコードをまとめて2018年にcontainerdとして公開したため、現在のDockerでは標準でcontainerdが利 用されている ちなみに・・・
23. Container Runtime Interface(CRI) • https://github.com/kubernetes/cri-api • Kubernetes/Dockerとコンテナランタイムが通信する ためのI/Fを規定 • CNCFが管理 • 2016年12月にKubernetes v1.5からαリリース • CRIの規定によってDocker以外のコンテナランタイ ムの組み込みが容易に • 実体はKubernetesと通信するためのAPI仕様 (gRPCのスキーマ定義) コンテナランタイムを支える標準仕様 – CRI – Copyright © 2020, Oracle and/or its affiliates. 23 Container Runtime Kubernetes(kubelet)/Docker Container Runtime Interface(CRI)
24. 高レベルランタイム • Kubernetes(kubelet)またはDocker(dockershim) からの命令をunix socket経由でgRPCプロトコルを 利用して受信し動作 • コンテナイメージの取得やネットワークのセットアップ などを実施 • コンテナに対する直接的な命令は低レベルランタイ ム(後述)が実施 • Container Runtime Interface(CRI)の仕様に従って 実装 • CRIランタイムとも呼ばれる • 基本的にはホストOS上にdaemonプロセスとして常駐 • OCI Runtime Specに沿ったJSONを生成して低レベ ルランタイム(後述)にコンテナの作成を要求 コンテナランタイムの種類 – 高レベルランタイム – Copyright © 2020, Oracle and/or its affiliates. 24
25. 低レベルランタイム • 高レベルランタイムによって実行され、カーネルの機能 等を利用しながらコンテナの隔離環境を作成し、直接 操作 • Linuxのnamespaceやcgroupの制御は低レベル ランタイムが実施 • OCI Runtime Specに沿ったJSONの内容に基 づいてコンテナを生成 • Open Container Initiative(OCI)が策定した標準仕 様(OCI Runtime Spec)に従って実装 • OCIランタイムとも呼ばれる • 基本的にはホストOSに存在するバイナリ • 高レベルランタイムによってバイナリが実行される コンテナランタイムの種類 – 低レベルランタイム – Copyright © 2020, Oracle and/or its affiliates. 25
26. ①Kubernetes/DockerがCRIに基づいて高レベルランタ イムと通信(プロトコルはgRPC) ②高レベルランタイムが低レベルランタイムを呼び出す。そ の際にどのようなコンテナを生成するかという情報(JSON) を渡す ③低レベルランタイムが渡された情報(JSON)に基づいて namespace/cgroupなどを利用してコンテナ環境を作成 し、実行 高/低レベルランタイムの協業イメージ Copyright © 2020, Oracle and/or its affiliates. 26 Kubernetes(kubelet)/Docker ① ③ 高レベルランタイム (CRIランタイム) コンテナやイメージの管理 CRI OCI Runtime Spec 低レベルランタイム (OCIランタイム) コンテナの実行 ② JSONファイル コ ン テ ナ 作 成 daemon バイナリ
27. containerd • https://containerd.io/ • “An industry-standard container runtime” • もともとはDocker社が開発していたコンテナランタイム • Dockerの一部だったものが独立 • 2017年にCNCFに寄贈 • オープンソースとして公開 • 2018年5月に「containerd v1.1」が正式リリース • CNCF Graduated Project • CRIにネイティブ対応 • 最新v1.4.3(2020/12現在) • 他の高レベルランタイムと比較すると多機能 • イメージのpush機能やGo API、コンテナリソース の使用状況のメトリクス収集機能などを持つ 高レベルランタイムの具体例(containerd) Copyright © 2020, Oracle and/or its affiliates. 27 参考:https://containerd.io/
28. cri-o • https://cri-o.io/ • “LIGHTWEIGHT CONTAINER RUNTIME FOR KUBERNETES” • KubernetesにおいてDockerに代わる軽量コンテナラ ンタイムとして開発 • KubernetesプロジェクトがCRIを導入した後(2016 年)に開発が開始 • 2017年にCRI-O 1.0がリリース • 最新v1.20.0(2020/12現在) • containerdとは対照的にKubernetes指向で開発さ れてきた • kubeletからの要求を処理するために必要な最低 限の機能を具備 高レベルランタイムの具体例(cri-o) Copyright © 2020, Oracle and/or its affiliates. 28 参考:https://cri-o.io/
29. containerd • Kubernetesだけではなく、Dockerやその他のクライア ントから実行可能な機能を実装 • クライアントからOSに至るまで、様々なプラットフォーム で操作可能なエコシステムを実現可能 • プラットフォームとしてのDockerの一部だった恩恵 を継承 cri-o • Kubernetesに特化して開発されており、kubeletから 利用される前提で機能を実装 • containerdよりも軽量に実装されているが、エコシ ステムとして機能が実装されているわけではない • 最低限の機能のみを実装しているため、作りとし てはcontainerdよりもセキュア containerdとcri-oの比較 Copyright © 2020, Oracle and/or its affiliates. 29
30. rkt • https://coreos.com/rkt/ • “A security-minded, standards-based container engine” • CoreOS社が開発 • 2014年に「Rocket」として発表 • 2016年にv1.0をリリース • 2017年にCNCFに寄贈 • Dockerの対抗馬として開発 • rktは高レベルランタイムと低レベルランタイムの双方の 役割を持つ • 実はGitHubレポジトリ上はプロジェクトが終了している • 公式ドキュメントとしてもdeprecated 高レベルランタイムの具体例(rkt) Copyright © 2020, Oracle and/or its affiliates. 30 参考:https://github.com/rkt/rkt/
31. runc • https://github.com/opencontainers/runc • Open Container Initiative(OCI)によるコンテナランタ イム実装 • 低レベルランタイムの筆頭 • 低レベルランタイムの実装におけるリファレンス的に 存在 • 最新v1.0-rc92(2020/12現在) • コンテナランタイムとして広く利用されているものの 依然としてβ版 • 現時点でユースケースとして求められる機能は実 装されている • rootless(root権限なしでコンテナを実行する機能)に 対応済み 低レベルランタイムの具体例(runc) Copyright © 2020, Oracle and/or its affiliates. 31 runcの脆弱性 • 2019年2月12日に「runcの権限昇格の脆弱性 (CVE-2019-5736) 」として報告 • 脆弱性を悪用して細工したコンテナをユーザが実 行した場合、ホスト上の runc バイナリが意図せ ず上書きされるというもの • コンテナが起動しているホスト上で root 権限でコ マンドが実行される恐れ
32. gVisor(runsc) • https://github.com/google/gvisor • “an application kernel for containers that provides efficient defense-in-depth anywhere” • Go言語で実装されたアプリケーションカーネル Google社が開発し、オープンソースとして公開 • 最新:release-20201208.0(2020/12現在) • 直接Kernelを介さずにユーザ空間で処理 • gVisorがKernelのフリをする • ホストカーネルとコンテナを切り離すことでサンドボッ クス化 • セキュリティ性の向上 低レベルランタイムの具体例(gVisor) Copyright © 2020, Oracle and/or its affiliates. 32 参考:https://gvisor.dev/docs/
33. Kata Containers • https://katacontainers.io/ • “The speed of containers, the security of VMs” • OpenStack Foundationがオープンソースとして開発 • 最新v1.11.5(2020/12現在) • よりセキュアなコンテナランタイムを目指して開発 • コンテナの軽量さを保ちつつ、このコンテナ間の分 離レベルを仮想マシン並みにする • カーネルの共有を行わずコンテナごとにカーネルを 持つという実装(仮想マシンのアーキテクチャに近 い) • エミュレータとしてQEMUを利用 低レベルランタイムの具体例(Kata Containers) Copyright © 2020, Oracle and/or its affiliates. 33 参考: https://katacontainers.io/collateral/kata-containers-1pager.pdf
34. Nabla Containers(runnc) • https://nabla-containers.github.io/ • “A new approach to Container Isolation” • IBM社が開発するコンテナランタイム • 最新v0.3(2020/12現在) • Unikernelを使ってホストとカーネルを共有せずにコンテ ナをより安全に動作させる • Unikernelはアプリケーションを動作させるための最 低限の機能のみを持ち、 1:1で紐づくカーネル • ホストカーネルへの攻撃対象領域を最小限に抑 える • ソースコードの絶対量が少なくなり、バグが発生し にくく、コンテナライフサイクルも高速化 低レベルランタイムの具体例(Nabla Containers) Copyright © 2020, Oracle and/or its affiliates. 34 参考: https://nabla-containers.github.io/
35. OKE (Oracle Container Engine for Kubernetes) GKE (Google Kubernetes Engine) EKS (Elastic Kubernetes Service) AKS (Azure Kubernetes Service) OpenShift IKS (IBM Kubernetes Service) Docker ◦ ◦ ◦ ◦ ◦ ◦ containerd × ◦ ◦ (Fargate/Bottlerocket) ◦ × ◦ cri-o × × × × ◦ × runc ◦ ◦ ◦ ◦ ◦ ◦ gVisor × ◦ × × × × Kata Containers × × × × ◦ × Nabla Containers × × × × × × 各マネージドKubernetesプラットフォームでサポートしているランタイム Copyright © 2020, Oracle and/or its affiliates. 35
36. コンテナランタイムの使い分け Takuya Niita Oracle Corporation Japan Dec 23, 2020 Copyright © 2020, Oracle and/or its affiliates. 36 Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来
37. Kubernetesでの高レベルランタイムの利用 • 手順は大きく2つ(cri-oを具体例に) • コンテナランタイムのインストール • 右の例はcri-oのインストール • kubeletの設定 • /etc/default/kubeletにあるkubeletの引数 「KUBELET_EXTRA_ARGS」を編集 • cri-oの場合 • --container-runtime=remote • Dockerの場合は「--container-runtime=docker」 • --container-runtime- endpoint="unix:///var/run/crio/crio.sock” Kubernetesにおけるコンテナランタイムの使い分け Copyright © 2020, Oracle and/or its affiliates. 37 [opc@client ~]$ sudo apt-get install cri-o cri-o-runc [opc@client ~]$ sudo systemctl daemon-reload [opc@client ~]$ sudo systemctl start crio [opc@client ~]$ vi /etc/default/kubelet KUBELET_EXTRA_ARGS=--cgroup-driver=systemd --container-runtime=remote --container-runtime- endpoint="unix:///var/run/crio/crio.sock” [opc@client ~]$ ・ ・ ・ 参考:https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri-o
38. Podごとの低レベルランタイムの利用 • KubernetesのRuntimeClassリソースを利用 • RuntimeClassは現時点(v1.20)ではフィーチャー ゲート機能(β版) • API Serverとkubeletのフィーチャーゲートを有効にす ることが必須 • v1.14時点でデフォルトはtrue • 異なるPodに異なるコンテナランタイムを利用する ことが可能 • Podに対してhandler(対応するCRI設定)を付与 • handler設定は各ランタイムの設定ファイルで定義 • Podの用途に応じてセキュリティとパフォーマンスの バランスを取ることが可能 • 高レベルのセキュリティを担保しなければならないワーク ロードの場合は、従来よりセキュリティの高いコンテナラ ンタイムを利用するなど Kubernetesにおけるコンテナランタイムの使い分け Copyright © 2020, Oracle and/or its affiliates. 38 RuntimeClassのmanifest Podのmanifest ここに定義した RuntimeClassを指定 参考:https://kubernetes.io/ja/docs/concepts/containers/runtime-class/
39. パフォーマンス • Kubernetes上でのコンテナイメージのpull、コンテナの 起動・停止に要する時間 • 公開されている高レベルコンテナランタイムに関するベンチ マークの中から一部をピックアップして考察(結果としてはど れも同様の傾向) • 今回は以下の資料を参照 • https://events19.linuxfoundation.org/wp- content/uploads/2017/11/How-Container-Runtime-Matters- in-Kubernetes_-OSS-Kunal-Kushwaha.pdf • 具体的にはcreate(image pull)/start/stop/removeで計測したパ フォーマンスを計測 • 利用する低レベルランタイムは以下の通り • containerd: runc • cri-o: runc • Docker: (containerd) + runc 汎用性(移植性) • コンテナランタイムがオンプレミス、クラウド上での各種プ ラットフォームで動作するように設計されているか • Kubernetes上だけではなく、コンテナランタイム単 体としての汎用性 • OSとしてLinux/Windows上(ともにIntelを想定) で動作可能か • 各コンテナランタイム自体を相互入れ替え可能か 各コンテナランタイムをどう使い分ける？(高レベルランタイム編) Copyright © 2020, Oracle and/or its affiliates. 39
40. containerd • Create(image pull)に関しては 他ランタイムと比較すると最速 • graph driverではなく、 snapshotsを利用 • Start(コンテナの起動)がcri-oと 比較すると少し時間がかかる • Dockerよりは早い cri-o • Createは最も遅い • Dockerと同じgraph driver を利用(snapshotsよりもオー バヘッド高) • Startに関しては他ランタイムと比 較すると最速 • Kubernetesネイティブに実装 されており、オーバヘッドが少 ないため Docker(rktはdeprecateのため) • Createはcontainerdとcri-oの中 間の速さ • graph driverによるオーバー ヘッド(snapshotsよりもオー バヘッド高) • Start/Stopは他ランタイムよりも遅 い • dockershimをブリッジさせる ことによるオーバーヘッド パフォーマンスによる比較 Copyright © 2020, Oracle and/or its affiliates. 40
41. containerd • Dockerでも利用されており、汎 用性高 • コンテナランタイムとして Windows/Linux上のいずれでも daemonとして動作可能 • マネージドKubernetes上でも AKSとGKEなどがcontainerdを サポート済み(2020/12現在) • cri-oやDockerと入れ替え可能 cri-o • CRIネイティブ(Kubernetesネイ ティブ)なので、Kubernetes上で 動作 • Minikube/kubeadmなどの ツールでも動作可能 • Windowsコンテナは未サポート (Linuxシステムベースで動作) • containerdやDockerと入れ替え 可能 Docker(rktはdeprecateのため) • コンテナランタイムとして Windows/Linux上のいずれでも daemonとして動作可能 • Windowsコンテナもサポート • containerdやcri-oと入れ替え可 能 汎用性(移植性)による比較 Copyright © 2020, Oracle and/or its affiliates. 41
42. セキュリティ • Linuxカーネルに対するセキュリティ 機能を安全に利用しているか • ホストカーネルを共有している場 合はrootless実行に対応してい るか • 今回は、runcのみ考察 • 現時点で発見されている脆弱性 の内容 パフォーマンス • Kubernetes上でのコンテナイメー ジのpull、コンテナの起動・停止に 要するトータル時間で考察 • 公開されている高レベルコンテナラ ンタイムに関するベンチマークの中 から一部をピックアップして考察(結 果としてはどれも同様の傾向) • 今回は以下の資料を参照 • https://speakerdeck.com/makoc chi/jkd-20181205-about-low- level-runtimes 汎用性(移植性) • コンテナランタイムがオンプレミス、 クラウド上での各種プラットフォーム で動作するように設計されている か • Kubernetes上だけではなく、 コンテナランタイム単体として の汎用性 • OSとしてLinux/Windows上 (ともにIntelを想定)で動作 可能か • 各コンテナランタイム自体を 相互入れ替え可能か 各コンテナランタイムをどう使い分ける？(低レベルランタイム編) Copyright © 2020, Oracle and/or its affiliates. 42
43. runc • カーネルとホストは共有 • Linuxの各種セキュ リティ機能を活用 • rootless実行に対応済 み • 2019年に権限昇格に 関する脆弱性が発見 (CVE-2019-5736) • 既に対処済み • 他にも複数の脆弱性を 発見 Kata Containers • ホストカーネルとの分離 • 仮想環境を構築し、 コンテナを実行 • 2020年に権限管理に 関する脆弱性が発見 (CVE-2020-2023) • 既に対処済み gVisor • ホストカーネルとの分離 • アプリケーションカー ネルの利用 • 2018年に特権昇格(サ ンドボックス内)に関する 脆弱性を発見(CVE- 2018-19333) • 既に対処済み Nabla Containers • ホストカーネルとの分離 • Unikernelの利用 • まだ大きな脆弱性は発 見されていない (2020/12現在) • まだそれほど広く使 われていない • ホストOSカーネルへのシ ステムコールを7つまでに 制限 セキュリティによる比較 Copyright © 2020, Oracle and/or its affiliates. 43
44. 低レベルコンテナランタイムをどう使い分ける？(パフォーマンス) Copyright © 2020, Oracle and/or its affiliates. 44 runc • パフォーマンスはNabla Containers、gVisorに 次ぐ • ほぼgVisorと同パ フォーマンス • ホストカーネルを共有し ているので、余計なオー バーヘッドは少ない Kata Containers • パフォーマンスは最も悪 い(特に起動が遅い) • 特に仮想マシンをホ ストとした場合に最 悪 • 仮想マシンを構築するた め、オーバヘッドが高い gVisor • パフォーマンスはNabla Containersに次ぐ • runcとほぼ変わらな い • ただし、システムコールが 多くなるとオーバヘッドが 高くなる可能性 Nabla Containers • パフォーマンスは他ランタ イムの中で最良 • ソースコードの絶対 量が少ないため、ラ イフサイクルが高速 • ただし、汎用性(移植 性)に難あり(後述)
45. 低レベルコンテナランタイムをどう使い分ける？ (汎用性(移植性)) Copyright © 2020, Oracle and/or its affiliates. 45 runc • Dockerでも利用されて おり、汎用性高 • Windows/Linuxともに 問題なく動作可能 • Windowsの場合、 厳密にはrunhcsと いうruncのフォークを 利用 • 移行先とした場合、他 のランタイムとの入れ替 えも可能 Kata Containers • 仮想環境上で動作する ので、その仕組みを構築 できるLinuxのみ • Intel VT-x technology • 移行先とした場合のラン タイムの入れ替えは制限 あり gVisor • Linuxのみの動作に制 限される • システムコールが一 部未実装なため、 動作しないアプリが 存在 • 移行先とした場合のラン タイムの入れ替えは制限 あり Nabla Containers • Unikernelでコンパイルさ れたアプリケーションを Linuxのみで動作可能 • Nablaベースの専用 イメージの作成が必 須 • 移行先とした場合のラン タイムの入れ替えについ ては最も制限あり
46. コンテナランタイム比較まとめ Copyright © 2020, Oracle and/or its affiliates. 46 高レベルランタイム パフォーマンス 汎用性(移植性) containerd ◦ ◦ cri-o ◦ △ (Windowsコンテナは未サポート) docker △ (dockershimによるオーバヘッド) ◦ 低レベルランタイム セキュリティ パフォーマンス 汎用性(移植性) runc △ (ホストカーネルの共有) ◦ ◦ Kata Containers ◦ × (仮想化によるオーバーヘッド) △ (一部制限あり) gVisor ◦ ◦ △ (一部制限あり) Nabla Containers ◦ ◦ × (専用コンテナが必須)
47. 高レベルランタイム • containerdやcri-oの登場により、Docker以外の選択肢が広がっている • containerdやcri-oは機能的にもかなり成熟しており、Kubernetes上でもサポートされているので、プロダクション 環境でも十分利用可能 • パフォーマンスを考慮しても、Dockerよりアドバンテージあり • ランタイムの相互入れ替えや共存も問題なく利用可能 • コンテナ自体がDockerから普及した流れもあるので、Dockerが他のランタイムに代替されていくのはもう少し先に なる可能性が高い 低レベルランタイム • 高レベルランタイム同様に様々な選択肢が広がっている • Dockerなどで標準利用されているruncと比較すると主にセキュリティ性が担保されたランタイムが多いが、パフォー マンスや汎用性を考慮するとruncより少し劣る • 高レベルランタイムと比較すると、相互入れ替えや共存についてはやりづらい可能性あり • gVisorはGKEのランタイムとしてサポートされているので、他と比較すると使いやすい可能性もある • 今後の開発(cgroup v2対応にも期待)で、パフォーマンスや汎用性が向上すれば、より現実的に利用できるようになりそう 今後のコンテナランタイム Copyright © 2020, Oracle and/or its affiliates. 47
48. デモ Takuya Niita Oracle Corporation Japan Dec 23, 2020 Copyright © 2020, Oracle and/or its affiliates. 48 Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来
49. Oracle Linux Cloud Native Environment(OLCNE) • Oracle Linux(7 or 8)上でコンテナ環境などを構築す るためのフレームワーク • Kubernetes • サービスメッシュ(Istio) • Prometheus • Helm • yumレポジトリから「oracle-olcne-release-el7/8」 というパッケージをインストールすることで構築 • olcnectlというコマンドラインツールを用いて各 種ツールをインストール可能 • CNCF LandscapeのPlatformカテゴリにもノミネー ト • Oracle Cloud Infrastructureでプロビジョニングした Oracle LinuxでもOLCNEを利用可能 Docker以外のコンテナランタイムをKubernetesで動かしてみよう - デモ構成 - Copyright © 2020, Oracle and/or its affiliates. 49
50. • 環境：Oracle Linux 8(Oracle Cloud Infrastructure上でプロビジョニング) • スペック • VM.Standard.2.8(OCPU: 8/メモリー:120GB) • Intel VT-capable CPU(Kata Containersで必須) • Kubernetesバージョン：v1.18.10 • コンテナランタイム • 高レベルランタイム：cri-o(OLCNEのデフォルトランタイム) • 低レベルランタイム • runc(OLCNEのデフォルトランタイム) • Kata Containers(OLCNEにデフォルトでパッケージング。RuntimeClassによりruncと相互入れ替え可能) Docker以外のコンテナランタイムをKubernetesで動かしてみよう - デモ構成 - Copyright © 2020, Oracle and/or its affiliates. 50
51. Docker以外のコンテナランタイムをKubernetesで動かしてみよう - イメージ - Copyright © 2020, Oracle and/or its affiliates. 51 Operator Node runc-nginx kata-nginx 高レベルランタイム 低レベルランタイム
52. まとめ Takuya Niita Oracle Corporation Japan Dec 23, 2020 Copyright © 2020, Oracle and/or its affiliates. 52 Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来
53. コンテナランタイムの標準仕様と仕組み • コンテナランタイムに関する2つの標準仕様 • OCI(Open Container Initiative)とCRI(Container Runtime Interface) • 標準仕様に準拠した大きく2つにカテゴリされるランタイム • 高レベルランタイム(CRIランタイム)：kubelet(dockershim)と通信し、低レベルランタイムにコンテナの情報を渡す • 低レベルランタイム(OCIランタイム)：高レベルランタイムから渡された情報を元に実際にコンテナを実行する コンテナランタイムを取り巻く状況 • Dockerを始めとした既存プラットフォーム以外の選択肢を検討する必要性 • 高レベルランタイム：containerdやcri-oなどのCRIに準拠したランタイムの台頭 • 低レベルランタイム：ホストカーネルを共有するruncとは別のアプローチを取るgVisorなどの選択肢 今後のコンテナランタイム • K8s v1.20でのdockershimのdeprecatedなどの要因により、Docker以外のランタイムを利用する場面が増加 • 環境やアプリケーションの特性に応じたランタイムの採用 まとめ Copyright © 2020, Oracle and/or its affiliates. 53
54. 各コンテナランタイムの公式ドキュメントとソースレポジトリ • containerd • 公式ドキュメント：https://containerd.io/docs/ • レポジトリ：https://github.com/containerd/containerd • cri-o • 公式ドキュメント：https://cri-o.io/ • レポジトリ： https://github.com/cri-o/cri-o • runc • レポジトリ：https://github.com/opencontainers/runc • gVisor • レポジトリ： https://github.com/google/gvisor • Kata Containers • 公式ドキュメント：https://katacontainers.io/docs/ • レポジトリ：https://github.com/kata-containers • Nabla Containers • 公式ドキュメント：https://nabla-containers.github.io/ • レポジトリ：https://github.com/nabla-containers 参考資料 & Special Thanks!! Copyright © 2020, Oracle and/or its affiliates. 54
55. 各コンテナランタイムのパフォーマンス参考資料 • How Container Runtimes matter in Kubernetes? by Kunal Kushwaha NTT OSS Center • https://events19.linuxfoundation.org/wp-content/uploads/2017/11/How-Container-Runtime-Matters-in- Kubernetes_-OSS-Kunal-Kushwaha.pdf • jkd 20181205 About low level runtimes by makocchi • https://speakerdeck.com/makocchi/jkd-20181205-about-low-level-runtimes Oracle Linux Cloud Native Environment • https://download.oracle.com/ocomdocs/global/Day1-LM.zip (mcd19_m-2.pdf) • 2019/8/6 Modern Cloud Day Tokyo 講演資料 書籍 • 「Docker/Kubernetes開発・運用のためのセキュリティ実践ガイド」 • https://book.mynavi.jp/ec/products/detail/id=114099 • 「イラストでわかるDockerとKubernetes」 • https://gihyo.jp/book/2020/978-4-297-11837-2 参考資料 & Special Thanks!! Copyright © 2020, Oracle and/or its affiliates. 55
56. Thank you 56 Copyright © 2020, Oracle and/or its affiliates.