Knativeの概要
Knative（ケイネイティブ）とは、Kubernetes上でサーバーレスを実現するためのOSSです。サーバーレスとはクラウド上でバックエンドプログラムやプロセスを動作させる機能のことです。Knativeは、DockerやKubernetesの深い知識がなくても、開発者が作成したプログラムを、容易にクラウド環境にデプロイ可能です。また、簡単な設定だけで、オートスケール（Pod数を0まで減らすスケールインも）や、きめ細やかトラフィック分散が実現可能なことも利点の1つです。
Knativeは、元々はGoogle社が主体となり開発が進められていましたが、2023年にCNCFのインキュベーティングプロジェクトとして承認されました。今後もさらなる活用が期待されるOSSです。GCPの「Cloud
Run」や、OpenShiftの「Red Hat OpenShift Serverless」はKnativeがベースとなり提供されているマネージドサービスとなっており、プロダクション環境でも既に稼働実績があるOSSといえます。
Knative には、主に下記の3つの機能があります。それぞれ用途が異なります。
- Knative Functions
- Knative Serving
- Knative Eventing
Knative Functionsは、Knative、Kubernetes、コンテナ―、Dockerfileなどの深い知識がなくても、Knativeで関数を利用するための機能を提供します。具体的には、開発言語に応じたテンプレートを利用することで、Knativeの機構に則ったビルド、デプロイ、起動のすべてが容易に実行できるようになります。ビルドした関数は、Open Container Initiative (OCI) フォーマットのコンテナイメージとして、自動的にレジストリに保存されます。作成したイメージは、Knative Servingや、Knative Eventingでも利用可能です。開発者がコアロジックの実装に集中できるという利点があります。
Knative Servingは、HTTPイベントをトリガーとするサーバーレス機能を提供します。Knativeでは、KubernetesのCustom Resource Definitions (CRDs)を使って、以下のリソースが定義されます。
| Service |
ワークロードのライフサイクル全体を管理するリソースで、後述するRoute、Configuration、RevisionはこのServiceを元に作成されます（つまり、Knative利用者はこのServiceだけを定義します）。 Serviceでは、利用するイメージの定義や、オートスケーリングの各種設定、各Revisionへの割り振りの調整などが行えます。 Kubernetesの「Service」と名称が同じなので、混同しないように注意が必要です。 |
|---|---|
| Route | ネットワークエンドポイントを1つ以上のRevisionにマッピングするリソースです。割り振り先の割合調整する等のブルーグリーンデプロイメントや、カナリアリリースの実現に利用されます。 |
| Configuration |
デプロイメントを適切な状態に保つためのリソースです。 Configurationが変更されると、新しいRevisionが作成されます。 |
| Revision | ワークロードに何か変更が加わった際に、その構成のスナップショットを保持ためのリソースです。基本的に不変オブジェクトになっており、これによりいつでも任意のバージョンへの切り替えおよび、ロールバックを可能にします。 |
参考： https://knative.dev/docs/serving/
Knative Eventingは、アプリケーションでイベント駆動型アーキテクチャを使うための機能を提供します。Source（イベントプロデューサー)がBrokerに向けて送信したイベントをTriggerによって、様々なSink（イベントコンシューマー）に向けて送信することが可能です。Knative Eventingでは、HTTP POST要求を使用して、イベントプロデューサーとSinkの間でイベントの送受信をおこないます。これらのイベントは、クラウドにおけるイベント通知の標準仕様である「CloudEvents」に準拠しており、任意のプログラム言語でイベントの作成、解析、送受信が可能です。Knative Eventingコンポーネントは疎結合なので、イベントプロデューサーやイベントコンシューマーがない状態でもお互いに独立して開発およびデプロイが可能です。
参考： https://knative.dev/docs/concepts/eventing-resources/brokers/
Knativeの主な特徴
| カスタムリソースを使ったシンプルなYAML構成 | KnativeのCRDsを利用することで、シンプルなYAMLファイルを書くだけで、柔軟なサーバーレス構成をデプロイすることが可能です。 |
|---|---|
| 柔軟なオートスケール | サービスへの要求がない場合には、Pod数はゼロにまでスケールインさせることが可能です。要求があれば、ゼロからスケールアウトします。つまり、クライアントからの要求量に合わせて、柔軟にワークロードをコントロールできます。 |
| 様々なロールアウト戦略 | Revisionの機能により、ブルーグリーンデプロイメント、カナリアリリースのような顧客の要件に沿ったロールアウトが実現可能です。 |
| 多くのイベントソースとの統合 |
多種多様なイベントプロデューサーが通知するCloudEvents形式のイベントを処理するソースを定義できます。Knativeが提供するソースや、サードパーティ製のソースを含めて、利用できるソースは下記のURLで確認できます。 参考： https://knative.dev/docs/eventing/sources/ CloudEvents形式でないイベントを発行するイベントプロデューサーであっても、カスタムイベントソースを作成することで対応することは可能です。 |
| 細やかなイベント処理 | イベントブローカーからのイベントは、Triggerによって処理され、指定した配信先に送付されます。抽出するイベントにはフィルターを設定でき、配信先を調整することが可能です。アノテーションにより依存関係を設定して、Triggerを動作させる条件を指定することも可能です。配信が失敗した場合、配信失敗時の送信先、リトライまでの時間、リトライポリシーなどの細かな設定が可能です。 |
| 拡張性 |
Knativeは様々なOSSと、統合、拡張が可能です。
|
Knativeの動作環境
-
Knative Serving / Knative Eventing
-
プロトタイプ用途
- ローカル1ノード： 3CPU、4GBメモリ
-
プロダクション用途
- 単一クラスタノード： 最低 6CPU、6GBメモリ、30GBディスクストレージ
- マルチクラスタノード： 最低 2CPU、4GBメモリ、20GBディスクストレージ
- Kubernetes 1.24 以上、kubectl がインストールされていること
- イメージを参照する必要があるため、Kubernetesクラスタがインターネットアクセス可能であること（ただし、プライベートレジストリも利用可能）
-
プロトタイプ用途
参考： https://knative.dev/docs/install/yaml-install/serving/install-serving-with-yaml/
参考： https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/
類似の機能をもつOSS
Knativeとほぼ同等の機能をもつOSSとして、KEDA（Kubernetes Event-driven Autoscaling）があります。こちらもKubernetes上で動作するイベント駆動型のオートスケーラーです。以前は、HTTPイベントには対応していませんでしたが、アドオンによりHTTPトラフィックのイベント駆動にも対応が可能になりました。
参考： https://keda.sh/
Knativeのライセンス
Knativeは、Apache2.0ライセンスです。Apache License（アパッチ・ライセンス）のコードが使用されていることの明記を条件に、ソースコードの自由な改変と公開が認められています。
参考情報
Knativeのサポート
NRIではお客様のご要望に応じて様々な支援ができるサービスをご用意しました。
詳細は下記ページをご確認ください。
