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

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

Kohei Ota
August 22, 2020

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

Kohei Ota

August 22, 2020
Tweet

More Decks by Kohei Ota

Other Decks in Technology

Transcript

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

    View full-size slide

  2. 自己紹介

    View full-size slide

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

    View full-size slide

  4. コンテナの仕組み

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. コンテナの仕組み
    /
    /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

    View full-size slide

  9. コンテナの仕組み
    /
    /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

    View full-size slide

  10. /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
    プロセス起動!

    View full-size slide

  11. /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つがコンテナ

    View full-size slide

  12. /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つがコンテナ
    これがコンテナイメージね

    View full-size slide

  13. コンテナランタイムは何してる?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. コンテナランタイムの役割(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

    View full-size slide

  18. コンテナランタイムの役割(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

    View full-size slide

  19. 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)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. microVMベースのFirecracker

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  28. コンテナでの利用例
    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/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. 「サンドボックス」のgVisor

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. 他にはないの?

    View full-size slide

  36. (時間があれば)Unikernelの紹介

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  40. Unikernelのメリット・デメリット
    VMと違い環境の分離までは行わずにプロセスとしてコンテナが動くので軽量かつ高

    不要なカーネルの機能は含まれないため、ホストとの接地点が少ない
    Unikernelの技術自体の知名度が低く、知見があまりない
    + Runncというものを導入するハードルの高さ
    イメージのビルド環境が特殊でフォーマットの互換性もない

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  43. 参考資料
    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

    View full-size slide

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

    View full-size slide