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

ストレージの制約

オートスケーラーは、Pod が持つ可能性のある特定のストレージ制約を認識しません。これには、次のような要件が含まれます。

• 永続ボリューム (PV) にアクセスするために、特定のアベイラビリティゾーンで実行する必要がある。

• 特定のディスクタイプ (ESSD など) をサポートするノードが必要である。

ソリューション：専用のノードプールを構成する

アプリケーションにこのようなストレージ依存関係がある場合は、そのプールで Auto Scaling を有効にする前に、専用のノードプールを構成してください。

ノードプールの構成でアベイラビリティゾーン、インスタンスタイプ、ディスクタイプを事前に設定することで、新しくプロビジョニングされるノードが Pod のストレージマウント要件を満たすことを保証します。これにより、リソースの不一致によるスケジューリングの失敗や Pod の起動エラーを防ぐことができます。

ノードインスタントスケーリングでシミュレートできるリソースタイプ

スケーリング動作のシミュレーションと判断のために、以下のリソースタイプがサポートされています。

cpu
memory
ephemeral-storage 
aliyun.com/gpu-mem # 共有 GPU のみがサポートされています。
nvidia.com/gpu

ノードの高速スケーリングは、Pod のリソースリクエストに基づいて、ノードプールから適切なサイズのインスタンスタイプをプロビジョニングすることをサポートしていますか？

はい、これはサポートされている機能です。オートスケーラーは、Pod の要件を満たすことができる、最もリソース効率が良く、コスト効率の高いインスタンスタイプをインテリジェントに選択します。

たとえば、2 つのインスタンスタイプで構成されたノードプールを考えます。小さい 4 vCPU / 8 GiB タイプと大きい 12 vCPU / 48 GiB タイプです。

• Pod が 2 vCPU をリクエストした場合、ノードの高速スケーリングは、Pod をスケジュールするために新しい 4 vCPU / 8 GiB ノードのプロビジョニングを優先します。

• 後でノードプールの構成を更新し、4 vCPU / 8 GiB タイプを 8 vCPU / 16 GiB タイプに置き換えた場合、ノードの高速スケーリングは自動的に適応し、将来の同様のリクエストに対して 8 vCPU / 16 GiB ノードのプロビジョニングを開始します。

ノードプールに複数のインスタンスタイプがある場合、ノードの高速スケーリングはどのようにプロビジョニングするインスタンスタイプを選択しますか？

ノードプールに複数のインスタンスタイプが構成されている場合、ノードの高速スケーリングはデフォルトの選択ロジックに従います。

1. 可用性によるフィルタリング：リージョンで現在在庫が不足しているインスタンスタイプを定期的に特定し、除外します。

2. サイズによるソート：残りの利用可能なインスタンスタイプを vCPU コア数に基づいて昇順にソートします。

3. 最初の一致を選択：最小のインスタンスタイプから順に、スケジュール不可能な Pod のリソースリクエストを満たすことができるかどうかを確認します。ソートされたリストの中で Pod の要件を満たす最初のインスタンスタイプがプロビジョニング対象として選択されます。ノードの高速スケーリングは、適切な一致が見つかった後、それより大きなインスタンスタイプを評価しません。

ノードの高速スケーリングを使用する際、ノードプール内のインスタンスタイプの現在の可用性を追跡する方法

ノードの高速スケーリングは、Auto Scaling が有効になっているノードプール内のインスタンスタイプの在庫を定期的に更新するヘルス メトリックを提供します。インスタンスタイプの在庫状況が変化すると、ノードの高速スケーリングは InstanceInventoryStatusChanged という名前の Kubernetes イベントを発行します。これらのイベントを監視することで、ノードプールの在庫の健全性をモニターできます。これにより、選択したインスタンスタイプが確実に在庫にあるかどうかを評価し、事前に構成を調整することができます。詳細については、「ノードの高速スケーリングのヘルスステータスの表示」をご参照ください。

在庫不足によるスケールアウトの失敗を防ぐために、ノードプールの構成を最適化する方法

利用可能なインスタンスタイプの範囲を広げるために、以下の構成の提案を検討してください。

• ノードプールに複数のオプションのインスタンスタイプを構成するか、汎用的な構成を使用します。

• ノードプールに複数のゾーンを構成します。

ノードの高速スケーリングがノードを追加できない理由

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

• ノードプールに構成されているインスタンスタイプの在庫が不足しています。

• ノードプールに構成されているインスタンスタイプが Pod のリソースリクエストを満たせません。ECS インスタンスタイプのリソースサイズは、リストされている仕様です。ランタイム中に次のリソース予約を考慮してください。

  • インスタンス作成中に、一部のリソースが仮想化と OS によって消費されます。詳細については、「購入したインスタンスのメモリサイズがインスタンスタイプで定義されたメモリサイズと異なるのはなぜですか？」をご参照ください。

  • Container Service for Kubernetes (ACK) は、kubelet、kube-proxy、Terway、コンテナランタイムなどの Kubernetes アドオンとシステムプロセスを実行するために、一定量のノードリソースを必要とします。詳細については、「ノードリソース予約ポリシー」をご参照ください。

  • デフォルトでは、システムアドオンはノードにインストールされます。Pod によってリクエストされるリソースは、インスタンスの仕様よりも少なくなければなりません。

• 「ノードの高速弾力性を有効にする」で説明されている権限付与を完了していません。

• Auto Scaling が有効になっているノードプールがインスタンスのスケールアウトに失敗しました。

後続のスケーリングの正確性とシステムの安定性を確保するために、ノードの高速スケーリングは、異常なノードの問題が解決されるまでスケーリング操作を実行しません。

ノードの高速スケーリングが有効なノードプールにカスタムリソースを構成する方法

ノードの高速スケーリングが有効になっているノードプールに、次の固定プレフィックスを持つ ECS タグを構成します。これにより、スケーリングアドオンは、ノードプールで利用可能なカスタムリソース、または指定されたリソースの正確な値を識別できます。

goatscaler.io/node-template/resource/{resource-name}:{resource-size}

例：

goatscaler.io/node-template/resource/hugepages-1Gi:2Gi

ノードの高速スケーリングがノードを削除できない理由

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

• 空のノードのみをスケールインするオプションが有効になっていますが、チェック対象のノードが空ではありません。

• ノード上の Pod のリソースリクエストのしきい値が、構成されたスケールインのしきい値よりも高くなっています。

• kube-system 名前空間の Pod がノード上で実行されています。

• ノード上の Pod には、他のノードがそれらを実行できないようにする強制的なスケジューリングポリシーがあります。

• ノード上の Pod には PodDisruptionBudget があり、利用可能な Pod の最小数に達しています。

• 新しいノードが追加された場合、ノードの高速スケーリングは 10 分以内にそのノードでスケールイン操作を実行しません。

• オフラインノードが存在します。オフラインノードとは、対応するノードオブジェクトを持たない実行中のインスタンスです。ノードの高速スケーリングアドオンは、バージョン 0.5.3 以降で自動クリーンアップ機能をサポートしています。それ以前のバージョンでは、これらの残存インスタンスを手動で削除する必要があります。

  バージョン 0.5.3 はカナリアリリースです。使用するには、チケットを送信してアクセスをリクエストしてください。

  アップグレードするには、「アドオン」をご参照ください。

  [ノードプール] ページで、[ノードプールの同期] をクリックし、次に [詳細] をクリックします。[ノード] タブで、オフライン状態のノードがあるかどうかを確認します。

どのような Pod があると、ノードのインスタントスケーリングはノードを削除できなくなりますか？

Pod が Deployment、ReplicaSet、Job、StatefulSet などのネイティブな Kubernetes コントローラーによって作成されていない場合、またはノード上の Pod を安全に終了または移行できない場合、ノードの高速スケーリングによるノードの削除が妨げられる可能性があります。

Pod 単位でノードの高速スケーリングのスケールイン動作を制御する方法

Pod のアノテーション goatscaler.io/safe-to-evict を使用して、特定の Pod が実行されているノードが ノードの高速スケーリングアドオンによってスケールインされるのを防ぐべきかどうかを指定します。

• ノードのスケールインを防ぐには、アノテーション "goatscaler.io/safe-to-evict": "false" を Pod に追加します。

• ノードのスケールインを許可するには、アノテーション "goatscaler.io/safe-to-evict": "true" を Pod に追加します。

ノードの高速スケーリングのスケールイン時に削除するノードを指定する方法

削除したいノードに goatscaler.io/force-to-delete:true:NoSchedule Taint を追加します。この Taint を追加すると、ノードの高速スケーリングは Pod のステータスを確認したり Pod をドレインしたりすることなく、直接ノードを削除します。この機能はサービスの中断やデータの損失を引き起こす可能性があるため、注意して使用してください。

ノードの高速スケーリングが特定のノードを削除しないようにする方法

対象のノードにノードアノテーション "goatscaler.io/scale-down-disabled": "true" を使用して、ノードの高速スケーリングアドオンによるスケールインを防ぎます。以下は、アノテーションを追加するためのサンプルコマンドです。

kubectl annotate node <nodename> goatscaler.io/scale-down-disabled=true

ノードの高速スケーリングを空のノードのみ スケールインするように構成できますか？

はい、この動作はノードレベルまたはクラスターレベルのいずれかで構成できます。両方のレベルで設定が構成されている場合、ノードレベルの設定が優先されます。

• ノードレベルの構成

  特定のノードにラベルを追加して、そのスケールイン動作を制御します。

  • 有効にする (空の場合のみスケールイン)：goatscaler.io/scale-down-only-empty:true

  • 無効にする (Pod があってもスケールインを許可)：goatscaler.io/scale-down-only-empty:false

• クラスターレベルの構成

  1. ACK コンソールで、[アドオン] ページに移動します。

  2. ノードの高速スケーリングアドオン (ACK GOATScaler) を見つけ、画面の指示に従って ScaleDownOnlyEmptyNodes を true または false に設定します。

ノードの高速スケーリングアドオンは自動的に更新されますか？

いいえ。システム全体のメンテナンスや大規模なプラットフォームのアップグレードの場合を除き、ACK が node instant scaling アドオン (ACK GOATScaler) を自動で更新することはありません。お客様は、ACK コンソール内の [アドオン] ページで手動でアップグレードする必要があります。