Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

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

oracle4engineer

December 23, 2020
Tweet

More Decks by oracle4engineer

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. コンテナランタイムとは
    Takuya Niita
    Oracle Corporation Japan
    Dec 23, 2020
    Copyright © 2020, Oracle and/or its affiliates.
    4
    Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来

    View full-size slide

  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
    コンテナ管理基盤

    View full-size slide

  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
    ハイパーバイザー

    View full-size slide

  7. Docker
    • 2013年に登場
    • Docker社が開発したコンテナ型の仮想環境を作成、
    配布、実行するプラットフォーム
    • コンテナを動かす環境だけではなく、コンテナを配
    布するためのプラットフォーム(Docker Hub)も提

    • Docker社は2019年にMirantis社に買収
    コンテナランタイムのデファクトスタンダード
    みんなが知るコンテナランタイムといえば・・・
    Copyright © 2020, Oracle and/or its affiliates.
    7

    View full-size slide

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










































    隔離されたリソース空間

    View full-size slide

  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の意味

    View full-size slide

  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
    ・・・ ・・・ ・・・
    サブシステム

    View full-size slide

  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というディレクトリが作成され、その配下に割
    り当てられたリソース情報が出力される



    View full-size slide

  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割当設定を
    引き継ぎ、メモリ割
    当設定が追加される

    View full-size slide

  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

    View full-size slide

  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)から見るとただのプロセス

    View full-size slide

  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コマンド実

    View full-size slide

  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
    アプリ アプリ アプリ

    View full-size slide

  17. Kubernetesコンポーネントの復習
    KubernetesにおけるDocker
    Copyright © 2020, Oracle and/or its affiliates.
    17
    >_
    kubectl
    API
    Server
    Scheduler
    kubelet
    Container
    runtime
    Controller
    Manager
    Masterノード Workerノード
    etcd
    この部分に
    注目!!

    View full-size slide

  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

    View full-size slide

  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以外のランタイムの登場

    View full-size slide

  20. いろんなコンテナランタイムをのぞいてみる
    Takuya Niita
    Oracle Corporation Japan
    Dec 23, 2020
    Copyright © 2020, Oracle and/or its affiliates.
    20
    Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来

    View full-size slide

  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

    View full-size slide

  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が利
    用されている
    ちなみに・・・

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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
    バイナリ

    View full-size slide

  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/

    View full-size slide

  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/

    View full-size slide

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

    View full-size slide

  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/

    View full-size slide

  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 権限でコ
    マンドが実行される恐れ

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

  36. コンテナランタイムの使い分け
    Takuya Niita
    Oracle Corporation Japan
    Dec 23, 2020
    Copyright © 2020, Oracle and/or its affiliates.
    36
    Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来

    View full-size slide

  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

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  44. 低レベルコンテナランタイムをどう使い分ける?(パフォーマンス)
    Copyright © 2020, Oracle and/or its affiliates.
    44
    runc
    • パフォーマンスはNabla
    Containers、gVisorに
    次ぐ
    • ほぼgVisorと同パ
    フォーマンス
    • ホストカーネルを共有し
    ているので、余計なオー
    バーヘッドは少ない
    Kata Containers
    • パフォーマンスは最も悪
    い(特に起動が遅い)
    • 特に仮想マシンをホ
    ストとした場合に最

    • 仮想マシンを構築するた
    め、オーバヘッドが高い
    gVisor
    • パフォーマンスはNabla
    Containersに次ぐ
    • runcとほぼ変わらな

    • ただし、システムコールが
    多くなるとオーバヘッドが
    高くなる可能性
    Nabla Containers
    • パフォーマンスは他ランタ
    イムの中で最良
    • ソースコードの絶対
    量が少ないため、ラ
    イフサイクルが高速
    • ただし、汎用性(移植
    性)に難あり(後述)

    View full-size slide

  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ベースの専用
    イメージの作成が必

    • 移行先とした場合のラン
    タイムの入れ替えについ
    ては最も制限あり

    View full-size slide

  46. コンテナランタイム比較まとめ
    Copyright © 2020, Oracle and/or its affiliates.
    46
    高レベルランタイム パフォーマンス 汎用性(移植性)
    containerd ○ ○
    cri-o ○ △
    (Windowsコンテナは未サポート)
    docker △
    (dockershimによるオーバヘッド)

    低レベルランタイム セキュリティ パフォーマンス 汎用性(移植性)
    runc △
    (ホストカーネルの共有)
    ○ ○
    Kata Containers ○ ×
    (仮想化によるオーバーヘッド)

    (一部制限あり)
    gVisor ○ ○ △
    (一部制限あり)
    Nabla Containers ○ ○ ×
    (専用コンテナが必須)

    View full-size slide

  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

    View full-size slide

  48. デモ
    Takuya Niita
    Oracle Corporation Japan
    Dec 23, 2020
    Copyright © 2020, Oracle and/or its affiliates.
    48
    Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  51. Docker以外のコンテナランタイムをKubernetesで動かしてみよう - イメージ -
    Copyright © 2020, Oracle and/or its affiliates.
    51
    Operator Node
    runc-nginx kata-nginx
    高レベルランタイム
    低レベルランタイム

    View full-size slide

  52. まとめ
    Takuya Niita
    Oracle Corporation Japan
    Dec 23, 2020
    Copyright © 2020, Oracle and/or its affiliates.
    52
    Oracle Cloud Hangout Cafe 3 #6 – コンテナランタイムの未来

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  56. Thank you
    56 Copyright © 2020, Oracle and/or its affiliates.

    View full-size slide