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

Container Service for Kubernetes:ノードの自動スケーリングに関するFAQ

最終更新日:Oct 28, 2024

このトピックでは、Container Service for Kubernetes (ACK) でのノードオートスケーリングに関するよくある質問 (FAQ) に対する回答を提供します。

Index

cluster-autoscalerを最新バージョンに更新するにはどうすればよいですか?

自動スケーリングが有効なクラスターの場合、次のいずれかの方法を使用してcluster-autoscalerを更新できます。

  1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、[ノード] > [ノードプール] を選択します。

  3. ノードスケーリングの右側にある [編集] をクリックし、[OK] をクリックしてcluster-autoscalerを最新バージョンに更新します。

cluster-autoscalerはどのリソースをシミュレートできますか?

cluster-autoscalerは、次のリソースをシミュレートおよび評価できます。

cpu
memory
sigma/eni
ephemeral-storage
aliyun.com/gpu-mem (shared GPUs only)
nvidia.com/gpu

詳細については、「」をご参照ください。自動スケーリングが有効になっているノードプールにカスタムリソースを追加するにはどうすればよいですか。 このトピックのセクション。

cluster-autoscalerはCRDをサポートしていますか?

cluster-autoscalerはKubernetes標準オブジェクトのみをサポートし、Kubernetes CustomResourceDefinitions (CRD) はサポートしません。

cluster-autoscalerがノードを削除しないようにするにはどうすればよいですか?

cluster-autoscalerがノードを削除しないようにするには、ノード設定に "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" の注釈を追加します。 次のコマンドを実行して、注釈を追加します。

kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

cluster-autoscalerでスケールアウト遅延を設定するにはどうすればよいですか。

cluster-autoscaler.kubernetes.io/pod-scale-up-delayアノテーションを使用して、各ポッドのスケールアウト遅延を設定できます。 遅延が終了してもポッドがまだスケジュールできない場合、cluster-autoscalerはポッドをスケジュールするノードを追加できます。 たとえば、"cluster-autoscaler.kubernetes.io/pod-scale-up-delay": "600s" のアノテーションを使用できます。

スケールアウトアクティビティがトリガーされた後、cluster-autoscalerがノードの追加に失敗するのはなぜですか。

次の状況があるかどうかを確認します。

  • スケーリンググループ内のインスタンスタイプは、ポッドからのリソース要求を満たすことができません。 指定されたECS (Elastic Compute Service) インスタンスタイプによって提供される一部のリソースは、次の目的で予約または占有されます。

  • ゾーン間スケールアウト活動は、ゾーンに制限があるポッドに対してはトリガーできません。

  • Resource Access Management (RAM) ロールには、Kubernetesクラスターを管理する権限がありません。 スケールアウトアクティビティに関与するKubernetesクラスターごとにRAMロールを設定する必要があります。 詳細については、「Kubernetes クラスターのノードの自動スケーリング」をご参照ください。

  • ノードの自動スケーリングを有効にすると、次の問題が発生します。

    • インスタンスのクラスターへの追加に失敗し、タイムアウトエラーが発生します。

    • ノードの準備ができておらず、タイムアウトエラーが発生します。

    ノードを正確にスケーリングできるようにするため、cluster-autoscalerは異常なノードを修正する前にスケーリングアクティビティを実行しません。

スケールインアクティビティがトリガーされた後、cluster-autoscalerがノードの削除に失敗するのはなぜですか。

次の状況があるかどうかを確認します。

  • 各ポッドの要求されたリソースしきい値が、指定されたスケールインしきい値よりも高い。

  • kube-system名前空間に属するポッドがノードで実行されています。

  • スケジューリングポリシーにより、ポッドは現在のノードで強制的に実行されます。 したがって、ポッドを他のノードにスケジュールすることはできません。

  • ノードのポッドにPodDisruptionBudgetが設定され、PodDisruptionBudgetの最小値に達します。

FAQの詳細については、「autoscaler」をご参照ください。

cluster-autoscalerはスケーリングアクティビティのスケーリンググループをどのように選択しますか。

ポッドをノードにスケジュールできない場合、自動スケーリングコンポーネントはスケーリンググループの設定に基づいてポッドのスケジューリングをシミュレートします。 設定には、ラベル、テイント、インスタンス仕様が含まれます。 スケーリンググループが要件を満たしている場合、このスケーリンググループがスケールアウトアクティビティに選択されます。 複数のスケーリンググループが要件を満たしている場合、シミュレーション後のアイドルリソースが最も少ないスケーリンググループが選択されます。

cluster-autoscalerがノードを削除できないポッドの種類は何ですか?

ポッドがネイティブのKubernetesコントローラー (Deployment、ReplicaSet、Job、StatefulSetなど) によって作成されていない場合、またはノード上のポッドを安全に終了または移行できない場合、ノードはcluster-autoscalerによって削除されません。 詳細については、「」をご参照ください。CAがノードを削除できないポッドの種類は何ですか?

cluster-autoscalerは、ノードオートスケーリングが有効になっているノードプールにスケジュール不可能なポッドをスケジュールできるかどうかを判断するためにどのようなスケジューリングポリシーを使用しますか。

次のリストは、cluster-autoscalerによって使用されるスケジューリングポリシーを示しています。

  • PodFitsResources

  • GeneralPredicates

  • PodToleratesNodeTaints

  • MaxGCEPDVolumeCount

  • NoDiskConflict

  • CheckNodeCondition

  • CheckNodeDiskPressure

  • CheckNodeMemoryPressure

  • CheckNodePIDPressure

  • CheckVolumeBinding

  • MaxAzureDiskVolumeCount

  • MaxEBSVorumeCount

  • 準備完了

  • NoVolumeZoneConflict

自動スケーリングが有効になっているノードプールにカスタムリソースを追加するにはどうすればよいですか。

自動スケーリングが有効になっているノードプールによって提供されるカスタムリソースを識別したり、ノードプールによって提供される特定のリソースタイプの量を識別したりするには、次のプレフィックスを持つECSタグをノードプールに追加する必要があります。

k8s.io/cluster-autoscaler/node-template/resource/{Resource name}:{Resource amount}

例:

k8s.io/cluster-autoscaler/node-template/resource/hugepages-1Gi:2Gi

cluster-autoscalerによって追加されたノードにポッドがスケジュールされないのはなぜですか。

クラスタオートスケーラによって追加されるノード上の利用可能なリソースの推定量は、クラスタオートスケーラによる基礎となるリソース計算の精度のために、ノード上で利用可能なリソースの実際の量よりも多い場合がある。 cluster-autoscalerによる基になるリソース計算の精度の詳細については、購入したインスタンスのメモリサイズが、インスタンスタイプで定義されているメモリサイズと異なるのはなぜですか。 「インスタンスFAQ」トピックのセクション。 ノード上のポッドによって要求されたリソースが、ノードによって提供されるコンピューティングリソースの70% を超える場合、ポッドが同じインスタンスタイプの別のノードにスケジュールできるかどうかを確認することを推奨します。

cluster-autoscalerは、クラスタ内のノードがポッドスケジューリングに十分なリソースを提供できるかどうかをcluster-autoscalerが判断したときに、DaemonSetsによって作成された保留中のポッドとポッドのリソース要求のみをチェックします。 クラスター内のノードにDaemonSetsによって作成されていない静的ポッドがある場合は、これらのポッドのリソースを予約することを推奨します。

ポッド注釈を使用して、cluster-autoscalerがポッドをホストするノードを削除できるようにするか、cluster-autoscalerがポッドをホストするポッドを削除できないようにするにはどうすればよいですか。

cluster-autoscalerがポッドをホストするノードを削除できるように、またはcluster-autoscalerがポッドをホストするノードを削除できないように、ポッドを構成できます。

  • cluster-autoscalerがポッドをホストするノードを削除しないようにポッドを構成するには、ポッド構成に "cluster-autoscaler.kubernetes.io/safe-To-evict": "false" の注釈を追加します。

  • cluster-autoscalerがポッドをホストするノードを削除できるようにポッドを構成するには、ポッド構成に "cluster-autoscaler.kubernetes.io/safe-To-evict": "true" の注釈を追加します。

cluster-autoscalerを自動的に更新するトリガーとなる操作は何ですか。

次の操作では、cluster-autoscalerを自動的に更新するようにシステムをトリガーできます。 これにより、cluster-autoscalerの設定が最新であり、そのバージョンがクラスターと互換性があることが保証されます。

  • 自動スケーリング設定を更新します。

  • 自動スケーリングが有効になっているノードプールを作成、削除、または更新します。

  • クラスターの更新に成功しました。

DaemonSetポッドのポッド削除を有効または無効にするにはどうすればよいですか?

cluster-autoscalerは、evict DaemonSetポッド設定に基づいてDaemonSetポッドを削除するかどうかを決定します。 この設定は、クラスター内のすべてのDaemonSetポッドで有効になります。 詳細については、「手順1: ノードの自動スケーリングの有効化」をご参照ください。 DaemonSetポッドのDaemonSetポッド削除機能を有効にする場合は、ポッド構成に "cluster-autoscaler.kubernetes.io/enable-ds-eviction": "true" の注釈を追加します。

DaemonSetポッドのDaemonSetポッドの削除機能を無効にする場合は、ポッド構成に "cluster-autoscaler.kubernetes.io/enable-ds-eviction": "false" の注釈を追加します。

説明
  • DaemonSetポッドの削除機能が無効になっている場合、ノードがDaemonSetポッド以外のポッドをホストしている場合にのみ、アノテーションを持つDaemonSetポッドが削除されます。 DaemonSetポッドのみをホストするノードを削除するためにアノテーションを使用する場合は、まずDaemonSetポッド削除機能を有効にする必要があります。

  • DaemonSetではなくDaemonSetポッドに上記のアノテーションを追加する必要があります。

  • このアノテーションは、DaemonSetsによって作成されていないポッドには適用されません。

  • デフォルトでは、cluster-autoscalerはDaemonSetポッドを削除しても他のタスクを遅延させません。 DaemonSetポッドの削除は、他のタスクと同時に実行されます。 cluster-autoscalerがすべてのDaemonSetポッドが削除されるまで待機する場合は、ポッド構成に "cluster-autoscaler.kubernetes.io/wait-until-evicted":"true" の注釈を追加する必要があります。

Auto Scalingは、複数のタイプのインスタンスを使用するスケーリンググループのリソース容量をどのように評価しますか。

複数のタイプのインスタンスを使用するスケーリンググループの場合、Auto scalingは、スケーリンググループが提供できるリソースの最小量に基づいて、スケーリンググループのリソース容量を評価します。

たとえば、スケーリンググループは2種類のインスタンスを使用します。 1つのインスタンスタイプは4 vCoresと32 GBのメモリを提供し、もう1つは8 vCoresと16 GBのメモリを提供します。 このシナリオでは、Auto Scalingは、スケーリンググループが4つのvCoresと16 GBのメモリを提供するインスタンスを追加できると考えています。 保留中のポッドが4 vCoresまたは16 GBを超えるメモリを要求する場合、ポッドはスケジュールされません。

スケーリンググループに複数のインスタンスタイプを指定した後も、リソース予約を考慮する必要があります。 詳細については、「」をご参照ください。スケールアウトアクティビティがトリガーされた後、cluster-autoscalerがノードの追加に失敗するのはなぜですか。 このトピックのセクション。