Container Service for Kubernetes:ノードの自動スケーリングに関するよくある質問

インデックス

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

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

• PodFitsResources

• GeneralPredicates

• PodToleratesNodeTaints

• MaxGCEPDVolumeCount

• NoDiskConflict

• CheckNodeCondition

• CheckNodeDiskPressure

• CheckNodeMemoryPressure

• CheckNodePIDPressure

• CheckVolumeBinding

• MaxAzureDiskVolumeCount

• MaxEBSVorumeCount

• 準備完了

• NoVolumeZoneConflict

リソースができることcluster-autoscalerシミュレートしますか?

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

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

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

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

状況が次のいずれかに一致するかどうかを確認します。

• スケーリンググループ内のインスタンスタイプは、ポッドからのリソース要求を満たしていない可能性があります。 Elastic Compute Service (ECS) インスタンスタイプによって提供されるリソースは、ECS仕様に準拠しています。 指定されたECSインスタンスタイプによって提供される一部のリソースは、次の目的で予約または占有されます。

  • リソースは仮想化に使用されるか、インスタンスの作成中にオペレーティングシステムによって占有されます。 詳細については、「」をご参照ください。購入したインスタンスのメモリサイズが、インスタンスタイプで定義されているメモリサイズと異なるのはなぜですか。

  • ACKは、重要なKubernetesコンポーネントとシステムプロセスを操作するためにノードリソースの一部を予約します。 具体的には、kubelet、kube-proxy、Terway、コンテナランタイムなどのコンポーネントにリソースが割り当てられます。 この予約により、OSカーネル、システムサービス、およびKubernetesデーモンを通常どおり実行できます。 しかしながら、ノードの割り当て可能なリソースの量は、その総リソース容量と比較して低減される。 詳細については、「リソース予約ポリシー」をご参照ください。

  • デフォルトでは、システムコンポーネントは各ノードにインストールされます。 したがって、要求されるポッドリソースは、インスタンスタイプのリソース容量未満である必要があります。

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

• Resource Access Management (RAM) ロールには、Kubernetesクラスターの管理に必要な権限がない場合があります。 スケールアウトアクティビティに関与するKubernetesクラスターごとにRAMロールを設定する必要があります。 詳細は、「前提条件 (Prerequisites)」をご参照ください。

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

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

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

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

cluster-autoscalerが複数のタイプのインスタンスを使用するスケーリンググループのリソース容量を評価する方法?

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

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

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

エラスティックスケーリング中に自動スケーリングが有効になっている複数のノードプールから選択するにはどうすればよいですか?

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

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

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

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

自動スケーリングが有効になっているノードプールにカスタムリソースを追加する方法?

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

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

例：

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

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

状況が次のいずれかに一致するかどうかを確認します。

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

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

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

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

FAQの詳細については、オープンソースコミュニティの「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" の注釈を追加します。

防ぐことができるポッドの種類cluster-autoscaler ノードの削除から?

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

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

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

スケジュール不可能なポッドのcluster-autoscalerでスケールアウト遅延を設定するにはどうすればよいですか?

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

ポッド注釈を使用して、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.kubernetes.io/scale-down-disabled": "true" の注釈を追加します。 次のコマンドを実行して、注釈を追加します。

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

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

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

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

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

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

システムが自動的に更新cluster-autoscalerをトリガーする操作は何ですか?

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

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

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

• クラスターのアップグレードに成功しました。

ACK管理クラスターでロールの権限付与を完了した後、ノードスケーリングがまだ失敗するのはなぜですか。

この問題は、クラスターのkube-system名前空間のシークレットにaddon.aliyuncsmanagedautoscalerrole.tokenがないことが原因である可能性があります。 このトークンがない場合は、次のいずれかの方法を使用して追加します。

• テクニカルサポートのためにチケットを起票してください。

• 権限を手動で追加する: デフォルトでは、ACKはワーカーRAMロールが関連する機能を使用すると想定します。 次の手順を使用して、AliyunCSManagedAutoScalerRolePolicy権限をワーカーロールに手動で割り当てます。

  1. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[クラスター情報] をクリックします。

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

  3. ノードプール ページで、ノードスケーリング の横にある [有効化] をクリックします。

     

  4. プロンプトに従って、Kubernetes WorkerRoleロールとAliyunCSManagedAutoScalerRolePolicyシステムポリシーを承認します。 次の図は、承認を完了できるコンソールページを示しています。

     

  5. 新しいRAMポリシーを適用するには、kube-system名前空間でcluster-autoscalerまたはack-goatscaler Deploymentを手動で再起動します。 cluster-autoscalerはノードの自動スケーリングを管理し、ack-goatscalerはノードの即時スケーリングを処理します。