このトピックでは、Container Service for Kubernetes (ACK) でのノードインスタントスケーリングに関するよくある質問 (FAQ) に対するソリューションを提供します。
インデックス
カテゴリ | サブカテゴリ | 問題 |
ノードインスタントスケーリングのスケーリング動作 | ||
カスタムスケーリングの動作 | ||
スケールアウト動作
ノードのインスタントスケーリングはどのリソースをシミュレートできますか?
次のリソースがサポートされています。
cpu
memory
ephemeral-storage
aliyun.com/gpu-mem # Only supports shared GPU
nvidia.com/gpu
ノードインスタントスケーリングを、ポッドが受信したリクエストに基づいてノードプールの適切なインスタンスタイプに調整できますか。
はい、できます。 たとえば、Auto Scalingを有効にしてノードプールに4 Core 8 GBと12 Core 48 GBの2つのインスタンスタイプを設定し、ポッドが2 Coreを要求した場合、スケーリング操作中にポッドを4 Core 8 GBノードにスケジューリングする優先順位はノードインスタントスケーリングになります。 4 Core 8 GBノードが後で8 Core 16 GBにアップグレードされた場合、node instant scalingは8 Core 16 GBノードでポッドを自動的に実行します。
ノードプールで複数のインスタンスタイプが設定されている場合、ノードインスタントスケーリングはデフォルトでどのように選択されますか?
ノードプールで設定されたインスタンスタイプに基づいて、ノードインスタントスケーリングはインベントリが不十分なインスタンスタイプを定期的に除外します。 次に、残りのタイプをCPUコアの数でソートし、それぞれをチェックして、スケジュール不可能なポッドのリソース要求を満たしているかどうかを確認します。 インスタンスタイプが要件を満たすと、ノードインスタントスケーリングに優先順位が付けられ、残りのタイプはチェックされません。
node instant scalingは、ノードプールのインスタンスタイプインベントリの変更をどのように検出しますか。
ノードインスタントスケーリングは、Auto scalingノードプールのインベントリの変更を定期的に更新するヘルスメトリックを提供します。 インスタンスタイプのインベントリステータスが変更されると、ノードインスタントスケーリングはInstanceInventoryStatusChangedという名前のKubernetesイベントを送信します。 このイベント通知をサブスクライブして、ノードプールのインベントリの正常性を監視し、そのステータスを評価し、インスタンスタイプの設定を事前に分析または調整することができます。 詳細については、「ノードインスタントスケーリングのヘルスステータスの表示」をご参照ください。
インベントリ不足によるスケールアウト障害を回避するために、ノードプール設定を最適化する方法を教えてください。
インスタンスタイプオプションの範囲を拡張するには、次の提案を検討してください。
ノードプールに複数のオプションのインスタンスタイプを設定するか、一般化された設定を使用します。
ノードプールに複数のゾーンを設定します。
スケールアウトアクティビティがトリガーされた後、ノードインスタントスケーリングがノードの追加に失敗するのはなぜですか。
次の問題を確認します。
ノードプールで構成されているインスタンスタイプのインベントリが不十分です。
ノードプールで構成されているインスタンスタイプは、ポッドからのリソース要求を満たすことができません。 指定されたECS (Elastic Compute Service) インスタンスタイプによって提供される一部のリソースは、次の目的で予約または占有されます。
リソースは仮想化に使用されるか、インスタンスの作成中にオペレーティングシステムによって占有されます。 詳細については、「」をご参照ください。購入したインスタンスのメモリサイズが、インスタンスタイプで定義されているメモリサイズと異なるのはなぜですか。
ACKは、kubelet、kube-proxy、Terway、コンテナランタイムなどのKubernetesコンポーネントとシステムプロセスを実行するためにいくつかのリソースを占有する必要があります。 詳細については、「リソース予約ポリシー」をご参照ください。
デフォルトでは、システムコンポーネントは各ノードにインストールされます。 したがって、要求されるポッドリソースは、インスタンスタイプのリソース容量未満である必要があります。
Resource Access Management (RAM) ロールには、Kubernetesクラスターを管理する権限がありません。 詳細については、「ノードインスタントスケーリングの有効化」をご参照ください。
Auto Scalingが有効になっているノードプールはスケールアウトに失敗します。
後続のスケーリングの精度とシステムの安定性を確保するために、node instant scalingコンポーネントは、異常なノードの問題を解決するまでスケーリング操作を実行しません。
スケールイン動作
スケールインがトリガーされた後、ノードのインスタントスケーリングがノードの削除に失敗するのはなぜですか。
次の問題を確認します。
空のノードでのスケーリングのみが有効になりますが、削除されるノードは空ではありません。
各ポッドの要求されたリソースしきい値が、指定されたスケールインしきい値よりも高い。
kube-system名前空間のポッドがノードで実行されています。
スケジューリングポリシーにより、ポッドは現在のノードで強制的に実行されます。 したがって、ポッドを他のノードにスケジュールすることはできません。
ノードのポッドにPodDisruptionBudgetが設定され、PodDisruptionBudgetの最小値に達しました。
新しいノードがある場合、ノードインスタントスケーリングは10分以内にノードに対してスケールイン操作を実行しません。
ノードインスタントスケーリングでノードが削除されないようにできるポッドの種類?
ポッドがネイティブのKubernetesコントローラー (Deployment、ReplicaSet、Job、StatefulSetなど) によって作成されていない場合、またはノード上のポッドを安全に終了または移行できない場合、ノードはノードインスタントスケーリングによって削除されません。
ポッドを使用したスケーリングの制御
ノードインスタントスケーリングでポッドを使用してノードのスケールインアクティビティを制御する方法を教えてください。
ポッド注釈goatscaler.io/safe-to-evict
を使用して、ポッドがノードの即時スケーリングをノード内でスケーリングできないようにするかどうかを指定できます。
ノードがスケーリングされないようにするには:
"goatscaler.io/safe-To-evict": "false"
という注釈をポッドに追加します。ノードをスケールインできるようにするには:
"goatscaler.io/safe-To-evict": "true"
という注釈をポッドに追加します。
ノードを使用したスケーリングの制御
のスケールインアクティビティ中に削除するノードを指定する方法ノードのインスタントスケーリング?
削除するノードに、taint goatscaler.io/force-to-delete:true:NoSchedule
を追加できます。 このテイントを追加すると、ポッドのステータスやポッドがドレインされたノードから追い出されたかどうかを確認せずに、ノードのインスタントスケーリングによって削除操作が実行されます。 サービスの中断やデータの損失が発生する可能性があるため、この機能は慎重に使用してください。
ノードインスタントスケーリングからノードが削除されないようにするにはどうすればよいですか?
node instant scalingがノードを削除しないようにするには、ノード設定に "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管理コンソールのアドオンページで、node instant scalingコンポーネントを見つけ、ScaleDownOnlyEmptyNodesをtrueまたはfalseに設定して、プロンプトに従ってこの機能を有効または無効にします。
ノードインスタントスケーリングコンポーネント
ありますか任意の操作トリガーの自動更新ノードのインスタントスケーリングコンポーネント?
いいえ、ありません。 システムのメンテナンスおよびアップグレード中を除き、ACKはノードインスタントスケーリングコンポーネントを自動的に更新しません。 Container Service管理コンソールの [アドオン] ページで手動で更新する必要があります。
ACK管理クラスターでロールの権限付与を完了した後、ノードスケーリングがまだ失敗するのはなぜですか。
この問題は、クラスターのkube-system名前空間のシークレットにaddon.aliyuncsmanagedautoscalerrole.token
がないことが原因である可能性があります。 このトークンがない場合は、次のいずれかの方法を使用して追加します。
テクニカルサポートのためにチケットを起票してください。
権限を手動で追加する: デフォルトでは、ACKはワーカーRAMロールが関連する機能を使用すると想定します。 次の手順を使用して、AliyunCSManagedAutoScalerRolePolicy権限をワーカーロールに手動で割り当てます。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、[クラスター情報] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
ノードプール ページで、ノードスケーリング の横にある [有効化] をクリックします。
プロンプトに従って、
Kubernetes WorkerRole
ロールとAliyunCSManagedAutoScalerRolePolicy
システムポリシーを承認します。 次の図は、承認を完了できるコンソールページを示しています。新しいRAMポリシーを適用するには、kube-system名前空間でcluster-autoscalerまたはack-goatscaler Deploymentを手動で再起動します。 cluster-autoscalerはノードの自動スケーリングを管理し、ack-goatscalerはノードの即時スケーリングを処理します。