このページでは、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 サービスのランタイム サービス アカウント用にトークンを生成します。 |