Alibaba Cloud Container Service for Kubernetes (ACK) では、各ノードのリソースの一部を Kubernetes コンポーネントおよびシステムプロセス用に予約します。これにより、オペレーティングシステムカーネル、システムサービス、Kubernetes デーモンプロセスが安定して動作します。その結果、ノードの合計容量とその割り当て可能リソースは異なります。ACK ではデフォルトのリソース予約ポリシーが適用されます。また、kubelet の構成を設定することで、リソース予約をカスタマイズすることもできます。
使用制限
カスタムノードのリソース予約は、Kubernetes バージョン 1.20 以降を実行しているクラスターでのみサポートされています。クラスターをアップグレードするには、「手動でクラスターをアップグレードする」をご参照ください。
影響範囲
カスタムリソース予約およびその影響範囲
リソース予約値を変更するには、「ノードプール向け kubelet の構成設定」をご参照ください。構成を更新すると、既存のノードプール内のノードに即座に反映されます。スケーリング操作時に追加されるノードや、既存のインスタンスの追加 機能を使用して追加されるノードについても、更新後の構成が適用されます。
-
コマンドラインで kubelet 構成ファイルを手動編集しないでください。 これにより、構成の競合やノードプールの運用・保守（O&M）中に予期せぬ動作が発生する可能性があります。
-
リソース予約量を増加させると、割り当て可能リソースが減少します。リソース使用率が高いノードでは、Pod のエビクションが発生する可能性があるため、値の設定には十分ご注意ください。
デフォルトリソース予約の影響範囲
ACK では、デフォルトのリソース予約値が随時更新される場合があります。更新後は、クラスターのスペックアップ、ノードプールのスペックアップ、またはノードプール向けカスタム kubelet パラメーターの変更など、ノードレベルの構成変更を行った際に、新しい予約値が自動的にノードに適用されます。このような O&M 操作を行わない場合、既存のノードプール内のノードは安定性を維持するため、従来の予約値を保持します。
ノードの割り当て可能リソースの表示
以下のコマンドを実行して、ノードの合計容量および割り当て可能リソースを表示します。
kubectl describe node [NODE_NAME] | grep Allocatable -B 7 -A 6期待される出力例：
Capacity:
cpu: 4 # ノード上の合計 CPU コア数。
ephemeral-storage: 123722704Ki # ノード上の合計一時ストレージ量（KiB 単位）。
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 7925980Ki # ノード上の合計メモリ量（KiB 単位）。
pods: 64
Allocatable:
cpu: 3900m # 割り当て可能な CPU コア数。
ephemeral-storage: 114022843818 # 割り当て可能な一時ストレージ量（バイト単位）。
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 5824732Ki # 割り当て可能なメモリ量（KiB 単位）。
pods: 64ノードの割り当て可能リソースの算出
割り当て可能リソースは、以下の数式で算出します。割り当て可能 = 容量 − 予約済み − エビクションしきい値
数式の詳細：
-
合計リソースは、ノードクエリコマンドの出力における
Capacityフィールドに対応します。 -
予約済みリソースの詳細については、「リソース予約ポリシーの詳細」をご参照ください。
-
エビクションのしきい値の詳細については、「ノードプレッシャーによるエビクション」をご参照ください。
リソース予約ポリシーの詳細
予約済みリソースは、以下の複数の要因に依存します：
-
仕様の高い ECS インスタンスでは通常、より多くの Pod を実行します。パフォーマンスを維持するため、ACK ではこうしたノード上で Kubernetes コンポーネント用に、より多くのリソースを予約します。
-
Windows ノードでは、Windows オペレーティングシステムおよび Windows Server コンポーネントに追加のリソースが必要となるため、Linux ノードよりも多くのリソースを予約します。詳細については、「Windows ノードプールの作成と管理」をご参照ください。
ACK では、CPU およびメモリの範囲に基づいて予約済みリソースを算出します。予約総量は、すべての範囲における予約量の合計です。Kubernetes 1.28 では、ACK が予約アルゴリズムを最適化し、CPU およびメモリの予約量を削減しました。クラスターのスペックアップを推奨します。「クラスターの手動スペックアップ」をご参照ください。
予約済みリソースには、Kubernetes コンポーネント用リソース（kubeReserved）およびシステムプロセス用リソース（systemReserved）が含まれます。それぞれが予約総量の 50 % を占めます。たとえば、4 コアのノードの場合：Kubernetes 1.28 以降のクラスターでは、ACK が合計 80 ミリコアを予約し、うち 40 ミリコアを kubeReserved、40 ミリコアを systemReserved として予約します。Kubernetes 1.20 ～ 1.27 のクラスターでは、ACK が合計 100 ミリコアを予約し、うち 50 ミリコアを kubeReserved、50 ミリコアを systemReserved として予約します。
CPU リソース予約ポリシー
Kubernetes 1.28 以降
以下の図は、コンピュートノードにおける合計 CPU 予約量を示しています。
32 コアのノードにおける合計 CPU 予約量の算出方法は以下のとおりです。
1000 × 6% + 1000 × 1% + 1000 × 2 × 0.5% + (32000 − 4000) × 0.25% = 150 ミリコア
Kubernetes 1.20 ～ 1.27
以下の図は、コンピュートノードにおける合計 CPU 予約量を示しています。
32 コアのノードにおける合計 CPU 予約量の算出方法は以下のとおりです。
100 + (32000 − 4000) × 2.5% = 800 ミリコア
メモリリソース予約ポリシー
Kubernetes 1.28 以降
以下の数式で合計メモリ予約量を算出します。
合計メモリ予約量 = min(11 × ($max_num_pods) + 255, 25% × ノードメモリ)。最終的な値は、11 × ($max_num_pods) + 255 と ノードメモリの 25 % のうち、小さい方の値となります。
-
$max_num_pods：ノードでサポートされる最大 Pod 数。説明ネットワークプラグインによって、ノードあたりの最大 Pod 数は異なります。詳細および算出方法については、「ノードあたりの最大 Pod 数」をご参照ください。
Container Service 管理コンソールにログインし、ノード ページで最大 Pod 数を確認できます。
-
Terway：
ノードあたりの最大 Pod 数 = コンテナネットワーク Pod の最大数 + ホストネットワーク Pod 数 -
Flannel：クラスター作成時にユーザーが設定します。
-
-
ノードメモリ：実際に使用可能なメモリ量（MiB 単位）。
たとえば、Terway を使用し、共有 ENI および複数の IP アドレスを有効化したクラスターにおいて、ノードがメモリ 256 GiB の ecs.g7.16xlarge インスタンスである場合、最大 Pod 数は (8 − 1) × 30 + 3 = 213 となります。合計メモリ予約量は min(11 × (210 + 3) + 255, 256 × 1024 × 25%) = 2598 MiB です。
Kubernetes 1.20 ～ 1.27
以下の図は、コンピュートノードにおける合計予約メモリ量を示しています。
メモリ 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.27） |
|||||
|
サンプルインスタンスタイプ |
CPU（コア数） |
メモリ （GiB） |
ノードあたりの最大 Pod 数 （Terway の包括的な ENI モードを例とする） |
CPU （ミリコア） |
メモリ （MiB） |
CPU（ミリコア） |
メモリ（MiB） |
|
ECS c7 インスタンスタイプ |
2 |
4 |
15 |
70 |
420 |
100 |
1024 |
|
4 |
8 |
48 |
80 |
783 |
100 |
1843 |
|
|
8 |
16 |
48 |
90 |
783 |
200 |
2662 |
|
|
16 |
32 |
213 |
110 |
2598 |
400 |
3645 |
|
|
32 |
64 |
213 |
150 |
2598 |
800 |
5611 |
|
|
64 |
128 |
213 |
230 |
2598 |
1600 |
9543 |
|
|
128 |
256 |
423 |
390 |
4908 |
2400 |
12164 |
|
|
ECS ebmc7a インスタンスタイプ |
256 |
512 |
453 |
710 |
5238 |
3040 |
17407 |
よくある質問
ノードの合計 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 ワークロード向けに リソースプロファイリング 機能を提供しています。この機能では、過去のリソース使用量を分析し、正確なポッド要求値の設定を支援します。手順については、「Deployment の作成」をご参照ください。