これは、ドキュメントのアーカイブ バージョンです。無料トライアル期間は 2021 年 9 月 30 日に終了しました。

Anthos Service Mesh を使用して Cloud Run for Anthos を Anthos フリートコンポーネントとしてインストールする方法の詳細については、一般提供版のドキュメントをご覧ください。

利用可能なバージョン

最新
アーカイブ

コンテナランタイムの契約

このページでは、Cloud Run for Anthos のコンテナの主な要件と動作について説明します。

サポートされる言語とイメージ

このページに記載されている制約を遵守していれば、コンテナイメージでは任意のプログラミング言語で書かれたコードを実行でき、任意のベースイメージを使用できます。

コンテナイメージ内の実行可能ファイルは Linux 64 ビット用にコンパイルする必要があります。 Cloud Run for Anthos は特に Linux x86_64 AB 形式をサポートしています。

正しいポートでのリクエストのリッスン

コンテナは、リクエストが送信されるポートで 0.0.0.0 に対するリクエストをリッスンする必要があります。デフォルトでは、リクエストは 8080 に送信されますが、選択したポートにリクエストを送信するように Cloud Run for Anthos を構成できます。

Cloud Run for Anthos コンテナインスタンス内では、PORT 環境変数の値は常にリクエストが送信されるポートを反映します。デフォルトは 8080 です。

Transport Layer Encryption（TLS）

コンテナにトランスポートレイヤセキュリティを直接実装しないでください。TLS は Cloud Run for Anthos for HTTPS and gRPC によって終端され、リクエストは TLS なしで HTTP または gRPC としてコンテナにプロキシされます。

レスポンス

コンテナインスタンスは、コンテナインスタンスの起動時間を含む、リクエストを受信した後、リクエストタイムアウト設定で指定された時間内にレスポンスを送信する必要があります。それ以外の場合は、リクエストが終了し、504 エラーが返されます。

環境変数

次の環境変数が実行中のコンテナに自動的に追加されます。

名前	説明	例
`PORT`	HTTP サーバーでリッスンする必要があるポート。	`8080`
`K_SERVICE`	実行されている Cloud Run for Anthos サービスの名前。	`hello-world`
`K_REVISION`	実行されている Cloud Run for Anthos リビジョンの名前。	`hello-world.1`
`K_CONFIGURATION`	リビジョンを作成した Cloud Run for Anthos 構成の名前。	`hello-world`

ファイルシステムへのアクセス

コンテナのファイルシステムは書き込み可能で、次の動作の対象です。

これはインメモリファイルシステムであるため、書き込みにはコンテナインスタンスのメモリが使用されます。
コンテナインスタンスが停止すると、ファイルシステムに書き込まれたデータは保持されません。

コンテナインスタンスのライフサイクル

受信リクエストに応じて、サービスは特定の数のコンテナインスタンスに自動的にスケーリングされ、各インスタンスでデプロイされたコンテナイメージが実行されます。

リビジョンがトラフィックを受信しない場合、構成されたコンテナインスタンスの最小数にスケールインされます（デフォルトはゼロ）。

起動

コンテナインスタンスは起動後 4 分以内にリクエストをリッスンする必要があります。このスタートアップ時間には、コンテナインスタンスに CPU が割り当てられます。

コンピューティングはリクエストの範囲です

起動後は、リクエストの範囲内でのみ計算できると想定すべきです。コンテナインスタンスがリクエストを処理していない場合、CPU が割り当てられません。

シャットダウン

コンテナインスタンスは、いつでもシャットダウンできます。

コンテナインスタンスをシャットダウンする必要がある場合、新しい受信リクエストは他のインスタンスにルーティングされ、現在処理されているリクエストの処理に時間がかかります。コンテナインスタンスは、（SIGKILL シグナルを使用して）シャットダウンする 10 秒前の開始を示す SIGTERM シグナルを受信します。この期間中に、コンテナインスタンスに CPU が割り当てられ、課金されます。コンテナインスタンスが SIGTERM シグナルをキャッチしない場合は、直ちにシャットダウンされます。

コンテナインスタンスの最小数の構成でコンテナインスタンスをアイドル状態にする必要がある場合を除き、15 分以上アイドル状態になることはありません。

コンテナインスタンスリソース

コンテナインスタンスのリソースリクエストは、GKE クラスタのノードでスケジュールされます。各ノードは、GKE クラスタで使用できるコンピューティングリソースの合計を共有します。

したがって、Cloud Run for Anthos サービスで使用できるコンピューティングリソースの量は、そのノードで使用可能なリソースの量によってのみ制限されます。リクエストのコンピューティングリソースについて学習する。

たとえば、コンテナに 512MiB のメモリを割り当て、そのコンテナが 8 GiB のメモリを持つノードで唯一の Pod で実行されている場合、そのコンテナはより多くの RAM の使用を試行できます。

CPU

デフォルトでは、キュープロキシサイドカーは 25 milliCPU を予約しており、Cloud Run for Anthos サービスで使用できる vCPU の量に制限はありません。キュープロキシのリソース消費量は、キューに入れるリクエストの数とリクエストのサイズによって異なります。

vCPU は、可変 CPU プラットフォーム上の単一ハードウェアハイパースレッドのおおよその CPU 時間を提供するために、基盤となるハードウェアを抽象化して実装されています。コンテナインスタンスは複数のコアで同時に実行される可能性があります。vCPU はコンテナインスタンスの起動時とリクエストの処理時にのみ割り当てられます。それ以外の場合はスロットルされます。

別の vCPU 値を割り当てるには、CPU の割り当てに関するドキュメントをご覧ください。

メモリ

デフォルトでは、キュープロキシサイドカーはメモリを予約しません。また、Cloud Run for Anthos サービスが使用できるメモリ量に制限はありません。必要に応じて、Cloud Run for Anthos サービスのメモリ上限を構成できます。GKE がメモリを処理する方法については、割り当て可能なメモリと CPU リソースをご覧ください。

メモリの一般的な使用方法は次のとおりです。

サービスを実行するためにメモリに読み込まれるコード
ファイルシステムへの書き込み
nginx サーバーなどのコンテナ内で実行する別のプロセス
PHP の OpCache などのメモリ内キャッシュシステム
リクエストごとのメモリ使用量

同時実行

デフォルトでは、Cloud Run for Anthos コンテナインスタンスは複数の同時実行に設定されています。これにより、各コンテナインスタンスで同時に複数のリクエストを受信できます。同時実行の設定によって、これを変更できます。

コンテナインスタンスサンドボックス

Cloud Run for Anthos ではコンテナサンドボックスを使用しません。

コンテナインスタンスメタデータサーバー

Cloud Run for Anthos コンテナインスタンスは、プロジェクト ID、リージョン、インスタンス ID、サービスアカウントなど、コンテナインスタンスの詳細を取得するためのメタデータサーバーを公開します。

メタデータサーバーからこのデータにアクセスするには、Metadata-Flavor: Google ヘッダーを持つ http://metadata.google.internal/ エンドポイントへの単純な HTTP リクエストを使用します。クライアントライブラリは必要ありません。詳細については、メタデータの取得をご覧ください。

次の表に、使用可能なメタデータサーバー情報の一部を示します。

パス	説明
`/computeMetadata/v1/project/project-id`	この Cloud Run for Anthos サービスのプロジェクト ID
`/computeMetadata/v1/instance/region`	この Cloud Run for Anthos サービスのリージョン
`/computeMetadata/v1/instance/id`	コンテナインスタンスの一意の識別子（ログでも使用可能）。
`/computeMetadata/v1/instance/service-accounts/default/token`	この Cloud Run for Anthos サービスのランタイムサービスアカウントのトークンを生成します。

コンテナ ランタイムの契約