ノードの自動スケーリングに関する FAQ

目次

制限

ノードの利用可能なリソースを正確に見積もることができない

基盤となるシステムが一部のリソースを消費するため、Elastic Compute Service (ECS) インスタンスの利用可能なメモリは、インスタンスタイプで定義されているメモリサイズよりも少なくなります。詳細については、「購入したインスタンスのメモリサイズが、インスタンスタイプで定義されているメモリサイズと異なるのはなぜですか?」をご参照ください。この制約により、Cluster Autoscaler の見積もりスケジューリング可能リソースは、実際のノードのスケジューリング可能リソースよりも大きくなる可能性があり、正確に見積もることができません。ポッドのリソースリクエストを構成する際には、以下の項目に注意してください。

• ポッドによってリクエストされるリソースは、インスタンスタイプで定義されているリソース (CPU、メモリ、ディスクを含む) よりも少なくなければなりません。ポッドによってリクエストされるリソースは、ノードによって提供される計算リソースの 70% を超えないようにすることをお勧めします。

• Cluster Autoscaler は、クラスター内のノードがポッドのスケジューリングに十分なリソースを提供できるかどうかを判断する際に、保留中のポッドと DaemonSet によって作成されたポッドのリソースリクエストのみをチェックします。クラスター内のノードに DaemonSet によって作成されていない静的ポッドがある場合は、ポッドのリソースを予約することをお勧めします。

• ノード上のポッドによってリクエストされるリソースが、ノードによって提供される計算リソースの 70% を超える場合は、ポッドを同じインスタンスタイプの別のノードにスケジューリングできるかどうかを確認することをお勧めします。

サポートされるスケジューリングポリシーが限られている

Cluster Autoscaler は、スケジューリング不可能なポッドを自動スケーリングが有効になっているノードプールにスケジューリングできるかどうかを判断するために、限られた数のスケジューリングポリシーのみをサポートしています。詳細については、「Cluster Autoscaler は、スケジューリング不可能なポッドをノード自動スケーリングが有効になっているノードプールにスケジューリングできるかどうかを判断するために、どのようなスケジューリングポリシーを使用しますか?」をご参照ください。

リソースタイプのリソースポリシーのみがサポートされている

リソースポリシーを使用して弾性リソースの優先順位をカスタマイズする 場合、リソースベースのポリシーのみが許可されます。

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: nginx
  namespace: default
spec:
  selector:
    app: nginx 
  units:
  - resource: ecs
  - resource: eci

複数のインスタンスタイプを持つノードプールに対して、指定されたインスタンスタイプをスケールアウトできない

ノードプールに複数のインスタンスタイプが構成されている場合、スケーリング用のインスタンスタイプを指定することはできません。Cluster Autoscaler は、スケーリンググループが提供できる最小限のリソースに基づいて、スケーリンググループのリソース容量を評価します。詳細については、「Cluster Autoscaler は、複数のタイプのインスタンスを使用するスケーリンググループのリソース容量をどのように評価しますか?」をご参照ください。

マルチゾーンノードプールでは、特定のゾーンに依存するポッドをスケールアウトできない

ノードプールが複数のゾーンで構成されており、ポッドが特定のゾーンで実行されている場合。たとえば、ポッドが特定のゾーンにあるボリュームを指定する PVC を使用している場合、またはポッドが特定のゾーンにある nodeSelector を持っている場合、Cluster Autoscaler は指定されたゾーンにノードを作成できない場合があります。Cluster Autoscaler がノードの追加に失敗する理由の詳細については、「スケールアウトアクティビティがトリガーされた後、Cluster Autoscaler がノードの追加に失敗するのはなぜですか?」をご参照ください。

どのようなスケジューリング ポリシーがクラスターオートスケーラースケジューリングできないポッドを、ノードの自動スケーリングが有効になっているノードプールにスケジューリングできるかどうかを判断するために使用しますか？

Cluster Autoscaler で使用されるスケジューリングポリシーを以下に示します。

• PodFitsResources

• GeneralPredicates

• PodToleratesNodeTaints

• MaxGCEPDVolumeCount

• NoDiskConflict

• CheckNodeCondition

• CheckNodeDiskPressure

• CheckNodeMemoryPressure

• CheckNodePIDPressure

• CheckVolumeBinding

• MaxAzureDiskVolumeCount

• MaxEBSVolumeCount

• ready

• NoVolumeZoneConflict

どのようなリソースをクラスターオートスケーラーシミュレートしますか?

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

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

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

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

次のシナリオが存在するかどうかを確認します。

• ノード自動スケーリング 機能は、自動スケーリングが有効になっているノードプールにのみ適用されます。ノード自動スケーリングが有効になっており、ノードプールのスケーリングモードが [自動] に設定されていることを確認してください。詳細については、「ノード自動スケーリングを有効にする」をご参照ください。

• スケーリンググループのインスタンスタイプが、ポッドのリソースリクエストを満たすことができません。ECS インスタンスタイプによって提供されるリソースは、ECS の仕様に準拠しています。ACK は、Kubernetes コンポーネントとシステムプロセスを実行するために、一定量のノードリソースを予約します。これにより、OS カーネル、システムサービス、および Kubernetes デーモンが想定どおりに実行されるようになります。ただし、これにより、ノードの割り当て可能なリソースの量がノードのリソース容量と異なる場合があります。詳細については、「リソース予約ポリシー」をご参照ください。

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

  • kubelet、kube-proxy、Terway、コンテナーランタイムなどのコンポーネントを実行するためにリソースが消費されます。詳細については、「リソース予約ポリシー」をご参照ください。

  • デフォルトでは、システムコンポーネントは各ノードにインストールされます。したがって、リクエストされたポッドリソースは、インスタンスタイプのリソース容量よりも少なくなければなりません。

• ゾーンに制限があるポッドに対して、ゾーン間のスケールアウトアクティビティをトリガーすることはできません。

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

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

  • インスタンスがクラスターに追加されず、タイムアウトエラーが発生します。

  • ノードが NotReady で、タイムアウトエラーが発生します。

  ノードを正しくスケーリングできるように、Cluster Autoscaler は異常なノードを修正するまでスケーリングアクティビティを実行しません。

• クラスターにノードがない場合、Cluster Autoscaler コンポーネントは機能しません。クラスターコンポーネントの安定性を確保するために、ノードプールの作成中に少なくとも 2 つのノードを構成することをお勧めします。

  シナリオでゼロノードからのスケールアウトまたはゼロノードへのスケールインが必要な場合は、ノードインスタントスケーリングを有効にする ことができます。

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

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

たとえば、スケーリンググループが 2 つのタイプのインスタンスを使用しているとします。1 つのインスタンスタイプは 4 vCPU と 32 GB のメモリを提供し、もう 1 つのインスタンスタイプは 8 vCPU と 16 GB のメモリを提供します。このシナリオでは、Auto Scaling は、スケーリンググループがそれぞれ 4 vCPU と 16 GB のメモリを提供するインスタンスを追加できると見なします。保留中のポッドが 4 vCPU と 16 GB のメモリよりも多くのリソースを リクエスト する場合、ポッドはスケジューリングされません。

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

スケーリングアクティビティを実行するときに、自動スケーリングが有効になっている複数のノードプールからどのように選択しますか?

ポッドをノードにスケジューリングできない場合、自動スケーリングコンポーネントは、スケーリンググループの構成 (ラベル、テイント、インスタンスの仕様を含む) に基づいてポッドのスケジューリングをシミュレートします。スケーリンググループが要件を満たしている場合、このスケーリンググループがスケールアウトアクティビティに選択されます。シミュレーション中に、自動スケーリングが有効になっている複数のノードプールがスケジューリング条件を満たしている場合、Cluster Autoscaler は最小浪費原則を適用します。ノードがクラスターに追加された後、残りのリソースが最も少ないノードプールが選択されます。

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

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

k8s.io/cluster-autoscaler/node-template/resource/{リソース名}:{リソース量}

例:

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

ノードプールの自動スケーリングの構成が失敗するのはなぜですか?

この問題は、次の原因によって発生する可能性があります。

• ノードプールはデフォルトのノードプールであり、ノード自動スケーリング 機能をサポートしていません。

• 手動で追加されたノードが既にノードプールに存在します。最初にこれらのノードを削除するか、または自動スケーリングが有効になっている新しいノードプールを作成することをお勧めします。

• ノードプールには、ノード自動スケーリング 機能と互換性のないサブスクリプション課金方法のインスタンスが含まれています。

なぜクラスターオートスケーラースケールイン アクティビティがトリガーされた後にノードを削除できない場合

次のシナリオが存在するかどうかを確認します。

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

• ノード上で kube-system 名前空間を実行するポッド。

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

• PodDisruptionBudget がノード上のポッドに設定されており、PodDisruptionBudget の最小値に達している。

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

DaemonSet ポッドのエヴィクションを有効または無効にするにはどうすればよいですか?

cluster-autoscaler は、[daemonset ポッドのエビクション] 設定に基づいて、DaemonSet ポッドをエビクションするかどうかを決定します。この設定は、クラスター内のすべての DaemonSet ポッドに有効です。詳細については、「ステップ 1: ノードの自動スケーリングを有効にする」をご参照ください。DaemonSet ポッドのポッドエビクションを有効にする場合は、ポッドの構成に "cluster-autoscaler.kubernetes.io/enable-ds-eviction":"true" アノテーションを追加します。

DaemonSet ポッドのエヴィクションを無効にする場合は、アノテーション "cluster-autoscaler.kubernetes.io/enable-ds-eviction":"false" をポッドの構成に追加します。

どの種類のポッドが クラスターオートスケーラーノードの削除から？

ポッドが Deployment、ReplicaSet、Job、StatefulSet などのネイティブ Kubernetes コントローラーによって作成されていない場合、またはノード上のポッドを安全に終了または移行できない場合、Cluster Autoscaler はノードの削除を妨げる可能性があります。詳細については、「どのようなタイプのポッドが CA によるノードの削除を妨げる可能性がありますか?」をご参照ください。

しますクラスターオートスケーラー CRD をサポートしていますか?

Cluster Autoscaler は標準の Kubernetes オブジェクトのみをサポートし、Kubernetes CustomResourceDefinitions (CRD) はサポートしていません。

スケールアウトの遅延を設定するにはどうすればよいですか？クラスターオートスケーラー スケジュールできないポッドの場合?

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.kubernetes.io/safe-to-evict": "false" アノテーションをポッド構成に追加します。

• Cluster Autoscaler がポッドをホストするノードを削除できるようにポッドを構成するには、"cluster-autoscaler.kubernetes.io/safe-to-evict": "true" アノテーションをポッド構成に追加します。

どうすれば クラスターオートスケーラーノードの削除から？

Cluster Autoscaler によってノードが削除されないようにするには、"cluster-autoscaler.kubernetes.io/scale-down-disabled": "true" アノテーションをノード構成に追加します。アノテーションを追加するには、次のコマンドを実行します。

kubectl annotate node <ノード名> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

更新方法クラスターオートスケーラー 最新バージョンに更新するにはどうすればよいですか？

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

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

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

3. [編集] [ノードスケーリング] の右側にあるをクリックし、パネルの下部にある [OK] をクリックして Cluster Autoscaler を最新バージョンに更新します。

どのような操作がシステムの自動更新をトリガーしますかクラスターオートスケーラー？

Cluster Autoscaler の構成が最新であり、そのバージョンがクラスターと互換性があることを確認するために、次の操作を実行すると、システムが Cluster Autoscaler を自動的に更新する可能性があります。

• 自動スケーリング構成を更新する。

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

• クラスターが更新される。

なぜノードスケーリング ロール権限付与を完了した後も失敗する ACK マネージドクラスター？

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

• チケットを送信する テクニカルサポートに。

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

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

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

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

     

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

     

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