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

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

スケーリング動作のシミュレーションと決定には、次のリソースタイプがサポートされています。

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

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

はい、サポートしています。たとえば、Auto Scaling が有効になっているノードプールに、4 コア 8 GB と 12 コア 48 GB の 2 つのインスタンスタイプを構成します。ある Pod が 2 CPU コアをリクエストします。ノードの高速スケーリングがスケールアウトを実行すると、Pod を 4 コア 8 GB のノードに優先的にスケジューリングします。後で 4 コア 8 GB のインスタンスタイプが 8 コア 16 GB にアップグレードされた場合、ノードの高速スケーリングは自動的に 8 コア 16 GB のノードで Pod を実行します。

ノードプールに複数のインスタンスタイプがある場合、ノードの高速スケーリングはデフォルトでどのように 1 つを選択しますか？

ノードプールに構成されているインスタンスタイプに基づいて、ノードの高速スケーリングは在庫が不十分なインスタンスタイプを定期的に除外します。次に、残りのタイプを CPU コア数でソートし、それぞれがスケジューリング不可能な Pod のリソースリクエストを満たしているかどうかを確認します。インスタンスタイプが要件を満たすと、ノードの高速スケーリングはそのインスタンスタイプを選択し、残りのタイプはチェックしません。

ノードの高速スケーリングを使用している場合、ノードプールのインスタンスタイプの在庫のリアルタイムの変更を監視するにはどうすればよいですか？

ノードの高速スケーリングは、Auto Scaling が有効になっているノードプール内のインスタンスタイプの在庫を定期的に更新するヘルス メトリックを提供します。インスタンスタイプの在庫ステータスが変更されると、ノードの高速スケーリングは InstanceInventoryStatusChanged という名前の Kubernetes イベントを送信します。このイベント通知をサブスクライブして、ノードプールの在庫の健全性を監視し、現在のステータスを評価し、事前にインスタンスタイプの構成を調整できます。詳細については、「ノードの高速スケーリングのヘルスステータスを表示する」をご参照ください。

在庫不足によるスケールアウトの失敗を防ぐために、ノードプールの構成を最適化するにはどうすればよいですか？

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

• ノードプールに複数のオプションのインスタンスタイプを構成するか、一般化された構成を使用します。

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

ノードの高速スケーリングがノードの追加に失敗するのはなぜですか？

次のシナリオを確認してください。

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

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

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

  • 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 分以内にそのノードでスケールイン操作を実行しません。

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

  バージョン v0.5.3 は段階的リリース中です。アクセスをリクエストするには、チケットを送信してください。コンポーネントのアップグレード方法については、「コンポーネント」をご参照ください。

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

ノードの高速スケーリングによるノードの削除を妨げる可能性がある Pod のタイプは何ですか？

Pod がデプロイメント、ReplicaSet、ジョブ、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 または goatscaler.io/scale-down-only-empty:false を追加して、空のノードのみのスケールインを有効または無効にします。

• クラスターレベル: Container Service for Kubernetes コンソールで、[アドオン] ページに移動します。ノードの高速スケーリングコンポーネント ACK GOATScaler を見つけ、画面の指示に従って ScaleDownOnlyEmptyNodes を true または false に設定します。これにより、空のノードのみのスケールインが有効または無効になります。

ノードの高速スケーリングコンポーネントの自動更新をトリガーする操作はありますか？

いいえ。ACK は、システムのメンテナンスやアップグレード中を除き、ノードの高速スケーリングコンポーネントである ACK GOATScaler を自動的に更新しません。Container Service 管理コンソール の [コンポーネント管理] ページでコンポーネントを手動でアップグレードする必要があります。