2017年12月時点で Cloud Native Computing Foundation (CNCF) がホストするプロジェクトについて簡単にまとめてみました。自分が KubeCon 2016 @ Seattle に参加した時点では 4 プロジェクトでしたが、そこから約1年で 14 プロジェクトと大きく増加しました。
Cloud Native Computing Foundation (CNCF)とは
Cloud Native Computing Foundation (以下 CNCF) は Kubernetes や Prometheus といったクラウドネイティブな OSS 技術の推進を行う団体です。2015 年に Linux Foundation 傘下に設立され、一つ目のプロジェクトとして Kubernetes が Google から寄贈されました。AWS、Google Cloud, Microsoft などクラウド大手や、Red Hat, Docker, CoreOS といったクラウド技術に関連する主要な企業が CNCF に参画しています (メンバー企業一覧)。
CNCF では他にも Certified Kubernetes という Kubernetes クラスタの適合性の認定や Certified Kubernetes Administrator (CKA) という Kubernetes 管理者の認定試験なども行っています。KubeCon + CloudNativeCon というイベントの主催もしており、KubeCon + CloudNativeCon 2017 には 4000 人以上が参加しました。(Z Lab からも 4名参加しました)
プロジェクト一覧 (2017年12月時点)
2017年12月時点では下記の 14 プロジェクトが CNCF でホストされています。プロジェクトは CNCF の Technical Oversight Committee (TOC) に Proposal を上げて受理されたらホストされるという流れになっています。Pull Request で挙がっている Proposal を見ると他にどんなプロジェクトが候補にあるかがわかります。
| プロジェクト名 | 種類 | 受理 |
|---|---|---|
| Kubernetes | コンテナオーケストレーション | #1 (2016年3月) |
| Prometheus | モニタリング | #2 (2016年5月) |
| OpenTracing | 分散トレーシング API | #3 (2016年10月) |
| Fluetnd | ログコレクタ | #4 (2016年11月) |
| linkerd | サービスメッシュ | #5 (2017年1月) |
| gRPC | Remote Procedure Call | #6 (2017年3月) |
| CoreDNS | サービスディスカバリ | #7 (2017年3月) |
| containerd | コンテナランタイム | #8 (2017年3月) |
| rkt | コンテナランタイム | #9 (2017年3月) |
| CNI | ネットワーク API | #10 (2017年5月) |
| Envoy | サービスメッシュ | #11 (2017年9月) |
| Jaeger | 分散トレーシング | #12 (2017年9月) |
| Notary | セキュリティ | #13 (2017年10月) |
| TUF | ソフトウェア・アップデート仕様 | #14 (2017年10月) |
各プロジェクト
Kubernetes
Kubernetes はコンテナのオーケストレーションツールです。Kubernetes によって数台から数千台のサーバーが一つのクラスタとして管理され、シンプルなインタフェースを通してその中に効率良くコンテナを配置し管理することができます。これにより数百のサーバー台数が必要なアプリケーションのデプロイもコマンド一つで簡単に行うことができます。コンテナを採用することで PaaS と比べて高い柔軟性を持っており、IaaS レイヤを抽象化しマルチクラウドを実現する点も注目されています。
元々は Google が社内のオーケストレーションツール Borg で得た 10 年以上の経験を元に開発を始めたプロジェクトで、最初に CNCF に寄贈されたプロジェクトになります。CNCF プロジェクトの中でも圧倒的に規模が大きく、CNCF 主催の KubeCon + CloudNativeCon というイベント名でも Kubernetes の名前を全面に押し出していることから CNCF の中心プロダクトと言ってよいでしょう。
Prometheus
Prometheus は Pull 型のメトリクス監視システムです。多彩なサービスディスカバリを特徴としており、Kubernetes のように監視対象が動的に変化する環境に適したシステムです。PromQL という独自のクエリ言語によって柔軟に可視化やアラートルールの設定を行うことができます。2015 年から PromCon というイベントが毎年開催されています。
Z Lab でも Prometheus を Kubernetes のメトリクス監視として利用しており Grafana の可視化やアラーティングを行っています。
OpenTracing
OpenTracing は分散トレーシングのためのオープンな仕様と各言語のライブラリ (Tracer) を提供しています。マイクロサービスではどのサービスでどれだけの時間がかかっているかがパフォーマンスを分析する上で重要となるため、このような分散トレーシングの技術が必要とされます。分散トレーシングのシステムは Google 社内の分散トレーシングシステム Dapper の論文が 2010 年に発表されたこをきっかけに Zipkin、 Jaeger、LightStep など様々なシステムが実装されています。トレーシングシステムの間で API の互換性がないと多くのソフトウェアに組み込んでもらうのは難しいため、ベンダに依存しない標準 API を提供することを目標としているようです。
プロジェクトの目的についてはプロジェクトコミッタの Ben Sigelman 氏の Towards Turnkey Distributed Tracing という記事がまとまっています。Ben Sigelman 氏は Google 在籍時に Dapper の開発者かつ論文の著者の一人で、現在は LightStep というモニタリング技術の会社の CEO です。
引用: 図(左)Dapperの論文 よりリクエストのトレースツリー、図(右)OpenTracing の Overview
Fluentd
Fluetned は Treasure Data が開発したログコレクタです。プラグインも充実しており様々な入力・出力に対応できます。2011 年にリリースされており、現在の CNCF のプロジェクトの中でも歴史があるプロダクトだと思われます。
Z Lab でも Kubernetes のコンテナログやシステムのログ収集に Fluentd を利用しています。また fluent-plugin-prometheus を用いて、nghttpx ingress controller のログを Prometheus のメトリクスに変換して HTTP トラフィックのリクエスト数やレスポンスタイムの可視化を行っています。
linkerd
linkerd は HTTP Proxy として動作しサービスメッシュを実現するシステムです。サービスメッシュとして下記のような機能を担います。
- 負荷分散
- サーキットブレーカー
- サービスディスカバリ
- リクエストルーティング
- リトライ
- メトリクス
アプリケーション側では上記機能を linkerd を HTTP Proxy として設定するだけで利用ことができます。Kubernetes で利用する場合はノードごとに DaemonSet で配置する方式とサイドカーとして Pod ごとに配置する方式の二つが用意されています。
なお、linkerd の作者による新しいサービスメッシュ Conduit も開発が始まっています。linkerde は JVM 言語の Scala で書かれていましたが、Conduit は Rust で書き直されており軽量化を実現しているようです。
gRPC
gRPC は Google が開発した HTTP/2 をベースとした RPC フレームワークです。Google 内で 15 年以上使われてきた Stubby という RPC フレームワークの経験を元に作られています。gRPC は下記のような特徴があります。
- Protocol Buffers (v3) をベースとしている
- バイナリ形式のためデータ量が少なく、高速にパースを行える
- IDL(Interface Definition Language) を定義することで、各種言語のライブラリを生成できる
- proto3 という最新バージョンで、serviceというRPCの定義や、JSONへの相互変換ができるようになった
- 通信プロトコルは HTTP/2
- コネクションの多重化とバイナリプロトコルで効率よく通信可能
- 双方向でのストリーム通信が可能
- 多言語に対応
- C, C++, Java, Go, Node.js, Python, Ruby, Objective-C, PHP, C#
Kubernetes でも etcd (v3) との通信などで使われており、Microservice 間の RPC として大きな注目を浴びています。
CoreDNS
CoreDNS はプラグイン機構を特徴とした軽量な DNS サーバーです。Kubernetes (~v1.8) でも使われている SkyDNS の後継に当たるプロジェクトで、コア開発者も同じ Miek Gieben氏です。Kubernetes v1.9 では KubeDNS を置き換えるようになるようです。KubeDNS は SkyDNS, dnsmasq などを組み合わせた複雑な構成になっていましたが、CoreDNS ではプラグイン機構を使ってシンプルに実装されています。
containerd
containerd は Docker が寄贈したコンテナランタイムです。containerd は gRPC のインタフェースを持ったデーモンでコンテナのライフサイクルを管理しています。もともとは Docker Engine の一部だったコンテナランタイム部分を分離したもので、現在は Docker Engine が containerd を利用する形になっています。Docker Engine はコンテナランタイム以外にも多くの機能を統合する形で開発が進められていますが、containerd として切り離されたことによってコンテナランタイム部分だけをシンプルに利用できるようになりました。Docker と containerd、 runC の関係については containerd の公式ページ に詳しくかかれています。
Kubernetes でも cri-containerd という containerd をランタイムとして使うプロジェクトが進められています。CRI は Container Runtime Interface の略でKubernetes とコンテナランタイムのインタフェースを Protocol Buffers の API として定義したものです。
引用: [Containerd Brings More Container Runtime Options for Kubernetes](http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html) より。cri-containerd で Docker のレイヤが不要になる。
rkt
rkt は CoreOS が開発したコンテナランタイムです。rkt リリース時(2014年12月)の CoreOS の blog ポストでは、Docker のセキュリティモデルを批判し rkt の開発を発表して話題になりました。Pod をネイティブで扱うことができる点や管理用デーモンが不要な点などコンテナオーケストレーションと相性の良いアーキテクチャになっています。
引用: [rkt vs other projects](https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html) より rkt と Docker のプロセスモデルの比較
CNI
CNI は Container Network Interface の略でコンテナのネットワークインタフェースを抽象化する仕様です。Project Calico や Weave Net といった様々なコンテナネットワークが CNI プラグインとして対応しており、CNI に対応した Kubernetes や rkt で簡単に利用することができます。CNI プラグインは実行可能なバイナリとして実装する形となっており、起動時に渡される環境変数などが CNI の仕様書 で定義されています。
Envoy
Envoy は Lyft が開発したサービスメッシュです。下記のような特徴があります
- C++ で書かれており高パフォーマンス
- サービスディスカバリ
- 負荷分散
- リトライ
- サーキットブレーカー
- メトリクス
マイクロサービス向けのセキュアなサービスメッシュ Istio でも Envoy を拡張したものをデータプレーンのコンポーネントとして利用しています。
Jaeger
Jaeger (\ˈyā-gər\ イエーガーに近い発音) は Uber が開発した分散トレーシングシステムです。CNCF のプロジェクトである OpenTracing に対応しています。
* https://jaeger.readthedocs.io/en/latest/ より引用
Notary
Notary は 任意のコンテントの正当性の検証をするためのサーバー、クライアントの実装です。The Update Framework (TUF) 共に CNCF に寄贈されました。TUF はソフトウェア・アップデートのためのセキュリティの仕様であり Notary は TUF の仕様を実装しています。Docker イメージが正当な提供者が作成したか検証を行う Docker Content Trust のコンポーネントとして Notary が使われています。
引用: [Understand the Notary service architecture](https://github.com/theupdateframework/notary/blob/master/docs/service_architecture.md) より。クライアントとサーバーのシーケンス図
TUF
The Update Framework (TUF) はセキュアなソフトウェアのアップデートを配布するための仕様です。2009 年にニューヨーク大学の Justin Cappos 教授らによって仕様が書かれました。ファイルの署名による正当性の検証だけでなく、ロールごとの鍵とタイムスタンプや有効期限などのメタデータを持つことで正当ではあるが脆弱な古いファイルによるリプレイ攻撃を防ぐといった、安全に最新のアップデートを配布する仕組みを提供しています。TUF を実装したものとして共に CNCF に寄贈された Notary があります。