GKE Standard ノードサイズを計画する

このページでは、Google Kubernetes Engine（GKE）Standard ノードプールのノードサイズを計画して、ワークロードの中断やリソース不足による終了のリスクを低減する方法について説明します。GKE Autopilot では Google がノードを管理するため、この計画は必要ありません。

適切なサイズのノードのメリット

アクティビティの急増に対処するために、ワークロードに合わせてノードのサイズを適切に設定することには、次のようなメリットがあります。

  • リソース不足によるエビクションのリスクが低減するため、ワークロードの信頼性が向上します。
  • トラフィックの多い時間帯にワークロードをスケーリングするスケーラビリティが改善されます。
  • ノードがニーズに対して大きくなりすぎてリソースが無駄になる可能性がなくなり、コストが低減されます。

ノード割り当て可能リソース

GKE ノードでは、ノードをクラスタの一部として機能させるシステム コンポーネントが実行されます。こうしたコンポーネントにより、CPU やメモリなどのノードリソースが使用されます。基盤となる Compute Engine 仮想マシン（VM）のサイズに基づくノードの合計リソースと、GKE ワークロードで使用可能なリクエスト対象のリソースが異なる場合があります。この違いは、システム機能とノードの信頼性確保のために、事前に定義された量のリソースを GKE が予約しているため生じます。GKE がシステム リソース用に予約するディスク容量は、ノードイメージによって異なります。ワークロードに使用できる残りのリソースは、割り当て可能なリソースと呼ばれます。

マニフェストで Pod を定義する際、Pod 仕様には、リソースのリクエストと上限を指定できます。GKE が Pod をノードに配置すると、Pod は指定されたリソースをノード上の割り当て可能なリソースからリクエストします。ノードプール内のノードのサイズを計画する場合は、ワークロードが正しく機能するために必要なリソースの数を検討する必要があります。

ノードの割り当て可能なリソースを確認する

1 つの既存ノードで割り当て可能なリソースを確認するには、次のコマンドを実行します。

kubectl get node NODE_NAME \
    -o=yaml | grep -A 7 -B 7 capacity

NODE_NAME は、ノードの名前に置き換えます。

出力は次のようになります。

allocatable:
  attachable-volumes-gce-pd: "127"
  cpu: 3920m
  ephemeral-storage: "47060071478"
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 13498416Ki
  pods: "110"
capacity:
  attachable-volumes-gce-pd: "127"
  cpu: "4"
  ephemeral-storage: 98831908Ki
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 16393264Ki
  pods: "110"

この出力で、allocatable セクションの値はノード上に割り当て可能なリソースです。capacity セクションの値はノード上のリソースの合計です。エフェメラル ストレージの単位はバイトです。

GKE のリソース予約

GKE は、ノードで使用可能なリソースの合計サイズに基づいて、ノードで特定の量のメモリリソースと CPU リソースを予約します。マシンタイプが大きいほど実行されるコンテナと Pod が多くなるため、大規模なマシンほど GKE が予約するリソースの量は増加します。また、Windows Server ノードは、Windows OS の実行とコンテナで実行できない Windows Server コンポーネントのために、同等の Linux ノードより多くのリソースを必要とします。

メモリと CPU の予約

以降のセクションでは、マシンタイプに基づくデフォルトのメモリと CPU の予約について説明します。

メモリの予約

メモリリソースについては、GKE が次のように予約します。

  • メモリが 1 GiB 未満のマシンの 255 MiB のメモリ
  • 最初の 4 GiB のメモリの 25%
  • 次の 4 GiB のメモリの 20%（最大 8 GiB）
  • 次の 8 GiB のメモリの 10%（最大 16 GiB）
  • 次の 112 GiB のメモリの 6%（最大 128 GiB）
  • 128 GiB を超えるメモリの 2%

また、GKE は Pod のエビクションに対処するために各ノードに 100 MiB のメモリを追加で予約します。

CPU の予約

CPU リソースについては、GKE が次のように予約します。

  • 最初のコアの 6%
  • 次のコアの 1％（最大 2 コア）
  • 次の 2 コアの 0.5%（最大 4 コア）
  • 4 コアを超えるコアの 0.25%

共有コア E2 マシンタイプの場合、GKE は合計 1,060 ミリコアを予約します。

ローカル エフェメラル ストレージの予約

GKE には、ノードのブートディスクやローカル SSD など、ローカルにアタッチされたデバイスを基盤とするローカル エフェメラル ストレージを備えたノードが用意されています。エフェメラル ストレージには可用性の保証がなく、ノードに障害が発生して削除されるとエフェメラル ストレージ内のデータが失われる可能性があります。

GKE は、Pod のエビクション時に使用する kubelet やノード上で動作している他のシステム コンポーネントのために、ノードの合計エフェメラル ストレージの一部を単一のファイル システムとして予約します。残りのエフェメラル ストレージは、Pod に割り当ててログなどの目的に使用できます。Pod でエフェメラル ストレージのリクエストと上限を指定する方法については、ローカル エフェメラル ストレージをご覧ください。

GKE は、ローカル エフェメラル ストレージの予約を次のように計算します。

EVICTION_THRESHOLD + SYSTEM_RESERVATION

実際の値は、ストレージを構成するデバイスのサイズとタイプによって変わります。

ノード ブートディスクを基盤とする一時ストレージ

デフォルトでは、一時ストレージはノード ブートディスクによりバックアップされます。この場合、GKE はエビクションのしきい値を次のように決定します。

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

エビクションのしきい値は、常にブートディスクの総容量の 10% です。

GKE はシステム予約の値を次のように決定します。

SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)

システム予約量は、以下のうち最も少ない値になります。

  • ブートディスク容量の 50%
  • ブートディスク容量の 35% + 6 GiB
  • 100 GiB

たとえば、ブートディスクが 300 GiB の場合は、次の値になります。

  • 容量の 50%: 150 GiB
  • 容量の 35% + 6 GiB: 111 GiB
  • 100 GiB

GKE は、以下のように予約します。

  • システム予約: 100 GiB（最小値）
  • エビクションのしきい値: 30 GiB

予約されるエフェメラル ストレージの合計は、130 GiB です。残りの容量（170 GiB）は、割り当て可能なエフェメラル ストレージになります。

ローカル SSD に基づく一時ストレージ

エフェメラル ストレージがローカル SSD を基盤とする場合、GKE は、エビクションのしきい値を次のように計算します。

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GB

この計算で、SSD_NUMBER はアタッチされているローカル SSD の数です。すべてのローカル SSD のサイズは 375 GB であるため、エビクションのしきい値は総エフェメラル ストレージ容量の 10% です。

GKE は、アタッチされている SSD の数に応じて、次のようにシステム予約を計算します。

ローカル SSD の数 システム予約（GiB）
1 50 GiB
2 75 GiB
3 以上 100 GiB

リソースの予約を使用してノードサイズを計画する

  1. デプロイ時と負荷がかかったときのワークロードのリソース要件を検討します。これには、ワークロードのリクエストと計画された上限、スケールアップに対応するためのオーバーヘッドが含まれます。

  2. ワークロードを実行するために、少数の大規模なノードが必要か、多数の小規模なノードが必要かを検討します。

    • 少数の大規模なノードは、高可用性を必要としないリソースを大量に消費するワークロードに適しています。スケールダウンが発生するとより多くの Pod をエビクションする必要が生じるため、ノードの自動スケーリングでは、そのスピードが損なわれます。
    • 多数の小規模なノードは、リソースを大量に消費しない高可用性ワークロードに適しています。スケールダウンが発生すると、エビクションする必要がある Pod が比較的少なくなるため、ノードの自動スケーリングは、より高速になります。

  3. Compute Engine マシン ファミリーの比較ガイドを使用して、ノードに必要なマシンシリーズとファミリーを決定します。

  4. ワークロードのエフェメラル ストレージの要件を検討します。ノードのブートディスクは十分ですか？ローカル SSD が必要ですか？

  5. 前のセクションの情報を使用して、選択したマシンタイプで割り当て可能なリソースを計算します。これを必要なリソースやオーバーヘッドと比較してください。

    • 選択したマシンタイプが大きすぎる場合は、余分なリソースに課金されないようにより小規模なマシンを検討します。
    • 選択したマシンタイプが小さすぎる場合は、ワークロード中断のリスクを低減させるためにより大規模なマシンを検討します。

次のステップ