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

コンテナランタイムの未来
Oracle Cloud Hangout Cafe 3 #6
Takuya Niita
Oracle Corporation Japan
Dec 23, 2020
コンテナランタイムの今までとこれから

View Slide

2 Copyright © 2020, Oracle and/or its affiliates.
1. コンテナランタイムとは
2. いろんなコンテナランタイムをのぞいてみる
3. コンテナランタイムの使い分け
4. デモ
5. まとめ
アジェンダ

View Slide

• 仁井田拓也
• 日本オラクル株式会社
テクノロジー・クラウド・エンジニアリング本部
• 前職は某SIer
• Oracle歴：1年8か月
• Cloud Native歴：1年半
• Kubernetesもここ1年で触り始めました
• CKA取得
• ジブリ大好き
• OCHaCafeは3回目の登壇
自己紹介
Copyright © 2020, Oracle and/or its affiliates.
3
@takuya_0301

View Slide

コンテナランタイムとは
Takuya Niita
Dec 23, 2020
4
Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来

View Slide

コンテナ型仮想化
• 軽量・高速な仮想マシン
• カーネル部分をホストOSと共有するため軽量
• オーバヘッドが少なく高パフォーマンス
• 高い可搬性
• 環境毎の差異をコンテナが吸収
• アプリケーションが最終的にどこにデプロイされても
一貫性を保証
• 効率的なローカル開発環境の構築
• テスト品質の向上
• CI/CDツールとの親和性
そもそもコンテナとは
5
コンテナ型仮想化
H/W
ホストOS
Bin/Lib
アプリA
Bin/Lib
アプリB
Bin/Lib
アプリC
Bin/Lib
アプリD
コンテナ管理基盤

View Slide

参考：仮想化実現方式の違いハイパーバイザー型 vs コンテナ型
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
ハイパーバイザー

View Slide

Docker
• 2013年に登場
• Docker社が開発したコンテナ型の仮想環境を作成、
配布、実行するプラットフォーム
• コンテナを動かす環境だけではなく、コンテナを配
布するためのプラットフォーム(Docker Hub)も提
供
• Docker社は2019年にMirantis社に買収
コンテナランタイムのデファクトスタンダード
みんなが知るコンテナランタイムといえば・・・
7

View Slide

Namespace
• Linuxのホスト上に作成される新たに分離されたリソー
ス(ネットワークやプロセスなど)空間を作り出す技術
• 上記技術によって作成されたリソース空間のことを
指す場合もある
• ホストが持っているリソース空間とは別のリソース空間
を作成可能
• 基本的にはNamespaceは自身の情報しか見えない
(他のNamespaceと共有すれば見える)
• 具体例)
• マウント名前空間
• マウントの集合、操作の隔離
• ネットワーク名前空間
• ネットワークデバイス、アドレス、ポートの隔離
Dockerはどのような仕組みで動くのか(Namespace)
8
H/W
ホストOS
Namespace Namespace Namespace
マ
ウ
ン
ト
プ
ロ
セ
ス
ネ
ッ
ト
ワ
ー
ク
マ
ウ
ン
ト
プ
ロ
セ
ス
ネ
ッ
ト
ワ
ー
ク
マ
ウ
ン
ト
プ
ロ
セ
ス
ネ
ッ
ト
ワ
ー
ク
隔離されたリソース空間

View Slide

Dockerはどのような仕組みで動くのか(Namespace)
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の意味

View Slide

cgroup(control group)
• プロセスをグループ化して，そのグループ内に存在する
プロセスに対して共通の管理を実施
• ホストOSが持つCPUやメモリなどのリソースに対し
て、グループごとに制限
• 2006年9月にGoogleのエンジニアによって最初の
パッチが投稿され，2.6.24カーネルでマージ
• cgroupは階層的に構成され、子groupは親groupの
属性を継承
• cgroupfsという特別なファイルシステムをマウントし
て利用(操作感は通常のファイルシステムと同様)
• 自由度は高いが、複数階層構造不可、サブシステム
間(リソース)の連携、など柔軟性や複雑さが課題
Dockerはどのような仕組みで動くのか(cgroup(v1))
10
/sys/fs/cgroup
CPU メモリディスクIO
cgroup1
cgroup2
cgroup3
cgroup4
cgroup5
cgroup6
・・・・・・・・・
サブシステム

View Slide

Dockerはどのような仕組みで動くのか(cgroup)
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というディレクトリが作成され、その配下に割
り当てられたリソース情報が出力される
・
・
・

View Slide

cgroup v2
• cgroup v1の課題であった柔軟性や複雑さを解決す
るために開発
• v2は4.5カーネルで正式機能
• 以下の特徴を持つ
• 単一階層構造
• サブシステム間の連携
• プロセス単位での制御
• プロセスが所属できるのは末端のcgroupのみ
• サブシステムの制御はcgroupごと
• 操作感はv1と同様であり、v1との共存も可能
• 現時点ではKubernetesやdockerを含めた様々なコ
ンテナ技術は未サポートか正式サポートしていない
• v2をサポートしようと動いている最中
参考：cgroup v2
12
/sys/fs/cgroup
cgroup1 cgroup2
cgroup3 cgroup5
・・・
CPU
cgroup4
CPU
メモリ
親のCPU割当設定を
引き継ぎ、メモリ割
当設定が追加される

View Slide

Storage
• Copy on Writeと呼ばれる方式でコンテナイメージ間
の差分を扱うことで、無駄なくコンテナイメージを管理
• Device Mapper/Btrfs/Aufsを利用して実現
Networking
• Dockerでネットワーク通信を利用するための機能
• veth/bridge/iptablesを利用して実現
Security
• Dockerでセキュリティを担保するための機能
• Capability/SELinux/seccompを利用して実現
Dockerはどのような仕組みで動くのか(その他機能)
13
Linux Kernel
Storage Network Security
cgroups Namespace

View Slide

Namespace
• コンテナごとにマウントポイント、ホスト名、プロセスID、
ユーザ、ネットワークなどをコンテナとして隔離
• コンテナごとに独立したファイルシステム、ホスト名、ネット
ワークが実現でき、他のコンテナに対するリソースには基本
的に干渉不可
cgroup
• コンテナごとにCPU、メモリやディスクI/Oなどのリソース
を割当
• Dockerコマンドで言えば、「--cpu-share」オプションや
「--memory」オプションによるリソース割当を実現
Dockerはどのような仕組みで動くのか(まとめ)
14
Host
Kernel
cgroup cgroup
Container1
(namespace)
Container2
(namespace)
Linux Kernelの機能で実現しているので、
ホスト(Kernel)から見るとただのプロセス

View Slide

chroot
• カレントディレクトリに起点となるルート
ディレクトリを変更する操作
• 以降は、変更したディレクトリ配下にのみ
アクセスが可能
• 外側のディレクトリにはアクセス不可
• 特権を分離してOSを保護する役割もあり、
セキュリティが向上
• ただし、ネットワークやプロセスはコント
ロール不可
参考：コンテナとよく一緒に語られる技術 − chroot −
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コマンド実
行

View Slide

LXC(Linux Containers)
• 仮想化技術(KVM)などを利用することなく、隔離され
たLinuxシステム（Linuxコンテナ）を構築するOS
レベル仮想化のソフトウェア
• 仮想化のレベルとしてはchroot < LXC < 仮想マ
シンのイメージ
• アプリケーションではなく単純に隔離した環境を構
築したいだけなら、コンテナよりも優れる
• 起動するイメージはOSのフルイメージ
• initやsystemdも動作
• cgroupやchrootなどを利用
• コマンドは、lxc-create/lxc-startなどDockerコマン
ドと類似
• 初期のDockerでは実行ドライバとしてLXCが利用
されていた
参考：コンテナとよく一緒に語られる技術 − LXC(Linux Containers) −
16
H/W
ホストOS
LXC
アプリ
LXC LXC LXC
アプリアプリアプリ

View Slide

Kubernetesコンポーネントの復習
KubernetesにおけるDocker
17
>_
kubectl
API
Server
Scheduler
kubelet
Container
runtime
Controller
Manager
Masterノード Workerノード
etcd
この部分に
注目！！

View Slide

dockershim
• ブリッジの役割を果たしてkubeletとの通信を実施
• DockerがContainer Runtime Interface(後述)
に対応していないため
• Kubernetesのin-treeパッケージとして開発
• kubernetes/pkg/kubelet/dockershim
containerd
• 高レベルランタイム(後述)の一種
• Dockerと直接対話し、低レベルランタイムと連携
する役割
runC
• 低レベルランタイム(後述)の一種
• 実際にKernelを操作する役割
KubernetesにおけるDocker
18
kubelet
dockershim
docker
containerd
runC
Kubernetes
Docker

View Slide

Docker一強から選べる時代へ
• コンテナランタイムのデファクトスタンダードであった
DockerがKubernetesで利用できる唯一のコンテナラ
ンタイム
• Kubernetes上で利用するとしても、単純にコンテ
ナランタイムとして利用するとしても、Docker以外
の選択肢を考慮する必要性
• Docker社以外の企業(CoreOS社など)はDockerと
別にコンテナランタイムの標準化を実施しようとしていた
• コンテナプラットフォームのエコシステムに対する将
来像が不安視されつつあった
• Kubernetes v1.20ではランタイムとしてのDockerが
deprecateに(in-tree dockershimの廃止)
• Dockerイメージ自体は今後も利用可能
Docker以外の選択肢
19
標準仕様の策定
＆
Docker以外のランタイムの登場

View Slide

いろんなコンテナランタイムをのぞいてみる
Takuya Niita
Dec 23, 2020
20

View Slide

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 –
21

View Slide

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 –
22
これらの標準仕様に従ってDockerのプラットフォームがいくつかの要素に分割。
Docker社はDockerのコンテナ管理機能を分離し、CNCF(Cloud Native Computing Foundation)に寄贈。
その後、CNCFはコードをまとめて2018年にcontainerdとして公開したため、現在のDockerでは標準でcontainerdが利
用されている
ちなみに・・・

View Slide

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 –
23
Container Runtime
Kubernetes(kubelet)/Docker
Container Runtime Interface(CRI)

View Slide

高レベルランタイム
• Kubernetes(kubelet)またはDocker(dockershim)
からの命令をunix socket経由でgRPCプロトコルを
利用して受信し動作
• コンテナイメージの取得やネットワークのセットアップ
などを実施
• コンテナに対する直接的な命令は低レベルランタイ
ム(後述)が実施
• Container Runtime Interface(CRI)の仕様に従って
実装
• CRIランタイムとも呼ばれる
• 基本的にはホストOS上にdaemonプロセスとして常駐
• OCI Runtime Specに沿ったJSONを生成して低レベ
ルランタイム(後述)にコンテナの作成を要求
コンテナランタイムの種類 – 高レベルランタイム –
24

View Slide

低レベルランタイム
• 高レベルランタイムによって実行され、カーネルの機能
等を利用しながらコンテナの隔離環境を作成し、直接
操作
• Linuxのnamespaceやcgroupの制御は低レベル
ランタイムが実施
• OCI Runtime Specに沿ったJSONの内容に基
づいてコンテナを生成
• Open Container Initiative(OCI)が策定した標準仕
様(OCI Runtime Spec)に従って実装
• OCIランタイムとも呼ばれる
• 基本的にはホストOSに存在するバイナリ
• 高レベルランタイムによってバイナリが実行される
コンテナランタイムの種類 – 低レベルランタイム –
25

View Slide

①Kubernetes/DockerがCRIに基づいて高レベルランタ
イムと通信(プロトコルはgRPC)
②高レベルランタイムが低レベルランタイムを呼び出す。そ
の際にどのようなコンテナを生成するかという情報(JSON)
を渡す
③低レベルランタイムが渡された情報(JSON)に基づいて
namespace/cgroupなどを利用してコンテナ環境を作成
し、実行
高/低レベルランタイムの協業イメージ
26
Kubernetes(kubelet)/Docker
①
③
(CRIランタイム)
コンテナやイメージの管理
CRI
OCI Runtime Spec
(OCIランタイム)
コンテナの実行
②
JSONファイル
コ
ン
テ
ナ
作
成
daemon
バイナリ

View Slide

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)
27
参考:https://containerd.io/

View Slide

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)
28
参考:https://cri-o.io/

View Slide

containerd
• Kubernetesだけではなく、Dockerやその他のクライア
ントから実行可能な機能を実装
• クライアントからOSに至るまで、様々なプラットフォーム
で操作可能なエコシステムを実現可能
• プラットフォームとしてのDockerの一部だった恩恵
を継承
cri-o
• Kubernetesに特化して開発されており、kubeletから
利用される前提で機能を実装
• containerdよりも軽量に実装されているが、エコシ
ステムとして機能が実装されているわけではない
• 最低限の機能のみを実装しているため、作りとし
てはcontainerdよりもセキュア
containerdとcri-oの比較
29

View Slide

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)
30
参考:https://github.com/rkt/rkt/

View Slide

runc
• https://github.com/opencontainers/runc
• Open Container Initiative(OCI)によるコンテナランタ
イム実装
• 低レベルランタイムの筆頭
• 低レベルランタイムの実装におけるリファレンス的に
存在
• 最新v1.0-rc92(2020/12現在)
• コンテナランタイムとして広く利用されているものの
依然としてβ版
• 現時点でユースケースとして求められる機能は実
装されている
• rootless(root権限なしでコンテナを実行する機能)に
対応済み
低レベルランタイムの具体例(runc)
31
runcの脆弱性
• 2019年2月12日に「runcの権限昇格の脆弱性
(CVE-2019-5736) 」として報告
• 脆弱性を悪用して細工したコンテナをユーザが実
行した場合、ホスト上の runc バイナリが意図せ
ず上書きされるというもの
• コンテナが起動しているホスト上で root 権限でコ
マンドが実行される恐れ

View Slide

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)
32
参考:https://gvisor.dev/docs/

View Slide

Kata Containers
• https://katacontainers.io/
• “The speed of containers, the security of VMs”
• OpenStack Foundationがオープンソースとして開発
• 最新v1.11.5(2020/12現在)
• よりセキュアなコンテナランタイムを目指して開発
• コンテナの軽量さを保ちつつ、このコンテナ間の分
離レベルを仮想マシン並みにする
• カーネルの共有を行わずコンテナごとにカーネルを
持つという実装(仮想マシンのアーキテクチャに近
い)
• エミュレータとしてQEMUを利用
低レベルランタイムの具体例(Kata Containers)
33
参考: https://katacontainers.io/collateral/kata-containers-1pager.pdf

View Slide

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)
34
参考: https://nabla-containers.github.io/

View Slide

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プラットフォームでサポートしているランタイム
35

View Slide

コンテナランタイムの使い分け
Takuya Niita
Dec 23, 2020
36

View Slide

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におけるコンテナランタイムの使い分け
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

View Slide

Podごとの低レベルランタイムの利用
• KubernetesのRuntimeClassリソースを利用
• RuntimeClassは現時点(v1.20)ではフィーチャー
ゲート機能(β版)
• API Serverとkubeletのフィーチャーゲートを有効にす
ることが必須
• v1.14時点でデフォルトはtrue
• 異なるPodに異なるコンテナランタイムを利用する
ことが可能
• Podに対してhandler(対応するCRI設定)を付与
• handler設定は各ランタイムの設定ファイルで定義
• Podの用途に応じてセキュリティとパフォーマンスの
バランスを取ることが可能
• 高レベルのセキュリティを担保しなければならないワーク
ロードの場合は、従来よりセキュリティの高いコンテナラ
ンタイムを利用するなど
Kubernetesにおけるコンテナランタイムの使い分け
38
RuntimeClassのmanifest
Podのmanifest
ここに定義した
RuntimeClassを指定
参考:https://kubernetes.io/ja/docs/concepts/containers/runtime-class/

View Slide

パフォーマンス
• 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を想定)
で動作可能か
• 各コンテナランタイム自体を相互入れ替え可能か
各コンテナランタイムをどう使い分ける？(高レベルランタイム編)
39

View Slide

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をブリッジさせる
ことによるオーバーヘッド
パフォーマンスによる比較
40

View Slide

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と入れ替え可
能
汎用性(移植性)による比較
41

View Slide

セキュリティ
• Linuxカーネルに対するセキュリティ
機能を安全に利用しているか
• ホストカーネルを共有している場
合はrootless実行に対応してい
るか
• 今回は、runcのみ考察
• 現時点で発見されている脆弱性
の内容
パフォーマンス
• Kubernetes上でのコンテナイメー
ジのpull、コンテナの起動・停止に
要するトータル時間で考察
• 公開されている高レベルコンテナラ
ンタイムに関するベンチマークの中
から一部をピックアップして考察(結
果としてはどれも同様の傾向)
• 今回は以下の資料を参照
• https://speakerdeck.com/makoc
chi/jkd-20181205-about-low-
level-runtimes
汎用性(移植性)
• コンテナランタイムがオンプレミス、
クラウド上での各種プラットフォーム
で動作するように設計されている
か
• Kubernetes上だけではなく、
コンテナランタイム単体として
の汎用性
• OSとしてLinux/Windows上
(ともにIntelを想定)で動作
可能か
• 各コンテナランタイム自体を
相互入れ替え可能か
各コンテナランタイムをどう使い分ける？(低レベルランタイム編)
42

View Slide

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つまでに
制限
セキュリティによる比較
43

View Slide

低レベルコンテナランタイムをどう使い分ける？(パフォーマンス)
44
runc
• パフォーマンスはNabla
Containers、gVisorに
次ぐ
• ほぼgVisorと同パ
フォーマンス
• ホストカーネルを共有し
ているので、余計なオー
バーヘッドは少ない
Kata Containers
• パフォーマンスは最も悪
い(特に起動が遅い)
• 特に仮想マシンをホ
ストとした場合に最
悪
• 仮想マシンを構築するた
め、オーバヘッドが高い
gVisor
• パフォーマンスはNabla
Containersに次ぐ
• runcとほぼ変わらな
い
• ただし、システムコールが
多くなるとオーバヘッドが
高くなる可能性
Nabla Containers
• パフォーマンスは他ランタ
イムの中で最良
• ソースコードの絶対
量が少ないため、ラ
イフサイクルが高速
• ただし、汎用性(移植
性)に難あり(後述)

View Slide

低レベルコンテナランタイムをどう使い分ける？ (汎用性(移植性))
45
runc
• Dockerでも利用されて
おり、汎用性高
• Windows/Linuxともに
問題なく動作可能
• Windowsの場合、
厳密にはrunhcsと
いうruncのフォークを
利用
• 移行先とした場合、他
のランタイムとの入れ替
えも可能
Kata Containers
• 仮想環境上で動作する
ので、その仕組みを構築
できるLinuxのみ
• Intel VT-x
technology
• 移行先とした場合のラン
タイムの入れ替えは制限
あり
gVisor
• Linuxのみの動作に制
限される
• システムコールが一
部未実装なため、
動作しないアプリが
存在
タイムの入れ替えは制限
あり
Nabla Containers
• Unikernelでコンパイルさ
れたアプリケーションを
Linuxのみで動作可能
• Nablaベースの専用
イメージの作成が必
須
タイムの入れ替えについ
ては最も制限あり

View Slide

コンテナランタイム比較まとめ
46
高レベルランタイムパフォーマンス汎用性(移植性)
containerd ○ ○
cri-o ○ △
(Windowsコンテナは未サポート)
docker △
(dockershimによるオーバヘッド)
○
低レベルランタイムセキュリティパフォーマンス汎用性(移植性)
runc △
(ホストカーネルの共有)
○ ○
Kata Containers ○ ×
(仮想化によるオーバーヘッド)
△
(一部制限あり)
gVisor ○ ○ △
(一部制限あり)
Nabla Containers ○ ○ ×
(専用コンテナが必須)

View Slide

• containerdやcri-oの登場により、Docker以外の選択肢が広がっている
• containerdやcri-oは機能的にもかなり成熟しており、Kubernetes上でもサポートされているので、プロダクション
環境でも十分利用可能
• パフォーマンスを考慮しても、Dockerよりアドバンテージあり
• ランタイムの相互入れ替えや共存も問題なく利用可能
• コンテナ自体がDockerから普及した流れもあるので、Dockerが他のランタイムに代替されていくのはもう少し先に
なる可能性が高い
• 高レベルランタイム同様に様々な選択肢が広がっている
• Dockerなどで標準利用されているruncと比較すると主にセキュリティ性が担保されたランタイムが多いが、パフォー
マンスや汎用性を考慮するとruncより少し劣る
• 高レベルランタイムと比較すると、相互入れ替えや共存についてはやりづらい可能性あり
• gVisorはGKEのランタイムとしてサポートされているので、他と比較すると使いやすい可能性もある
• 今後の開発(cgroup v2対応にも期待)で、パフォーマンスや汎用性が向上すれば、より現実的に利用できるようになりそう
今後のコンテナランタイム
47

View Slide

デモ
Takuya Niita
Dec 23, 2020
48

View Slide

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で動かしてみよう - デモ構成 -
49

View Slide

• 環境：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で動かしてみよう - デモ構成 -
50

View Slide

Docker以外のコンテナランタイムをKubernetesで動かしてみよう - イメージ -
51
Operator Node
runc-nginx kata-nginx

View Slide

まとめ
Takuya Niita
Dec 23, 2020
52

View Slide

コンテナランタイムの標準仕様と仕組み
• コンテナランタイムに関する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以外のランタイムを利用する場面が増加
• 環境やアプリケーションの特性に応じたランタイムの採用
まとめ
53

View Slide

各コンテナランタイムの公式ドキュメントとソースレポジトリ
• 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!!
54

View Slide

各コンテナランタイムのパフォーマンス参考資料
• 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!!
55

View Slide

View Slide

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

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

oracle4engineer
PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

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

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

oracle4engineer PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

oracle4engineer
PRO