この情報は、次のようなタイプのユーザーに有用です。
- Cloud Run for Anthos の使用を開始するユーザー。
- GKE クラスタの実行経験があるオペレータ。
- Cloud Run for Anthos と Kubernetes クラスタを統合して、より優れたアプリケーションを設計したり、Cloud Run for Anthos アプリケーションを構成したりする必要があるアプリケーション デベロッパー。
デフォルト インストールのコンポーネント
Cloud Run for Anthos を Google Kubernetes Engine クラスタのアドオンとしてインストールすると、knative-serving と gke-system の名前空間が自動的に作成されます。次のコンポーネントは、これらの名前空間のいずれかにデプロイされます。
knative-serving名前空間で実行されるコンポーネント:- アクティベーター: Pod がゼロにスケールインされるか、リビジョンに送信されるリクエストで過負荷になると、アクティベーターはリクエストを一時的にキューし、オートスケーラーに送信します。オートスケーラーによって報告された指標と使用可能な Pod に基づいてリビジョンがスケーリングされると、キュー内のリクエストがそのリビジョンに転送されます。アクティベーターはデータプレーン コンポーネントです。データプレーン コンポーネントは、ユーザー トラフィックを転送するすべての機能とプロセスを管理します。
- オートスケーラー: アクティベーターとリクエストの同時実行制限を適用するデータプレーン コンポーネントであるキュープロキシ サイドカー コンテナから、指標を集計して処理します。オートスケーラーは、リビジョンの同時実行数を計算し、目的の Pod 数に基づいてデプロイのサイズを調整します。リビジョンで Pod が使用可能な場合、オートスケーラーはコントロール プレーン コンポーネントになります。それ以外の場合は、Pod をゼロにスケールインすると、オートスケーラーはデータプレーン コンポーネントになります。
- コントローラ: オートスケーラーとサービス オブジェクトの子リソースを作成および更新します。コントローラはコントロール プレーン コンポーネントです。コントロール プレーン コンポーネントは、ユーザー トラフィックのリクエストパスを確立するすべての機能とプロセスを管理します。
- Webhook: デフォルト値の設定、一貫性のないオブジェクトや無効なオブジェクトの拒否、および Cloud Run for Anthos リソースに対する Kubernetes API 呼び出しの検証と変更を行います。Webhook はコントロール プレーン コンポーネントです。
gke-system名前空間で実行されるコンポーネント:- クラスタ ローカル ゲートウェイ: ある Cloud Run for Anthos から別の Cloud Run for Anthos への内部トラフィックを処理するデータプレーンのロードバランサ。クラスタ ローカル ゲートウェイは、GKE クラスタ内からのみアクセスできます。個人情報や内部プロセスが誤って公開されることを防ぐために、外部ドメインの登録は行われません。
- Istio Ingress Gateway: クラスタの外部からのトラフィック（外部と内部のいずれかのネットワークからのトラフィックを含む）の受信と処理を担当するデータプレーン内のロードバランサ。
- Istio パイロット: 正しいエンドポイントで HTTP リクエストが処理されるように、クラスタ ローカル ゲートウェイと Istio Ingress ゲートウェイを構成します。Istio Pilot は、コントロール プレーン コンポーネントです。詳しくは、Istio Pilot をご覧ください。
Cloud Run for Anthos コンポーネントは、GKE コントロール プレーン クラスタの更新の際に自動的に更新されます。詳しくは、利用可能な GKE バージョンをご覧ください。
クラスタ リソースの使用量
Cloud Run for Anthos の初期インストールには、クラスタに対しておおよそ 1.5 の仮想 CPU と 1 GB のメモリが必要です。クラスタ内のノード数は、Cloud Run for Anthos のインストールに必要な容量とメモリ要件に影響しません。
1 つのアクティベーターあたり、最大 1,000 milliCPU および 600 MiB RAM でリクエストの消費が可能です。既存のアクティベーターで受信リクエスト数を処理できない場合は、追加の Activator が提供されます。これには、300 milliCPU および 60 MiB RAM の予約が必要になります。
Cloud Run for Anthos サービスが作成したすべての Pod によって、リクエストの同時実行制限を適用するキュープロキシ サイドカーが作成されます。キュープロキシによって 25 milliCPU が予約されますが、メモリは予約されません。キュープロキシの使用量は、キューに追加されるリクエスト数とリクエストのサイズによって異なります。CPU とメモリリソースに制限はありません。
サービスの作成
Cloud Run for Anthos によって、サービス、リビジョン、構成、ルートといった一連のカスタム リソース定義（CRD）が定義され、Kubernetes が拡張されます。CRD により、クラスタ上のアプリケーションの動作が定義および制御されます。
- Cloud Run for Anthos サービスは、Cloud Run for Anthos によって定義される最上位のカスタム リソースです。これは、ワークロードのライフサイクル全体を管理する単一のアプリケーションです。サービスにおいて、サービスの更新ごとに、ルート、構成、新しいリビジョンがアプリに含まれていることが確認されます。
- リビジョンは、コードと構成に関するポイントインタイムかつ不変のスナップショットです。
- Configuration には、最新のリビジョンの現在の構成が保持され、過去のすべてのリビジョンの履歴が記録されます。構成を変更すると、新しいリビジョンが作成されます。
- Route では、HTTP エンドポイントが定義され、エンドポイントがリクエストの転送先となる 1 つ以上のリビジョンに関連付けられます。
ユーザーが Cloud Run for Anthos サービスを作成すると、次の処理が行われます。
Cloud Run for Anthos Service オブジェクトによって、次が定義されます。
- リビジョンの提供方法に関する構成。
- このバージョンのサービスに対する不変のリビジョン。
- リビジョンに指定されたトラフィックの割り当てを管理するためのルート。
ルート オブジェクトによって、VirtualService が作成されます。VirtualService オブジェクトによって、ゲートウェイ トラフィックが正しいリビジョンにルーティングされるように、Ingress ゲートウェイとクラスタ ローカル ゲートウェイが構成されます。
リビジョン オブジェクトによって、コントロール プレーン コンポーネント（Kubernetes Service オブジェクトと Deployment オブジェクト）が作成されます。
ネットワーク構成によって、アプリのアクティベーター、オートスケーラー、ロードバランサが接続されます。
リクエスト処理
次の図は、サンプルの Google Kubernetes Engine クラスタ上で、Cloud Run for Anthos のデータプレーン コンポーネントを経由するユーザー トラフィックの予想されるリクエストパスの概要を示しています。
次の図は、上の図を展開した、ユーザー トラフィックのリクエストパスの詳細を示しています。さらに詳細を次に示します。
Cloud Run for Anthos のリクエストパスの場合:
トラフィックは、以下を経由します。
- クラスタ外部からのトラフィック用の Ingress ゲートウェイ
- クラスタ内部のトラフィック用のクラスタ ローカル ゲートウェイ
VirtualService コンポーネントは、トラフィック ルーティング ルールを指定します。VirtualService コンポーネントによって、ユーザー トラフィックが正しいリビジョンにルーティングされるように、ゲートウェイが構成されます。
コントロール プレーン コンポーネントである Kubernetes Service は、トラフィックを処理する Pod の可用性に応じて、リクエストパスの次のステップを決定します。
リビジョンに Pod が存在しない場合:
- Pod のスケールアップのために、アクティベーターによって、受信したリクエストが一時的にキューに入れられ、指標がオートスケーラーに push されます。
- オートスケーラーによって、Deployment 内の Pod が望ましい状態までスケーリングされます。
- Deployment により、追加のリクエストを受信できるように追加の Pod が作成されます。
- アクティベーターによって、キュープロキシ サイドカーに対するリクエストが再試行されます。
サービスがスケールアウトされている（Pod が使用可能な）場合、Kubernetes Service によってキュープロキシ サイドカーにリクエストが送信されます。
キュープロキシ サイドカーでは、コンテナが一度に処理できるリクエスト キュー パラメータ（シングル スレッドまたはマルチスレッドのリクエスト）が適用されます。
キュープロキシ サイドカーに処理可能な数より多くのリクエストが含まれている場合、オートスケーラーによって追加のリクエストを処理する Pod が作成されます。
キュープロキシ サイドカーによって、ユーザー コンテナにトラフィックが送信されます。