evolution of container runtime : containerD (Japanese version)

Transcript

1. Evolution of Container Runtime コンテナ・ランタイムの進化 Kunal Kushwaha @kunalkushwaha container
2. コンテナ・ランタイム コンテナをホスト上で管理するために、中心となる基本構成要素 • コンテナの実行と管理(supervision) • イメージの配布 • ネットワーク・インターフェースと管理 • ローカル・ストレージ • ネイティブに組み込まれたAPI
3. Docker より前の時代 - Linux VServer 2002 - OpenVZ 2005 - FreeBSD Jails 2005 - Solaris Containers. 2005 - LXC 2008 - エンドユーザはシステム管理者 - 分離した環境におけるプロセス実行に集中
4. Docker - 2013年3月に初リリース - コンテナ実行エンジンとして出発 - アプリケーションと依存性のパッケージに集中 - 階層化の手法を使いアプリケーションをスマートにパッケージ化することで、イメージ 間の共有が可能に - コンテナの作成にあたり、AUFSで効率的に階層化したイメージを扱う - エンドユーザは開発者とQA(品質管理) - 集中しているのは - アプリケーションのパッケージ化 - 異なったマシン/環境間でアプリケーションの再作成や共有 - 開発・QA 環境における、時間と領域の節約
5. Dockerの台頭 - 主なプラットフォーム全てに移植 - AUFS のみならず、devicemapper、 btrfs、 overlayfs、 zfs 等 - イメージのセキュリティ - コンテント・アドレッサブル・ストレージ (CAS)を docker v1.10 で導入 - 更なる機能 - イメージ構築、セキュリティ - 後方互換性 - 技術的負債？ - エコシステム - ネットワーク、ストレージ、ログ記録、オー ケストレータのソリューション
6. 思想(方向性)の対立 - Docker はデーモンであるべき - Docker イメージの形式 - 標準の docker ワークフロー (dockerhub) - Docker 1.12 (Swarmモード) Noooooo 好きじゃない人達がいる!!
8. Containerd プロジェクト • 2015年11月にスタートした、OCI ランタイムの runc を制御するため • 2016年の 1.11 までコンテナのランタイムとして Docker が使っていた • 2016年12月に新しい作業領域（スコープ）のもとで再スタート • 現在の Docker は 0.2.x 系のブランチを使用 • 新しい成果が反映されるのは 1.0 master ブランチから 新しい作業領域すべてを CNCF に寄贈
9. “containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users. containerd will serve as a core container runtime for the CNCF ecosystem.” （containerdは、開発者やエンドユーザが直接使うので はなく、より大きなシステムに組み込めるよう設計されて います。containerdはCNCFエコシステムの中心となる コンテナ・ランタイムになります。）
10. エコシステムにおける Containerd の役割 Ecosystem
11. つまり、Containerd は Docker を抽出したもの？ - Dockerの複雑さを修正したシンプルな設計 - 狭い領域に集中する小さな構成要素（コンポーネント） - すべてのサービスに対する GRPC インターフェース - 長期運用における安定性 - OCI イメージとランタイムのサポート - マルチテナンシー（名前空間）のサポート - ポータブル（移植性） - 領域を限定 - ネットワークを扱わない - ボリュームを扱わない - 構築を扱わない - ログを扱わない • Containerd サービス ◦ 中身 ◦ イメージ ◦ ルートファイルシステム ◦ 実行 ◦ Shim（詰め木） ちがいます! Containerd は進化であり、作り直しではありません
12. Containerd アーキテクチャ
13. ストレージ・アーキテクチャ Docker Containerd dist ctr Config Rootfs(mounts)
14. Containerdの利点 - シンプルで進化した設計 - 簡単に貢献できる - 簡単にメンテナンスできる - OCI 仕様に対応した設計 - コミュニティによって承認されたコンテナ向けスタンダード（標準） - ロックイン無し - プラグイン・アーキテクチャ - 簡単に拡張 - 限定的な領域 - 合意を得た機能のみ - 望まれていない機能が膨張しない - マルチテナンシー (名前空間) - 同一ホスト上で複数のオーケストレータを干渉せずに実行
15. 私は Containerd プロジェクトの対象？ - Docker / Kubernetes のエンドユーザ - いいえ。ほとんど同様に使えます。変更は間接的なものであり、おそらく気づかないでしょう。 - Cloud プロバイダ - はい。containerd との直接統合により、コンテナ・サービスを構築できます。 - Docker を使いますが、高度な機能は使わない場合 - いいえ。問題はありません。 - もしかしたら、対象です。それは、明確に欲しいものが何かわかっており、 Containerd上で使おうとす る場合です。 - Docker コンテナと一緒にカスタム・コンテナを実行する場合 - はい、名前空間機能の使用とカスタムコンテナの実行が、安全かつ簡単になります。
16. Containerd の現状 - 1.0 向け機能実装が今月末（6月）に完了 - 結合テストが計画中 - Containerd 向けの Kubernetes CRI - https://github.com/kubernetes-incubator/cri-containerd - AWS 統合 - https://github.com/samuelkarp/amazon-ecs-agent/tree/containerd - ベンチマーク／ストレス・テスト - https://github.com/estesp/bucketbench
17. プロジェクトへのs中 - Slack - github.com/containerd/containerd - #containerd (dockercommunity.slack.com) - #japanese - 参加して日本語で議論しましょう - 毎週の開発レポート : - https://github.com/containerd/containerd/tree/master/reports - Twitter でフォロー - @containerd
18. ありがとう Thanks