Knative serving のアーキテクチャの概要

このページでは、Knative serving のアーキテクチャの概要と、Google Kubernetes Engine クラスタで Knative serving を有効にする際に発生する変更について説明します。

この情報は、次のようなタイプのユーザーに有用です。

• Knative serving を使用しているユーザー。
• GKE クラスタの実行経験があるオペレーター。
• Knative serving を Kubernetes クラスタと統合して、より優れたアプリケーションを設計したり、Knative serving アプリケーションを構成する必要があるアプリケーション デベロッパー。

デフォルト インストールのコンポーネント

Knative serving をクラスタにインストールし、ステートレス ワークロードを接続して管理します。Knative コンポーネントは knative-serving Namespace に作成されます。

Knative serving では、Cloud Service Mesh を使用してトラフィックをルーティングします。デフォルトでは、Cloud Service Mesh はコンポーネントを istio-system Namespace にインストールします。

Knative serving と Cloud Service Mesh によってインストールされるコンポーネントは次のとおりです。

• Knative serving によって knative-serving Namespace にインストールされるコンポーネントは次のとおりです。

  • アクティベーター: Pod がゼロにスケールインされるか、リビジョンに送信されるリクエストで過負荷になると、アクティベーターはリクエストを一時的にキューし、指標をオートスケーラーに送信して、Pod をスピンアップします。オートスケーラーによって報告された指標と使用可能な Pod に基づいてリビジョンがスケーリングされると、キュー内のリクエストがそのリビジョンに転送されます。アクティベーターはデータプレーン コンポーネントです。データプレーン コンポーネントは、ユーザー トラフィックを転送するすべての機能とプロセスを管理します。
  • オートスケーラー: アクティベーターとリクエストの同時実行制限を適用するデータプレーン コンポーネントであるキュープロキシ サイドカー コンテナから、指標を集計して処理します。オートスケーラーは、リビジョンの同時実行数を計算し、目的の Pod 数に基づいてデプロイのサイズを調整します。リビジョンで Pod が使用可能な場合、オートスケーラーはコントロール プレーン コンポーネントになります。それ以外の場合は、Pod をゼロにスケールインすると、オートスケーラーはデータプレーン コンポーネントになります。
  • コントローラ: オートスケーラーとサービス オブジェクトの子リソースを作成および更新します。コントローラはコントロール プレーン コンポーネントです。コントロール プレーン コンポーネントは、ユーザー トラフィックのリクエストパスを確立するすべての機能とプロセスを管理します。
  • 指標コレクタ: Knative serving コンポーネントから指標を収集し、Cloud Monitoring に転送します。
  • Webhook: デフォルト値の設定、一貫性のないオブジェクトや無効なオブジェクトの拒否、Knative serving リソースに対する Kubernetes API 呼び出しの検証と変更を行います。Webhook はコントロール プレーン コンポーネントです。

• Cloud Service Mesh によってインストールされ、istio-system Namespace で実行されるコンポーネントは次のとおりです。

  • クラスタ ローカル ゲートウェイ: Knative serving サービス間の内部トラフィックを処理するデータプレーンのロードバランサ。クラスタ ローカル ゲートウェイは、GKE クラスタ内からのみアクセスできます。個人情報や内部プロセスが誤って公開されることを防ぐために、外部ドメインの登録は行われません。
  • Istio Ingress Gateway: クラスタの外部からのトラフィック（外部と内部のいずれかのネットワークからのトラフィックを含む）の受信と処理を担当するデータプレーン内のロードバランサ。
  • Istio: 正しいエンドポイントで HTTP リクエストが処理されるように、クラスタ ローカル ゲートウェイと Istio Ingress ゲートウェイを構成します。Istiod はコントロール プレーン コンポーネントです。詳細については、Istiod をご覧ください。

Knative serving コンポーネントは、GKE コントロール プレーン クラスタの更新の際に自動的に更新されます。詳しくは、利用可能な GKE バージョンをご覧ください。

クラスタ リソースの使用量

Knative serving の初期インストールには、クラスタに対しておおよそ 1.5 個の仮想 CPU と 1 GB のメモリが必要です。クラスタ内のノード数は、Knative serving のインストールに必要な容量とメモリ要件に影響しません。

1 つのアクティベーターあたり、最大 1,000 milliCPU および 600 MiB RAM でリクエストの消費が可能です。既存のアクティベーターで受信リクエスト数を処理できない場合は、追加の Activator が提供されます。これには、300 milliCPU および 60 MiB RAM の予約が必要になります。

Knative serving サービスが作成したすべての Pod によって、リクエストの同時実行制限を適用するキュープロキシ サイドカーが作成されます。キュープロキシによって 25 milliCPU が予約されますが、メモリは予約されません。キュープロキシの使用量は、キューに追加されるリクエスト数とリクエストのサイズによって異なります。CPU とメモリリソースに制限はありません。

Service の作成

Knative serving Service のアーキテクチャ（クリックして拡大）

Knative serving によって、Service、Revision、Configuration、Route といった一連のカスタム リソース定義（CRD）が定義され、Kubernetes が拡張されます。CRD により、クラスタ上のアプリケーションの動作が定義および制御されます。

• Knative serving Service は、Knative serving によって定義される最上位のカスタム リソースです。これは、ワークロードのライフサイクル全体を管理する単一のアプリケーションです。サービスにおいて、サービスの更新ごとに、ルート、構成、新しいリビジョンがアプリに含まれていることが確認されます。
• リビジョンは、コードと構成に関するポイントインタイムかつ不変のスナップショットです。
• Configuration には、最新のリビジョンの現在の構成が保持され、過去のすべてのリビジョンの履歴が記録されます。構成を変更すると、新しいリビジョンが作成されます。
• Route では、HTTP エンドポイントが定義され、エンドポイントがリクエストの転送先となる 1 つ以上のリビジョンに関連付けられます。

ユーザーが Knative serving Service を作成すると、次の処理が行われます。

1. Knative serving Service オブジェクトによって、次のことが定義されます。

   1. リビジョンの提供方法に関する構成。
   2. このバージョンのサービスに対する不変のリビジョン。
   3. リビジョンに指定されたトラフィックの割り当てを管理するためのルート。

2. ルート オブジェクトによって、VirtualService が作成されます。VirtualService オブジェクトによって、ゲートウェイ トラフィックが正しいリビジョンにルーティングされるように、Ingress ゲートウェイとクラスタ ローカル ゲートウェイが構成されます。

3. リビジョン オブジェクトによって、コントロール プレーン コンポーネント（Kubernetes Service オブジェクトと Deployment オブジェクト）が作成されます。

4. ネットワーク構成によって、アプリのアクティベーター、オートスケーラー、ロードバランサが接続されます。

リクエスト処理

次の図は、サンプルの Google Kubernetes Engine クラスタ上で、Knative serving データプレーン コンポーネントを経由するユーザー トラフィックに想定されるリクエストパスの概要を示しています。

Knative serving クラスタのアーキテクチャ（クリックして拡大）

次の図は、上の図を展開した、ユーザー トラフィックのリクエストパスの詳細を示しています。さらに詳細を次に示します。

Knative serving リクエストパス（クリックして拡大）

Knative serving リクエストパスの場合:

1. トラフィックは、以下を経由します。

   • クラスタ外部からのトラフィック用の Ingress ゲートウェイ
   • クラスタ内部のトラフィック用のクラスタ ローカル ゲートウェイ

2. VirtualService コンポーネントは、トラフィック ルーティング ルールを指定します。VirtualService コンポーネントによって、ユーザー トラフィックが正しいリビジョンにルーティングされるように、ゲートウェイが構成されます。

3. コントロール プレーン コンポーネントである Kubernetes Service は、トラフィックを処理する Pod の可用性に応じて、リクエストパスの次のステップを決定します。

   • リビジョンに Pod が存在しない場合:

     1. Pod のスケールアップのために、アクティベーターによって、受信したリクエストが一時的にキューに入れられ、指標がオートスケーラーに push されます。
     2. オートスケーラーによって、Deployment 内の Pod が望ましい状態までスケーリングされます。
     3. Deployment により、追加のリクエストを受信できるように追加の Pod が作成されます。
     4. アクティベーターによって、キュープロキシ サイドカーに対するリクエストが再試行されます。

   • サービスがスケールアウトされている（Pod が使用可能な）場合、Kubernetes Service によってキュープロキシ サイドカーにリクエストが送信されます。

4. キュープロキシ サイドカーでは、コンテナが一度に処理できるリクエスト キュー パラメータ（シングル スレッドまたはマルチスレッドのリクエスト）が適用されます。

5. キュープロキシ サイドカーに処理可能な数より多くのリクエストが含まれている場合、オートスケーラーによって追加のリクエストを処理する Pod が作成されます。

6. キュープロキシ サイドカーによって、ユーザー コンテナにトラフィックが送信されます。