このドキュメントは、フリートと Anthos Service Mesh を使用する Knative serving の最新バージョンを対象としています。詳細

過去のバージョン（Cloud Run for Anthos）はアーカイブされていますが、既存のユーザーはドキュメントを引き続きご利用いただけます。

利用可能なバージョン

最新
アーカイブ

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

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

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

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

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

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

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

Knative serving コンテナインスタンス内では、リクエスト送信先ポートが PORT 環境変数の値に常に反映されます。デフォルトでは 8080 に設定されます。

Transport Layer Encryption（TLS）

コンテナに Transport Layer Security を直接実装しないでください。TLS は HTTPS および gRPC 対応の Knative serving によって終了し、リクエストは TLS なしで HTTP または gRPC としてコンテナにプロキシされます。

レスポンス

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

環境変数

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

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

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

コンテナのファイルシステムは書き込み可能で、次の動作の影響を受けます。

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

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

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

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

起動

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

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

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

シャットダウン

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

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

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

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

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

したがって、Knative serving サービスで使用可能なコンピューティングリソースの量は、そのノードで使用可能なリソースの量によって制限されます。詳しくは、リクエストのコンピューティングリソースをご覧ください。

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

CPU

デフォルトでは、キュープロキシサイドカーは 25 milliCPU を予約します。Knative serving サービスで使用できる vCPU の量に上限はありません。キュープロキシのリソース使用量は、キューに追加されるリクエスト数とリクエストのサイズによって異なります。

vCPU は、基盤となるハードウェアを抽象化して実装し、利用可能な CPU プラットフォームに対して単一ハードウェアのハイパースレッドとほぼ同等の CPU 時間を提供します。コンテナインスタンスは、複数のコアで同時に実行できます。vCPU は、コンテナインスタンスの起動とリクエストの処理中にのみ割り当てられます。それ以外の場合は、スロットリングされます。

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

メモリ

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

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

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

同時実行

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

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

Knative serving ではコンテナサンドボックスを使用しません。

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

Knative serving コンテナインスタンスは、プロジェクト ID、リージョン、インスタンス ID、サービスアカウントなど、コンテナインスタンスに関する詳細情報を取得するために使用できるメタデータサーバーを公開します。

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

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

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

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