すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:リソース予約ポリシー

最終更新日:Mar 12, 2025

Container Service for Kubernetes (ACK) は、Kubernetes コンポーネントとシステムプロセスを実行するために、特定量のノードリソースを予約します。これにより、オペレーティングシステムカーネル、システムサービス、および Kubernetes デーモンが想定どおりに実行できるようになります。その結果、ノードの割り当て可能リソースの量は、ノードのリソース容量とは異なります。ACK はデフォルトのリソース予約ポリシーを提供します。 kubelet を構成してリソース予約をカスタマイズすることもできます。

制限

Kubernetes バージョンが 1.20 以降のクラスターに対してのみ、カスタムリソース予約ポリシーを作成できます。 ACK クラスタをアップグレードするには、「ACK クラスタを手動でアップグレードする」をご参照ください。

影響

カスタム リソース予約の影響

リソース予約をカスタマイズする方法の詳細については、「ノードプールの kubelet パラメータをカスタマイズする」をご参照ください。カスタムリソース予約ポリシーは、ノードプール内の既存のノードと、ノードプールに新しく追加されたノードの両方に適用されます。新しいノードには、スケールアウト操作によって追加されたノードと、ACK コンソールの [ノードプール] ページで [既存のノードを追加] を選択して追加された Elastic Compute Service (ECS) ノードが含まれます。

重要
  • CLI を使用して kubelet ConfigMap を手動で変更しないでください。構成の競合が存在する場合、ノードプール O&M アクティビティ中に例外が発生する可能性があります。

  • ノードの予約リソースの量を変更すると、ノードの割り当て可能リソースの量が減少する可能性があります。ノードのリソース使用率が高い場合、ノードで実行されているポッドがエビクションされる可能性があります。リソース予約を適切に構成してください。

デフォルトのリソース予約の影響

ACK は、リソース予約のデフォルト値を反復処理する場合があります。反復後にノードプールのノード構成を更新すると、新しいリソース予約ポリシーがノードプール内のノードに自動的に適用されます。たとえば、Kubernetes バージョンを更新したり、ノードプールを更新したり、ノードプールの kubelet パラメータを変更したりすると、新しいリソース予約ポリシーが自動的に適用されます。 O&M 操作を実行しない場合、ビジネスの安定性に影響を与える場合に備えて、新しいリソース予約ポリシーはノードプール内の既存のノードには適用されません。

ノードの割り当て可能リソースを表示する

次のコマンドを実行して、ノードのリソース容量と割り当て可能リソースを表示します。

kubectl describe node [NODE_NAME] | grep Allocatable -B 7 -A 6

予想される出力:

Capacity:
  cpu:                4                 # ノードの CPU コアの総数
  ephemeral-storage:  123722704Ki       # ノードの一時ストレージの総量。単位: KiB。
  enormouspages-1Gi:      0
  enormouspages-2Mi:      0
  memory:             7925980Ki         # ノードのメモリの総量。単位: KiB。
  pods:               64
Allocatable:
  cpu:                3900m             # ノード上の割り当て可能な CPU コアの総数
  ephemeral-storage:  114022843818      # ノード上の割り当て可能な一時ストレージの量。単位: バイト。
  enormouspages-1Gi:      0
  enormouspages-2Mi:      0
  memory:             5824732Ki         # ノード上の割り当て可能なメモリの量。単位: KiB。
  pods:               64

ノードの割り当て可能リソースを計算する

次の式に基づいて、ノードの割り当て可能リソースを計算できます: 割り当て可能リソース = リソース容量 - 予約リソース - エビクションしきい値

式の説明:

  • ノードリソースをクエリするために使用されるコマンドの出力の Capacity パラメータは、ノードのリソース容量を示します。

  • リソース予約の詳細については、このトピックの「リソース予約ポリシー」セクションをご参照ください。

  • エビクションしきい値の詳細については、「ノードプレッシャーエビクション」をご参照ください。

リソース予約ポリシー

リソース予約ポリシーを構成する際には、次の項目に注意してください。

  • 一般に、仕様の高い ECS ノードは、より多くのポッドをホストできます。ノードのパフォーマンスを確保するために、ACK は Kubernetes コンポーネントにより多くのリソースを予約します。

  • Windows ノードでは、Windows オペレーティングシステムと Windows Server コンポーネントを実行するために追加のリソースが必要です。したがって、Windows ノードは通常、Linux ノードよりも多くのリソースを予約します。詳細については、「Windows ノードプールを作成する」をご参照ください。

ACK は、異なる間隔の CPU リソースとメモリリソースに基づいて、予約リソースの量を計算します。ノードのリソース容量は、すべての間隔の予約リソースの合計に等しくなります。予約 CPU リソースとメモリリソースの量を削減するために、リソース予約ポリシーアルゴリズムは、Kubernetes 1.28 を実行する ACK クラスタ向けに最適化されています。クラスターを更新することをお勧めします。詳細については、「ACK クラスタを手動でアップグレードする」をご参照ください。

予約リソースは、kubeReserved と systemReserved の 2 つのカテゴリに分類されます。 kubeReserved リソースは Kubernetes コンポーネント用に予約されており、systemReserved リソースはシステムプロセス用に予約されています。各カテゴリは、予約リソース全体の 50% を占めます。たとえば、4 つの CPU コアを持つノードでは、Kubernetes 1.28 以降を実行する ACK クラスタは合計 80 ミリコアの CPU リソースを予約し、kubeReserved リソースと systemReserved リソースはそれぞれ 40 ミリコアを占めます。対照的に、Kubernetes バージョン 1.20 から 1.28 (両端を含む) を実行する ACK クラスタは、合計 100 ミリコアの CPU リソースを予約し、kubeReserved リソースと systemReserved リソースはそれぞれ 50 ミリコアを占めます。

CPU リソースを予約するためのポリシー

Kubernetes 1.28 以降

次の図は、計算ノードの予約 CPU リソースの総量を示しています。

ノードが 32 個の CPU コアを提供する場合、予約される CPU リソースの総量は次の式に基づいて計算されます。

1000 × 6% + 1000 × 1% + 1000 × 2 × 0.5% + (32000 - 4000) × 0.25% = 150 ミリコア

Kubernetes 1.20 から 1.28 (両端を含む)

次の図は、計算ノードの予約 CPU リソースの総量を示しています。

ノードが 32 個の CPU コアを提供する場合、予約される CPU リソースの総量は次の式に基づいて計算されます。

100 + (32,000 - 4,000) × 2.5%= 800 ミリコア

メモリを予約するためのポリシー

Kubernetes 1.28 以降

計算ノードの予約メモリリソースの総量は、次の式に基づいて計算されます: 予約メモリリソース = min(11 × ($max_num_pods) + 255, ノードメモリ × 25%)。予約メモリリソースの総量は、11 × ($max_num_pods) + 255ノードメモリ × 25% の小さい方の値です。

  • $max_num_pods: ノードで実行できるポッドの最大数。

    説明

    ノードあたりの最大ポッド容量の計算方法は、クラスターのネットワークプラグインによって異なります。詳細な説明と式については、「ポッドの最大数」をご参照ください。

    ACK コンソール にログインし、ノード ページでノードあたりのポッドの最大数を確認できます。
    • Terway: ノードあたりのポッドクォータ = 最大コンテナネットワークポッド + ホストネットワークポッド

    • Flannel: クラスター作成中に値を手動で構成します。

  • ノードメモリ: システムの実際に使用可能なメモリリソース。単位: MiB。

    各インスタンスタイプで定義されているメモリサイズは合計メモリサイズであり、システムによって占有されているメモリの量を含みます。その結果、インスタンスで使用可能なメモリのサイズは、インスタンスタイプで定義されているメモリサイズよりも小さくなります。詳細については、「購入したインスタンスのメモリサイズがインスタンスタイプで定義されているメモリサイズと異なるのはなぜですか?

たとえば、クラスターはマルチ IP 共有 ENI モードで Terway を使用し、ノードのインスタンスタイプは 256 GiB のメモリを持つ ecs.g7.16xlarge です。この場合、ノードで実行できるポッドの最大数は、次の式に基づいて計算されます: (8 - 1) × 30 + 3 = 213。予約メモリリソースの総量は、次の式に基づいて計算されます: 予約メモリリソース = min(11 × (210 + 3) + 255, 256 × 1,024 × 25%) = 2,598 MiB

Kubernetes 1.20 から 1.28 (両端を含む)

次の図は、計算ノードの予約メモリリソースの総量を示しています。

ノードが 256 GiB のメモリを提供する場合、予約されるメモリリソースの総量は次の式に基づいて計算されます。

4 × 25% + (8 - 4) × 20% + (16 - 8) × 10% + (128 - 16) × 6% + (256 - 128) × 2% = 11.88 GiB

ACK ノードのデフォルトリソース予約の例

説明

ECS インスタンスタイプの詳細については、「インスタンスファミリの概要」をご参照ください。

ノードリソース容量

予約リソース (Kubernetes 1.28 以降)

予約リソース (Kubernetes 1.20 から 1.28 (両端を含む))

インスタンスタイプ

CPU (単位: コア)

メモリ

(単位: GiB)

ノード上のポッドの最大数

この例では、クラスターはマルチ IP 共有 ENI モードで Terway を使用しています。

CPU

(単位: ミリコア)

メモリ

(単位: MiB)

CPU (単位: ミリコア)

メモリ (単位: MiB)

ECS c7

2

4

15

70

420

100

1,024

4

8

48

80

783

100

1,843

8

16

48

90

783

200

2,662

16

32

213

110

2,598

400

3,645

32

64

213

150

2,598

800

5,611

64

128

213

230

2,598

1,600

9,543

128

256

423

390

4,908

2,400

12,164

ECS ebmc7a

256

512

453

710

5,238

3,040

17,407

FAQ

ノードの CPU とメモリの総リソースを表示するにはどうすればよいですか?

CPU

次のコマンドを実行して、ノードの CPU コアの総数を表示します。

cat /proc/cpuinfo | grep processor

予想される出力:

processor       : 0
processor       : 1
processor       : 2
processor       : 3

メモリ

次のコマンドを実行して、ノードのメモリの総量を表示します。

cat /proc/meminfo | grep MemTotal

予想される出力:

MemTotal:        7660952 kB

関連情報

  • リソース予約とエビクションしきい値をカスタマイズする方法と関連する使用上の注意の詳細については、「ノードプールの kubelet パラメータをカスタマイズする」をご参照ください。

  • 割り当て可能リソースの量に基づいて、アプリケーションポッドのリソースリクエストを構成できます。ノード上のすべてのアプリケーションポッドのリソースリクエストの合計は、ノード上の割り当て可能リソースの量を超えることはできません。そうでない場合、リソース不足のためにポッドのスケジューリングが失敗します。 ACK は、Kubernetes ネイティブワークロード用に リソースプロファイル を作成して、履歴リソース使用量データに基づいてリソースリクエストを構成するのに役立ちます。アプリケーションポッドのリソースリクエストを構成する方法の詳細については、「デプロイメントを使用してステートレスアプリケーションを作成する」をご参照ください。