Autopilot でのリソース リクエスト


このページでは、Google Kubernetes Engine(GKE)Autopilot ワークロードに指定できるリソースの最大リクエスト、最小リクエスト、デフォルトのリクエストと、Autopilot がワークロードの安定性を維持するためにこれらのリクエストを自動的に変更する方法について説明します。

Autopilot リソース リクエストの概要

Autopilot は、ワークロード構成に指定したリソース リクエストを使用して、ワークロードを実行するノードを構成します。Autopilot は、ワークロードが使用するコンピューティング クラスまたはハードウェア構成に基づいて、リソースの最小リクエストと最大リクエストを適用します。一部のコンテナのリクエストを指定していない場合、Autopilot は、コンテナが正常に実行されるようにデフォルト値を割り当てます。

Autopilot クラスタにワークロードをデプロイすると、選択したコンピューティング クラスまたはハードウェア構成(GPU など)で許容される最小値と最大値に対してワークロード構成が GKE により検証されます。リクエストが最小値未満の場合は、Autopilot がワークロード構成を自動的に変更し、リクエストが許容範囲に収まるようにします。リクエストが最大値より大きい場合、Autopilot はワークロードを拒否し、エラー メッセージが表示されます。

次のリストは、リソース リクエストのカテゴリの概要を示します。

  • デフォルトのリソース リクエスト: ワークロードに独自のリクエストを指定しない場合、Autopilot によって追加されます。
  • リソースの最小リクエストと最大リクエスト: Autopilot は、リクエストがこの制限内に収まるように、指定されたリクエストを検証します。リクエストが制限を超えると、Autopilot によってワークロード リクエストが変更されます。
  • ワークロードの分離と期間延長のリクエスト: Autopilot には、互いに分離しているワークロードや GKE が開始した強制排除からの保護を強化した Pod ごとに別々のデフォルト値と最小値があります。
  • DaemonSet のリソース リクエスト: Autopilot では、DaemonSet のコンテナごとに異なるデフォルト値、最小値、最大値があります。

リソースのリクエスト方法

Autopilot では、リソースを Pod 仕様でリクエストします。リクエストできるサポート対象の最小リソースと最大リソースは、Pod が実行されるノードのハードウェア構成によって変わります。特定のハードウェア構成をリクエストする方法については、次のページをご覧ください。

デフォルトのリソース リクエスト

Pod 内の一部のコンテナにリソース リクエストを指定しない場合、Autopilot はデフォルト値を適用します。これらのデフォルト値は、多くの小規模なワークロードに適しています。

さらに、Autopilot は、選択したコンピューティング クラスやハードウェア構成に関係なく、次のデフォルト リソース リクエストを適用します。

  • DaemonSet のコンテナ

    • CPU: 50 mCPU
    • メモリ: 100 MiB
    • エフェメラル ストレージ: 100 MiB
  • その他すべてのコンテナ

    • エフェメラル ストレージ: 1 GiB

Autopilot によるクラスタの制限の詳細については、割り当てと上限をご覧ください。

コンピューティング クラスのデフォルト リクエスト

Autopilot では、コンピューティング クラスで実行される Pod の Pod 仕様で定義されていないリソースには、次のデフォルト値が適用されます。一方のリクエストのみを設定し、もう一方を空白のままにすると、GKE は最小リクエストと最大リクエストのセクションで定義されている CPU とメモリの比率を使用して、欠落しているリクエストを比率に沿う値に設定します。

コンピューティング クラス リソース デフォルト リクエスト
汎用 CPU 0.5 vCPU
メモリ 2 GiB
バランス CPU 0.5 vCPU
メモリ 2 GiB
パフォーマンス CPU
  • C3 マシンシリーズ: 2 vCPU
  • ローカル SSD を使用した C3 マシンシリーズ: 2 vCPU
  • C3D マシンシリーズ: 2 vCPU
  • ローカル SSD を使用した C3D マシンシリーズ: 4 vCPU
  • H3 マシンシリーズ: 80 vCPU
  • C2 マシンシリーズ: 2 vCPU
  • C2D マシンシリーズ: 2 vCPU
  • T2A マシンシリーズ: 2 vCPU
  • T2D マシンシリーズ: 2 vCPU
メモリ
  • C3 マシンシリーズ: 8 GiB
  • ローカル SSD を使用した C3 マシンシリーズ: 8 GiB
  • C3D マシンシリーズ: 8 GiB
  • ローカル SSD を使用した C3D マシンシリーズ: 16 GiB
  • H3 マシンシリーズ: 320 GiB
  • C2 マシンシリーズ: 8 GiB
  • C2D マシンシリーズ: 8 GiB
  • T2A マシンシリーズ: 8 GiB
  • T2D マシンシリーズ: 8 GiB
エフェメラル ストレージ
  • C3 マシンシリーズ: 1 GiB
  • ローカル SSD を使用した C3 マシンシリーズ: 1 GiB
  • C3D マシンシリーズ: 1 GiB
  • ローカル SSD を使用した C3D マシンシリーズ: 1 GiB
  • H3 マシンシリーズ: 1 GiB
  • C2 マシンシリーズ: 1 GiB
  • C2D マシンシリーズ: 1 GiB
  • T2A マシンシリーズ: 1 GiB
  • T2D マシンシリーズ: 1 GiB
スケールアウト CPU 0.5 vCPU
メモリ 2 GiB

他のハードウェア構成のデフォルト リクエスト

Autopilot は、特殊なハードウェア(GPU など)を搭載したノードで実行される Pod の Pod 仕様で定義されていないリソースに次のデフォルト値を適用します。

ハードウェア リソース トータルのデフォルト リクエスト
H100(80GB)GPU
nvidia-h100-80gb
CPU
  • 8 GPU: 200 vCPU
メモリ
  • 8 GPU: 1,400 GiB
エフェメラル ストレージ
  • 8 GPU: 1 GiB
A100(40 GB)GPU
nvidia-tesla-a100
CPU
  • 1 GPU: 9 vCPU
  • 2 GPU: 20 vCPU
  • 4 GPU: 44 vCPU
  • 8 GPU: 92 vCPU
  • 16 GPU: 92 vCPU
メモリ
  • 1 GPU: 60 GiB
  • 2 GPU: 134 GiB
  • 4 GPU: 296 GiB
  • 8 GPU: 618 GiB
  • 16 GPU: 1,250 GiB
A100(80 GB)GPU
nvidia-a100-80gb
CPU
  • 1 GPU: 9 vCPU
  • 2 GPU: 20 vCPU
  • 4 GPU: 44 vCPU
  • 8 GPU: 92 vCPU
メモリ
  • 1 GPU: 134 GiB
  • 2 GPU: 296 GiB
  • 4 GPU: 618 GiB
  • 8 GPU: 1,250 GiB
エフェメラル ストレージ
  • 1 GPU: 1 GiB
  • 2 GPU: 1 GiB
  • 4 GPU: 1 GiB
  • 8 GPU: 1 GiB
L4 GPU
nvidia-l4
CPU
  • 1 GPU: 2 vCPU
  • 2 GPU: 21 vCPU
  • 4 GPU: 45 vCPU
  • 8 GPU: 93 vCPU
メモリ
  • 1 GPU: 7 GiB
  • 2 GPU: 78 GiB
  • 4 GPU: 170 GiB
  • 8 GPU: 355 GiB
T4 GPU
nvidia-tesla-t4
CPU 0.5 vCPU
メモリ 2 GiB

リソースの最小リクエストと最大リクエスト

デプロイ構成でリクエストされるリソースの合計は、Autopilot で許可されるサポート範囲の最小値と最大値の間に入る必要があります。次の条件が適用されます。

  • エフェメラル ストレージ リクエストは、別途指定しない限り、すべてのコンピューティング クラスとハードウェア構成で 10 MiB~10 GiB でなければなりません。大量のボリュームを使用する場合は、汎用のエフェメラル ボリュームを使用することをおすすめします。エフェメラル ストレージと同等の機能とパフォーマンスを提供し、どの GKE ストレージ オプションで使用しても高い汎用性があります。たとえば、pd-balanced を使用する汎用エフェメラル ボリュームの最大サイズは 64 TiB です。
  • DaemonSet Pod の場合、最小リソース リクエストは次のとおりです。

    • バーストをサポートするクラスタ: Pod あたり 1 mCPU、Pod あたり 2 MiB のメモリ、Pod 内のコンテナあたり 10 MiB のエフェメラル ストレージ。
    • バーストをサポートしていないクラスタ: Pod あたり 10 mCPU、Pod あたり 10 MiB のメモリ、Pod 内のコンテナあたり 10 MiB のエフェメラル ストレージ。

    クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。

  • CPU とメモリの比率は、選択したコンピューティング クラスまたはハードウェア構成で許容される範囲内になければなりません。CPU とメモリの比率が許容範囲を超えている場合、Autopilot は小さい方のリソースを自動的に増加させます。たとえば、Scale-Out クラスで実行されている Pod に 1 vCPU と 16 GiB のメモリ(比率 1:16)をリクエストすると、Autopilot は、CPU リクエストを 4 vCPU に増加させ、比率は 1:4 になります。

コンピューティング クラスの最小値と最大値

Autopilot がサポートするコンピューティング クラスごとの CPU とメモリの最小値、最大値と許容される比率を次の表に示します。

コンピューティング クラス CPU とメモリの比率(vCPU:GiB) リソース 最小 最大
汎用 1:1~1:6.5 CPU

この値は、クラスタがバーストをサポートしているかどうかによって異なります。

  • バーストをサポートするクラスタ: 50m CPU
  • バーストをサポートしていないクラスタ: 250m CPU

クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。

30 vCPU
メモリ

この値は、クラスタがバーストをサポートしているかどうかによって異なります。

  • バーストをサポートするクラスタ: 52 MiB
  • バーストをサポートしていないクラスタ: 512 MiB

クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。

110 GiB
バランス 1:1~1:8 CPU 0.25 vCPU

222 vCPU

最小 CPU プラットフォームが選択されている場合:

  • Intel プラットフォーム: 126 vCPU
  • AMD プラットフォーム: 222 vCPU
メモリ 0.5 GiB

851 GiB

最小 CPU プラットフォームが選択されている場合:

  • Intel プラットフォーム: 823 GiB
  • AMD プラットフォーム: 851 GiB
パフォーマンス なし CPU 0.001 vCPU
  • C3 マシンシリーズ: 174 vCPU
  • ローカル SSD を使用した C3 マシンシリーズ: 174 vCPU
  • C3D マシンシリーズ: 358 vCPU
  • ローカル SSD を使用した C3D マシンシリーズ: 358 vCPU
  • H3 マシンシリーズ: 86 vCPU
  • C2 マシンシリーズ: 58 vCPU
  • C2D マシンシリーズ: 110 vCPU
  • T2A マシンシリーズ: 46 vCPU
  • T2D マシンシリーズ: 58 vCPU
メモリ 1 MiB
  • C3 マシンシリーズ: 1,345 GiB
  • ローカル SSD を使用した C3 マシンシリーズ: 670 GiB
  • C3D マシンシリーズ: 2,750 GiB
  • ローカル SSD を使用した C3D マシンシリーズ: 1,375 GiB
  • H3 マシンシリーズ: 330 GiB
  • C2 マシンシリーズ: 218 GiB
  • C2D マシンシリーズ: 835 GiB
  • T2A マシンシリーズ: 172 GiB
  • T2D マシンシリーズ: 218 GiB
エフェメラル ストレージ 10 MiB
  • C3 マシンシリーズ: 250 GiB
  • ローカル SSD を使用した C3 マシンシリーズ: 10,000 GiB
  • C3D マシンシリーズ: 250 GiB
  • ローカル SSD を使用した C3D マシンシリーズ: 10,000 GiB
  • H3 マシンシリーズ: 250 GiB
  • C2 マシンシリーズ: 250 GiB
  • C2D マシンシリーズ: 250 GiB
  • T2A マシンシリーズ: 250 GiB
  • T2D マシンシリーズ: 250 GiB
スケールアウト 1:4 CPU 0.25 vCPU
  • arm64: 43 vCPU
  • amd64: 54 vCPU
メモリ 1 GiB
  • arm64: 172 GiB
  • amd64: 216 GiB

Autopilot Pod でコンピューティング クラスをリクエストする方法については、Autopilot Pod のコンピューティング クラスを選択するをご覧ください。

他のハードウェア構成の最小値と最大値

次の表では、特別なハードウェア(GPU など)を持つノードで実行される Pod の CPU とメモリの最小値、最大値と許容される比率を示します。特に指定されていない限り、バージョン 1.28.6-gke.1369000 以降と 1.29.1-gke.1575000 以降では、サポートされるエフェメラル ストレージの最大値は 122 GiB です。それより前のバージョンでは、サポートされるエフェメラル ストレージの最大値は 10 GiB です。

ハードウェア CPU とメモリの比率(vCPU:GiB) リソース 最小 最大
H100(80GB)GPU
nvidia-h100-80gb
未適用 CPU
  • 8 GPU: 0.001 vCPU
  • 8 GPU: 206 vCPU
メモリ
  • 8 GPU: 1 MiB
  • 8 GPU: 1,795 GiB
エフェメラル ストレージ
  • 8 GPU: 10 MiB
  • 8 GPU: 5,250 GiB
A100(40 GB)GPU
nvidia-tesla-a100
未適用 CPU
  • 1 GPU: 9 vCPU
  • 2 GPU: 20 vCPU
  • 4 GPU: 44 vCPU
  • 8 GPU: 92 vCPU
  • 16 GPU: 92 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPU: 22 vCPU
  • 4 GPU: 46 vCPU
  • 8 GPU: 94 vCPU
  • 16 GPU: 94 vCPU

A100 GPU ノードで実行されるすべての DaemonSet の CPU リクエストの合計は、2 vCPU を超えないようにする必要があります。

メモリ
  • 1 GPU: 60 GiB
  • 2 GPU: 134 GiB
  • 4 GPU: 296 GiB
  • 8 GPU: 618 GiB
  • 16 GPU: 1,250 GiB
  • 1 GPU: 74 GiB
  • 2 GPU: 148 GiB
  • 4 GPU: 310 GiB
  • 8 GPU: 632 GiB
  • 16 GPU: 1,264 GiB

A100 GPU ノードで実行されるすべての DaemonSet のメモリ リクエストの合計は、14 GiB 超えないようにする必要があります。

A100(80 GB)GPU
nvidia-a100-80gb
未適用 CPU
  • 1 GPU: 9 vCPU
  • 2 GPU: 20 vCPU
  • 4 GPU: 44 vCPU
  • 8 GPU: 92 vCPU
  • 1 GPU: 11 vCPU
  • 2 GPU: 22 vCPU
  • 4 GPU: 46 vCPU
  • 8 GPU: 94 vCPU

A100(80GB)GPU ノードで実行されるすべての DaemonSet の CPU リクエストの合計は、2 vCPU を超えないようにする必要があります。

メモリ
  • 1 GPU: 134 GiB
  • 2 GPU: 296 GiB
  • 4 GPU: 618 GiB
  • 8 GPU: 1,250 GiB
  • 1 GPU: 148 GiB
  • 2 GPU: 310 GiB
  • 4 GPU: 632 GiB
  • 8 GPU: 1,264 GiB

A100(80GB)GPU ノードで実行されるすべての DaemonSet のメモリ リクエストの合計は、14 GiB を超えないようにする必要があります。

エフェメラル ストレージ
  • 1 GPU: 512 MiB
  • 2 GPU: 512 MiB
  • 4 GPU: 512 MiB
  • 8 GPU: 512 MiB
  • 1 GPU: 280 GiB
  • 2 GPU: 585 GiB
  • 4 GPU: 1,220 GiB
  • 8 GPU: 2,540 GiB
L4 GPU
nvidia-l4
  • 1 GPU: 1:3.5~1:4
  • 2、4、8 GPU: 未適用
CPU
  • 1 GPU: 2 vCPU
  • 2 GPU: 21 vCPU
  • 4 GPU: 45 vCPU
  • 8 GPU: 93 vCPU
  • 1 GPU: 31 vCPU
  • 2 GPU: 23 vCPU
  • 4 GPU: 47 vCPU
  • 8 GPU: 95 vCPU

L4 GPU ノードで実行されるすべての DaemonSet の CPU リクエストの合計は、2 vCPU を超えないようにする必要があります。

メモリ
  • 1 GPU: 7 GiB
  • 2 GPU: 78 GiB
  • 4 GPU: 170 GiB
  • 8 GPU: 355 GiB
  • 1 GPU: 115 GiB
  • 2 GPU: 86 GiB
  • 4 GPU: 177 GiB
  • 8 GPU: 363 GiB

L4 GPU ノードで実行されるすべての DaemonSet のメモリ リクエストの合計は、14 GiB を超えないようにする必要があります。

T4 GPU
nvidia-tesla-t4
1:1~1:6.25 CPU 0.5 vCPU
  • 1 GPU: 46 vCPU
  • 2 GPUs: 46 vCPU
  • 4 GPUs: 94 vCPU
メモリ 0.5 GiB
  • 1 GPU: 287.5 GiB
  • 2 GPU: 287.5 GiB
  • 4 GPU: 587.5 GiB

Autopilot Pod で GPU をリクエストする方法については、Autopilot に GPU ワークロードをデプロイするをご覧ください。

ワークロードの分離と期間延長のリソース リクエスト

Autopilot を使用すると、次のような方法を使用して Kubernetes のスケジュール設定と強制排除の動作を操作できます。

  • taint と tolerationノードセレクタを使用して、特定の Pod が特定のノードにのみ配置されるようにします。詳細については、GKE でワークロードの分離を構成するをご覧ください。
  • Pod の反アフィニティを使用して、Pod が同じノード上に配置されないようにします。これらのメソッドを使用してスケジューリング動作を制御するワークロードのデフォルトと最小のリソース リクエストは、使用しないワークロードよりも高くなります。
  • アノテーションを使用して、ノードの自動アップグレードとスケールダウン イベントによる強制排除から Pod を最大 7 日間保護します。詳細については、Autopilot Pod の実行時間を延長するをご覧ください。

指定したリクエストが最小値未満の場合、Autopilot の動作は、使用したメソッドに従って次のように変化します。

  • taint、toleration、セレクタ、期間延長の Pod: Autopilot は、Pod のスケジュールを設定するときにリクエストを増やすように Pod を変更します。
  • Pod の反アフィニティ: Autopilot は Pod を拒否し、エラー メッセージが表示されます。

次の表に、デフォルトのリクエストと、指定できる最小のリソース リクエストを示します。構成またはコンピューティング クラスがこのテーブルにない場合、Autopilot は特別な最小値またはデフォルト値を適用しません。

コンピューティング クラス リソース デフォルト 最小
汎用 CPU 0.5 vCPU 0.5 vCPU
メモリ 2 GiB 0.5 GiB
バランス CPU 2 vCPU 1 vCPU
メモリ 8 GiB 4 GiB
スケールアウト CPU 0.5 vCPU 0.5 vCPU
メモリ 2 GiB 2 GiB

初期コンテナ

初期コンテナは連続で実行され、アプリケーション コンテナを開始する前に完了する必要があります。Autopilot 初期コンテナにリソース リクエストを指定しない場合、GKE は各初期コンテナに対して Pod が利用できるトータルのリソースを割り当てます。この動作は GKE Standard では異なります。各初期コンテナは、Pod がスケジュールされているノードで使用可能な未割り当てリソースを使用できます。

アプリケーション コンテナとは異なり、GKE では Autopilot 初期コンテナにリソース リクエストを指定しないことをおすすめします。これにより、各コンテナは Pod で使用可能なすべてのリソースを取得できます。リクエストするリソースがデフォルトより少ない場合は、初期コンテナが制限されます。Autopilot のデフォルトよりも多くのリソースをリクエストすると、Pod が存在する全期間で請求額が増える可能性があります。

Autopilot でリソース制限を設定する

Kubernetes では、Pod 仕様のリソースに requestslimits の両方を設定できます。Pod の動作は、次の表に示すように、limitsrequests と異なるかどうかによって異なります。

値の設定 Autopilot の動作
requestslimits と等しい Pod は Guaranteed QoS クラスを使用します。
requests は設定、limits は未設定

動作は、クラスタがバーストをサポートしているかどうかによって異なります。

  • バースト機能をサポートするクラスタ: Pod は、使用可能なバースト可能な容量までバーストできます。
  • バーストをサポートしていないクラスタ: GKE は limitsrequests に設定します。

クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。

requests は未設定、limits は設定 Autopilot は、requestslimits の値に設定します。これは Kubernetes のデフォルトの動作です。

変更前:


resources:
  limits:
    cpu: "400m"

変更後:


resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"
requestslimits より小さい

動作は、クラスタがバーストをサポートしているかどうかによって異なります。

  • バースト機能をサポートするクラスタ: Pod は、limits で指定された値までバーストできます。
  • バーストをサポートしていないクラスタ: GKE は limitsrequests に設定します。

クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。

requestslimits より大きい Autopilot は、requestslimits の値に設定します。

変更前:


resources:
  requests:
    cpu: "450m"
  limits:
    cpu: "400m"

変更後:


resources:
  requests:
    cpu: "400m"
  limits:
    cpu: "400m"
requests は未設定、limits は未設定

Autopilot は、requests をコンピューティング クラスまたはハードウェア構成のデフォルト値に設定します。

limits の動作は、クラスタがバーストをサポートしているかどうかによって異なります。

  • バーストをサポートするクラスタ: Autopilot は limits を設定しません。
  • バーストをサポートしていないクラスタ: GKE は limitsrequests に設定します。

クラスタがバーストをサポートしているかどうかを確認するには、GKE でのバーストの可用性をご覧ください。

ほとんどの場合、ワークロードに適切なリソース リクエストと同等の上限を設定します。

起動時やトラフィックの増加時など、定常状態よりも一時的に多くのリソースを必要とするワークロードの場合は、リクエストよりも高い上限を設定して Pod をバーストできるようにします。詳細については、GKE で Pod バーストを構成するをご覧ください。

Autopilot での自動リソース管理

ワークロードに指定したリソース リクエストが許可された範囲外の場合、または一部のコンテナ用のリソースをリクエストしない場合、Autopilot は、許可された範囲に適合するようにワークロード構成を変更します。Autopilot は、リクエストが指定されていないコンテナにデフォルト値を適用したうえで、リソース比率とリソースのスケールアップ要件を計算します。

  • リクエストがない: 一部のコンテナでリソースをリクエストしない場合、Autopilot はコンピューティング クラスまたはハードウェア構成のデフォルトのリクエストを適用します。
  • CPU とメモリの比率: Autopilot は、小さい方のリソースをスケールアップして、比率が許容範囲内になるようにします。
  • エフェメラル ストレージ: Autopilot は、各コンテナで必要な最小サイズを満たすようにエフェメラル ストレージ リクエストを変更します。すべてのコンテナにわたるストレージ リクエストの累積値は、最大許容値を超えることはできません。Autopilot は、値が最大値を超えると、リクエストをスケールダウンします。
  • 最小数を下回るリクエスト: 選択したハードウェア構成で許容される最小リソース数よりも少ないリソースをリクエストすると、Autopilot は、少なくとも最小リソース値をリクエストするように Pod を自動的に変更します。

デフォルトでは、Autopilot が最小またはデフォルトのリソース値を満たすようにリソースを自動的にスケーリングすると、GKE は追加の容量を Pod マニフェストの最初のコンテナに割り当てます。GKE バージョン 1.27.2-gke.2200 以降では、Pod マニフェストの annotations フィールドに次のコードを追加して、追加のリソースを特定のコンテナに割り当てるように GKE に指示できます。

autopilot.gke.io/primary-container: "CONTAINER_NAME"

CONTAINER_NAME は、コンテナの名前に置き換えます。

リソースの変更の例

次のシナリオ例では、実行中の Pod とコンテナの要件を満たすように Autopilot がワークロード構成を変更する方法を示します。

単一コンテナで 0.05 vCPU 未満の場合

コンテナ数 元のリクエスト 変更されたリクエスト
1 CPU: 30 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 50 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB

複数のコンテナの合計 CPU が 0.05 vCPU 未満の場合

コンテナ数 元のリクエスト 変更されたリクエスト
1 CPU: 10 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 30 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
2 CPU: 10 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 10 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
3 CPU: 10 mvCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 10 mCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 50 mCPU
メモリ: 1.5 GiB
エフェメラル ストレージ: 30 MiB

複数のコンテナの合計が 0.25 vCPU を超える場合

複数のコンテナの合計リソースが 0.25 vCPU 以上の場合、CPU は 0.25 vCPU の倍数に丸められ、余分な CPU が最初のコンテナに追加されます。この例では、元の累積 CPU は 0.32 vCPU で、合計 0.5 vCPU に変更されます。

コンテナ数 元のリクエスト 変更されたリクエスト
1 CPU: 0.17 vCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 0.35 vCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
2 CPU: 0.08 vCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 0.08 vCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
3 CPU: 0.07 vCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
CPU: 0.07 vCPU
メモリ: 0.5 GiB
エフェメラル ストレージ: 10 MiB
4 初期コンテナで、リソースが未定義 Pod リソースを受信
Pod リソースの合計 CPU: 0.5 vCPU
メモリ: 1.5 GiB
エフェメラル ストレージ: 30 MiB

単一コンテナで、リクエストされた CPU に対してメモリが低すぎる場合

この例では、メモリが CPU の量に対して少なすぎます(最小比は 1 vCPU : 1 GiB)。CPU とメモリの許容最小比は 1:1 です。この値より小さい場合は、メモリ リクエストが引き上げられます。

コンテナ数 元のリクエスト 変更されたリクエスト
1 CPU: 4 vCPU
メモリ: 1 GiB
エフェメラル ストレージ: 10 MiB
CPU: 4 vCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB
Pod リソースの合計 CPU: 4 vCPU
メモリ: 4 GiB
エフェメラル ストレージ: 10 MiB

次のステップ