Knative 徹底解説概要編

Google Cloud Next’18 では先進的なサービスが数多く発表されました。
中でも、1日目のKeynoteで発表された Cloud Services Platform は今後のコンテナ開発を大きく変える可能性のあるものでした。
本記事から始まる Knative 徹底解説シリーズでは、Cloud Services PlatformファミリーであるKnativeの3つの役割を、サンプルコードを交えて使い方と共に解説していきます。

このシリーズは以下の構成の予定です。

概要編 ←いまここ
実践編1 Knative Servingについての実践
実践編2 Knative Buildingについての実践
実践編3 Knative Eventingについての実践

Knativeで変わるもの
Knativeの3つの役割
Knativeの始め方
- Next Step

Knativeで変わるもの

Knativeを使用するためには、Kubernetesがインストールされたクラスタを用意する必要がありますが、KnativeはKubernetesと同様にコンテナをオーケストレーションするためのものである、という点は変わりません。

Knativeは、クラウドにおけるPaaSやFaaSのようなアーキテクチャを、Knativeがインストールされていれば(つまり、Kubernetesクラスタであれば)どこでも実現できるものです。

今までのオンプレミスのワークロードといえば、いかにしてクラウドコンピューティングへ移行していくのかという課題を抱えるものも少なくありませんでしたが、Knative及び GKE On-Prem の登場によって、オンプレミスからクラウドへ向いていたワークロードの移行方向が逆転する可能性を秘めていると感じましたし、Keynote内でも「クラウドの力をオンプレへ持ってくる」という表現がされていました。

Knativeを使用することによって以下のようなことが実現できます。

Deployment, Service, HPAと用意していた設定が1つで済む
長時間使用していないサービスをゼロスケール
同一リクエストを複数のコンテナに対してトラフィック分割が可能
クラスタ内でコンテナをビルドする
Pub/SubトピックへのPublishイベントを検知してコンテナでメッセージを処理する

詳しい解説はKnative 徹底解説シリーズそれぞれの記事で触れます。

Knativeの3つの役割

Knativeには大きく分けて3つの機能があります。

Knative Build

Knative Buildは、その名の通りコンテナをビルドするための機能です。
GCPで Cloud Build を使っていればコンテナのビルドは済んでしまうので、GCPを使用している開発者にとってはあまり恩恵を感じませんが、Knativeが使えればどこでもコンテナをビルドできるというのは、ワークロードをオンプレミスで実行している開発者にとっては役立つ場面があるかもしれません。
Knative Buildでビルドしたコンテナを、プライベートなコンテナレジストリへpushすることができます。

コンテナビルドのソースファイルとしてGoogle Cloud Storageやプライベートなものを含むGitHubリポジトリを指定することもできます。GitHubリポジトリの場合には特定のリビジョンを指定することも可能です。

Knative Serving

Knative ServingはKnativeの中核を成す機能です。
DockerHubやContainer Registryへ保存されているコンテナイメージを起動し、サービスとして実行することができます。

Servingを使うことによって長時間(だいたい5分くらい)アクセスのないコンテナの起動Pod数をゼロにすることが可能になる他、トラフィック分割によるコンテナ単位でのカナリアリリースなど、Kubernetesではできなかったかゆいところに手が届くようになります。

Servingは雑に言ってしまうとGCPのAppEngineのようなもので、コンテナを作ってあとはServingの定義ファイルさえ書いてしまえば自分たちのサービスを提供することができるシンプルさです。

Knative Eventing

Knative EventingはApache KafkaやGCPの Pub/Subへのメッセージを処理するFaaSのような役割を担います。
Knativeのドキュメントによると、EventingにはCNCFにより定義される Cloud Events の思想に基づき、コンテナをFaaSのようなものとして起動し、サービス同士の疎結合性を高める目的があります。