第3章 アーキテクチャー
3.1. Knative Serving アーキテクチャー
OpenShift Container Platform 上の Knative Serving により、開発者はサーバーレスアーキテクチャーを使用して、クラウドネイティブアプリケーション を作成できます。Serverless は、アプリケーション開発者がサーバーのプロビジョニングやアプリケーションのスケーリングを管理する必要がないクラウドコンピューティングのモデルです。これらのルーチンタスクはプラットフォームによって抽象化されるため、開発者は従来のモデルの場合よりも速くコードを実稼働にプッシュできます。
Knative Serving は、OpenShift Container Platform クラスター上のサーバーレスワークロードの動作を定義し、制御する Kubernetes カスタムリソース定義 (CRD) としてオブジェクトのセットを提供し、クラウドネイティブアプリケーションのデプロイおよび管理をサポートします。CRD についての詳細は、「カスタムリソース定義による Kubernetes API の拡張」を参照してください。
開発者はこれらの CRD を使用して、複雑なユースケースに対応するためにビルディングブロックとして使用できるカスタムリソース (CR) インスタンスを作成します。以下は例になります。
- サーバーレスコンテナーの迅速なデプロイ
- Pod の自動スケーリング
CR についての詳細は、「カスタムリソース定義からのリソースの管理」を参照してください。
3.1.1. Knative Serving CRD
- Service
-
service.serving.knative.devCRD はワークロードのライフサイクルを自動的に管理し、アプリケーションがネットワーク経由でデプロイされ、到達可能であることを確認します。これは、ユーザーが作成した Service またはカスタムリソースに対して加えられるそれぞれの変更についての Route、Configuration、および新規 Revision を作成します。Knative での開発者の対話のほとんどは、Service を変更して実行されます。 - Revision
-
revision.serving.knative.devCRD は、ワークロードに対して加えられるそれぞれの変更についてのコードおよび設定の特定の時点におけるスナップショットです。リビジョンはイミュータブル (変更不可) オブジェクトであり、必要な期間保持することができます。 - Route
-
route.serving.knative.devCRD は、ネットワークのエンドポイントを、1 つ以上の Revision にマップします。部分的なトラフィックや名前付きルートなどのトラフィックを複数の方法で管理することができます。 - Configuration
-
configuration.serving.knative.devCRD は、デプロイメントの必要な状態を維持します。これにより、コードと設定を明確に分離できます。設定を変更すると、新規 Revision が作成されます。
