Container Service for Kubernetes (ACK) は、Kubernetesコンポーネントとシステムプロセスを実行するために特定の量のノードリソースを予約します。 これにより、オペレーティングシステムのカーネル、システムサービス、およびKubernetesデーモンを期待どおりに実行できます。 その結果、ノードの割り当て可能なリソースの量は、ノードのリソース容量と異なる。 ACKは、デフォルトのリソース予約ポリシーを提供する。 kubeletを設定して、リソース予約をカスタマイズすることもできます。
制限事項
Kubernetesバージョンが1.20以降のACKクラスターに対してのみ、カスタムリソース予約ポリシーを作成できます。 ACKクラスターのアップグレード方法の詳細については、「ACKクラスターの手動アップグレード」をご参照ください。
影響
カスタムリソース予約の影響
リソース予約をカスタマイズする方法の詳細については、「ノードプールのkubeletパラメーターのカスタマイズ」をご参照ください。 カスタムリソース予約ポリシーは、ノードプール内の既存のノードと、ノードプールに新たに追加されたノードの両方に適用されます。 新しいノードには、スケールアウト操作によって追加されたノードと、ACKコンソールの [ノードプール] ページで [既存のノードの追加] を選択して追加されたElastic Compute Service (ECS) ノードが含まれます。
kubelet ConfigMapを手動で変更するためにCLIを使用しないでください。 構成の競合が存在する場合、ノードプールのO&Mアクティビティ中に例外が発生する可能性があります。
ノードの予約リソース量を変更すると、ノードの割り当て可能なリソース量が減少する場合があります。 ノードのリソース使用率が高い場合、ノード上で実行されるポッドが追い出される可能性があります。 リソース予約を適切に設定します。
デフォルトのリソース予約の影響
ACKは、リソース予約のデフォルト値を反復し得る。 イテレーション後にノードプールのノード構成を更新すると、新しいリソース予約ポリシーがノードプール内のノードに自動的に適用されます。 たとえば、Kubernetesバージョンを更新したり、ノードプールを更新したり、ノードプールのkubeletパラメーターを変更したりすると、新しいリソース予約ポリシーが自動的に適用されます。 O&M操作を実行しない場合、ビジネスの安定性に影響がある場合に備えて、新しいリソース予約ポリシーはノードプール内の既存のノードには適用されません。
新しいリソース予約ポリシーを既存のノードに適用するには、クラスターからノードを削除してから、クラスターに再度追加します。 デフォルトでは、新しいリソース予約ポリシーは、新しく追加されたノードに自動的に適用されます。 クラスターとの間でノードを追加および削除する方法、および操作の影響の詳細については、「ノードの削除」および「既存のECSインスタンスをACKクラスターに追加する」をご参照ください。
ノードの割り当て可能なリソースの表示
次のコマンドを実行して、ノードのリソース容量と割り当て可能なリソースを表示します。
kubectl describe node [NODE_NAME] | grep Allocatable -B 7 -A 6
期待される出力:
Capacity:
cpu: 4 # The total number of CPU cores of the node.
ephemeral-storage: 123722704Ki # The total amount of ephemeral storage of the node. Unit: KiB.
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 7925980Ki # The total amount of memory of the node. Unit: KiB.
pods: 64
Allocatable:
cpu: 3900m # The number of allocatable CPU cores on the node.
ephemeral-storage: 114022843818 # The amount of allocatable ephemeral storage on the node. Unit: bytes.
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 5824732Ki # The amount of allocatable memory on the node. Unit: 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ミリコア
1.28経由のKubernetes 1.20 (包括的)
コンピュートノードの予約済みCPUリソースの合計量を次の図に示します。
ノードが32個のCPUコアを提供する場合、予約されたCPUリソースの合計量は次の式に基づいて計算されます。
100 + (32,000 - 4,000) × 2.5%= 800ミリコア
メモリを確保するためのポリシー
Kubernetes 1.28以降
計算ノードの予約済みメモリリソースの合計量は、次の式に基づいて計算されます。予約済みメモリリソース=min(11 × $max_num_pods + 255、合計メモリ × 25%)
。 $max_num_pods
は、ノードで実行できるポッドの最大数を示します。 ノードメモリ
はMiBで測定されます。 予約されたメモリリソースの合計量は、11 × $max_num_pods + 255
とtotal memory × 25%
の小さい方の値になります。
ノードで実行できるポッドの最大数は、クラスターで使用されるネットワークプラグインに基づいて計算されます。
ACKクラスターがTerwayを使用している場合、ノードで実行できるポッドの最大数は、ECSインスタンスタイプによって決定されるelastic network Interface (ENI) の数によって異なります。 さまざまなTerwayモードのノードで実行できるポッドの最大数を計算する方法の詳細については、「Terwayでの作業」をご参照ください。 ノードで実行できるポッドの最大数を表示する方法の詳細については、「Terwayでの作業」トピックのTerwayでの作業セクションを参照してください。 [ACKコンソール] にログインして、ノードで実行されるポッドの最大数を ノード ページで表示することもできます。
ACKクラスターがFlannelを使用している場合、ACKクラスターの作成時にノードで実行できるポッドの最大数を指定できます。 [ACKコンソール] にログインして、ノードで実行されるポッドの最大数を ノード ページで確認できます。
たとえば、クラスターはマルチIP共有ENIモードでTerwayを使用し、ノードのインスタンスタイプはecs.g7.16xlargeで、メモリは256 GiBです。 この場合、ノードで実行できるポッドの最大数は、(8 - 1) × 30 = 210
の式に基づいて計算されます。 予約済みメモリリソースの合計量は、次の式に基づいて計算されます。予約済みメモリリソース=min(11 × 210 + 255, 256 × 1,024 × 25%) = 2,565 MiB
。
1.28経由のKubernetes 1.20 (包括的)
次の図は、計算ノードの予約済みメモリリソースの合計量を示しています。
ノードが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 (単位: millicore) | メモリ (単位: MiB) | CPU (単位: millicore) | メモリ (単位: MiB) |
ECS c7 | 2 | 4 | 12 | 70 | 387 | 100 | 1,024 |
4 | 8 | 45 | 80 | 750 | 100 | 1,843 | |
8 | 16 | 45 | 90 | 750 | 200 | 2,662 | |
16 | 32 | 210 | 110 | 2,565 | 400 | 3,645 | |
32 | 64 | 210 | 150 | 2,565 | 800 | 5,611 | |
64 | 128 | 210 | 230 | 2,565 | 1,600 | 9,543 | |
128 | 256 | 420 | 390 | 4,875 | 2,400 | 12,164 | |
ECS ebmc7a | 256 | 512 | 450 | 710 | 5,205 | 3,040 | 17,407 |
よくある質問
ノードの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ネイティブワークロードのリソースプロファイルを作成して、履歴リソース使用量データに基づいてリソースリクエストを設定するのに役立ちます。 アプリケーションポッドのリソース要求を構成する方法の詳細については、「デプロイを使用したステートレスアプリケーションの作成」をご参照ください。
ノード上の既存のポッドにカスタムリソース予約ポリシーを適用するには、クラスターからノードを削除してから、そのノードを再度クラスターに追加する必要があります。 デフォルトでは、カスタムリソース予約ポリシーは、新しく追加されたノードに自動的に適用されます。 クラスターとの間でノードを追加および削除する方法、および操作の影響の詳細については、「ノードの削除」および「既存のECSインスタンスをACKクラスターに追加する」をご参照ください。