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

Transcript

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

   View Slide

2. 自己紹介
   

   View Slide

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

   View Slide

4. コンテナの仕組み
   

   View Slide

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

   View Slide

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

   View Slide

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

   View 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 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 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 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 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 Slide

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

    View Slide

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

    View 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 Slide

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

    View 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 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 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

25. microVMベースのFirecracker
    

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

35. 他にはないの？
    

    View Slide

36. （時間があれば）Unikernelの紹介
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

40. Unikernelのメリット・デメリット
    VMと違い環境の分離までは行わずにプロセスとしてコンテナが動くので軽量かつ高
    速
    不要なカーネルの機能は含まれないため、ホストとの接地点が少ない
    Unikernelの技術自体の知名度が低く、知見があまりない
    + Runncというものを導入するハードルの高さ
    イメージのビルド環境が特殊でフォーマットの互換性もない
    

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide