Anthos clusters on VMware（GKE on VMware）バージョン 1.10 では、ユーザー クラスタのノードプールのクラスタ自動スケーリングが一般提供されています。クラスタの自動スケーリングは、ワークロードの需要に基づいて、特定のノードプール内のノード数を変更します。ノードを手動で追加または削除する必要はありません。また、ノードプールを過剰にプロビジョニングする必要もありません。代わりに、ノードプールの最小サイズと最大サイズを指定するだけで、あとは自動的に設定されます。
クラスタの自動スケーリング時にリソースを削除または移動すると、ワークロードが一時的に中断することがあります。たとえば、ワークロードが単一のポッドで、現在のノードが削除されると、ポッドは別のノードに再スケジュールされます。自動スケーリングを有効にする前に、一時的な中断が許容されるようにワークロードを設計し、重要なポッドで割り込みが発生しないようにしてください。
ノードプールでは、クラスタの自動スケーリングがデフォルトで無効になっています。ユーザー クラスタのノードプールに対する自動スケーリングは、クラスタの作成時かクラスタの作成後に gkectl update コマンドを使用して有効化または無効化できます。
クラスタの自動スケーリングの仕組み
クラスタ オートスケーラーはノードプール単位で機能します。クラスタ オートスケーラーを使用してノードプールを構成する場合は、ノードプールの最小サイズと最大サイズを指定します。
クラスタ オートスケーラーは、実際のリソース使用率ではなく、ノードプールのノードで実行されているポッドのリソース要求数に基づいて、ノードプールのサイズを自動的に調整します。ポッドとノードのステータスを定期的にチェックし、次の処理を行います。
- ノードプール内のノード数が不足しているためにポッドのスケジューリングができない場合、クラスタ オートスケーラーはノードプールの最大サイズまでノードを追加します。
- ノードの使用率が低く、ノードプール内のノード数を少なくしてもすべての Pod のスケジューリングが可能な場合、クラスタ オートスケーラーはノードを削除してノードプールを最小サイズにします。ノードを正しい方法でドレインできない場合、ノードは強制終了され、アタッチされた Kubernetes マネージド ディスクの接続が解除されます。
ポッドがリクエストするリソースが少なすぎる場合（あるいは、実際の要件に対して過小なデフォルト値をそのまま使用している場合）、ノードでリソース不足が発生しても、クラスタ オートスケーラーで状況を改善することができません。クラスタ オートスケーラーが正常に動作するように、すべてのワークロードに明示的なリソース リクエストを行う必要があります。
動作条件
クラスタ オートスケーラーは、次のことを前提としてノードプールのサイズを変更します。
- 複製対象のすべての Pod は、他のノードで再起動できるものとします。これにより、短い中断が発生する可能性があります。サービスの中断を許容できない場合、クラスタ オートスケーラーの使用はおすすめしません。
- ユーザーや管理者がノードを手動で管理することはありません。クラスタ オートスケーラーがノードプールに対して有効になっている場合、ノードプールの
replicasフィールドをオーバーライドすることはできません。 - 1 つのノードプール内のすべてのノードは同じラベルセットを持つものとします。
- クラスタ オートスケーラーは、各ノードプール内のインスタンス タイプの相対的なコストを考慮し、可能な限り無駄を最小限に抑える方法でノードプールを拡張しようとします。
ノードプールの最小サイズと最大サイズ
autoscaling.minReplicas と autoscaling.maxReplicas の値を使用して、クラスタ内の各ノードプールの最小サイズと最大サイズを指定できます。クラスタ オートスケーラーは、この範囲内で再スケーリングを決定します。ノードプールの replicas 値（自動スケーリングなしの場合のデフォルトのノード数）は、指定した minReplicas よりも大きく、指定した maxReplicas よりも小さい値にする必要があります。自動スケーリングを有効にした場合は、ノードプールに新しいノードが必要になるか、ノードプールからノードを安全に削除できるようになるまで、クラスタ オートスケーラーは反映を待機します。
ポッドのスケジューリングと停止の考慮
スケールダウンする場合、クラスタ オートスケーラーは、Pod に設定されているスケジューリング ルールとエビクション ルールを考慮します。この制限により、オートスケーラーによってノードが削除されるのを防ぐことができます。次のいずれかの条件を持つポッドはノードから削除されません。
- ポッドのアフィニティまたは反アフィニティ ルールにより、再スケジューリングが防止される。
- ポッドにローカル ストレージがある。
- ポッドが、Deployment、StatefulSet、Job、ReplicaSet などのコントローラによって管理されていない。
- ポッドが kube-system 名前空間にあり、PodDisruptionBudget がない。
アプリケーションの PodDisruptionBudget でも、自動スケーリングを防止できます。ノードを削除すると予算を超過する場合、クラスタはスケールダウンされません。
クラスタ オートスケーラーの詳細と中断を防ぐ方法については、クラスタ オートスケーラーに関する FAQ をご覧ください。
- スケールダウンの仕組み
- スケールダウン時にクラスタ オートスケーラーは PodDisruptionBudget と連携しますか？
- クラスタ オートスケーラーによるノードの削除を防ぐポッドの種類はありますか？
制限事項
クラスタ オートスケーラーには次の制限があります。
- スケールダウンして、ノードプール内のレプリカをゼロにすることはできません。
- 常に、ユーザー クラスタのワーカーノードの合計は 3 以上となる必要があります。つまり、自動スケーリングされたすべてのノードプールの
minReplicas値の合計と、自動スケーリングされていないすべてのノードプールのreplicas値の合計との和を 3 以上にする必要があります。 - 場合によっては、クラスタ オートスケーラーのスケールダウンが完全でなく、スケールダウン後に余分なノードが存在することがあります。これは、必要なシステムポッドが別のノード用にスケジュールされているときに発生する可能性があります。これらのポッドを別のノードに移動するためのトリガーがないためです。使用率が低いノードがいくつかありますが、スケールダウンされません。どうしてでしょうか？ この制限を回避するには、ポッド停止予算を構成できます。
- フィルタを変更したカスタム スケジュール設定はサポートされていません。
- ポッドの
PriorityClass値が-10以下の場合、ノードはスケールアップされません。詳細については、クラスタ オートスケーラーが Pod の優先度とプリエンプションでどのような役割を果たしているかをご覧ください。 - Windows ノードプールの自動スケーリングはサポートされていません。