クラスタの自動スケーリング中にリソースを削除または移動する必要がある場合は、ワークロードが一時的に中断する可能性があります。たとえば、ワークロードが 1 つのレプリカを持つコントローラで構成されている場合、現在のノードを削除すると、レプリカの Pod は別のノードに再スケジュールされる可能性があります。このため、一時的な中断が発生する可能性を許容するようにワークロードを設計するか、重要な Pod で割り込みが発生しないように設計する必要があります。
クラスタ オートスケーラーは、ノードが十分に活用されておらず、すべての Pod オブジェクトが少数のノードでスケジュールされる可能性がある場合にも、ノードを削除します。ノードが 10 分後に正常にドレインされなかった場合、ノードは強制終了されます。この期間は構成できません。
Pod がリクエストするリソースが少なすぎる場合(たとえば、デフォルト値が過小な場合)、クラスタ オートスケーラーは状況を改善できません。クラスタ オートスケーラーが正常に動作するように、すべてのワークロードで適切なリソース リクエストを行う必要があります。詳細については、コンテナのリソースの管理をご覧ください。
Pod アノテーションとクラスタ オートスケーラーの挙動
クラスタ オートスケーラーは、スケーリングの決定を行う際に特定の Pod アノテーションを考慮します。たとえば、クラスタ オートスケーラーは "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" などの Pod アノテーションをサポートしています。このアノテーションを「false」に設定すると、スケールダウン イベント中に Pod をホストしているノードが削除されなくなります。これらのアノテーションを理解して使用すると、ワークロードの要件に合わせてオートスケーラーの挙動を微調整できます。
Pod アノテーションとそのクラスタ オートスケーラーへの影響の詳細については、次のリソースをご覧ください。
複製対象のすべての Pod オブジェクトを、他のノードで再起動できるものとします。これにより、短い中断が発生する可能性があります。ワークロードが中断を許容しない場合は、自動スケーリングを無効にしてノードプールで実行するようにワークロードを構成します。詳細については、ノード taint を使用してスケジューリングを制御するをご覧ください。
クラスタ オートスケーラーは、手動で行ったノード管理オペレーションをオーバーライドできます。
1 つのノードプール内のすべてのノードは同じラベルセットを持つものとします。
クラスタ オートスケーラーは、スケールアップ後にアイドル状態の CPU または未使用のメモリを持つ最小限のノードグループを選択します。この動作は、同じクラスタ内に異なるサイズのノード(たとえば、ハイ CPU やハイメモリ ノード)がある場合に、どのノードプールがスケールアップされるかに影響します。
ノードプールの最大サイズを設定する際には、すべてのワークロードを実行するのに十分な大きさであることを確認してください。クラスタ内のノードプールにすべてのワークロードを実行するのに十分なメモリと CPU がない場合、停止する可能性があります。
PodDisruptionBudget を使用してワークロードを保護する
PodDisruptionBudget を使用すると、GKE on Azure を構成してワークロードの中断を防ぐことができます。PodDisruptionBudget を作成するときは、使用可能な Pod レプリカの最小数、または特定のタイミングで使用できない可能性がある Pod レプリカの最大数を指定します。詳細については、アプリケーションの停止予算を指定するをご覧ください。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["# About cluster autoscaler\n========================\n\nThis document describes the cluster autoscaler, which automatically controls the\nsize of your node pools. The cluster autoscaler is enabled when you specify\nminimum and maximum values for the number of nodes in a node pool.\nYou specify those values when you\n[Create a node pool](/kubernetes-engine/multi-cloud/docs/azure/how-to/create-node-pool)\nor [Update a node pool](/kubernetes-engine/multi-cloud/docs/azure/how-to/update-node-pool).\n\nGKE on Azure uses the open-source Kubernetes\ncluster autoscaler.\n\nAutoscale a node pool\n---------------------\n\nThe cluster autoscaler automatically resizes the number of nodes\nin a given node pool, based on the demands of your workloads. You don't need to\nmanually add or remove nodes or over-provision your node pools. Instead, you\nspecify a minimum and maximum size for the node pool, and the rest is automatic.\n\nIf resources need to be deleted or moved while autoscaling your cluster, your\nworkloads might experience transient disruption. For example, if your workload\nconsists of a controller with a single replica, that replica's Pod might be\nrescheduled onto a different node if its current node is deleted. Because of\nthis, you must design your workloads to either tolerate potential disruption or\nensure that critical Pods are not interrupted.\n| **Note:** For autoscaling to function correctly, GKE on Azure deploys the `metrics-server` Deployment with elevated [RBAC permissions](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) to your nodes, such as the ability to patch and update itself. Additional components, such as `antrea`, `coredns`, and `konnectivity-agent` have specific autoscalers with permissions to scale their component up or down depending on need.\n\nHow the cluster autoscaler works\n--------------------------------\n\nThe cluster autoscaler works on a per-node pool basis. When you use the cluster\nautoscaler to configure a node pool, you specify a minimum and maximum size for\nthe node pool. You can change the minimum and maximum size when you\n[Create a node pool](/kubernetes-engine/multi-cloud/docs/azure/how-to/create-node-pool)\nor [Update a node pool](/kubernetes-engine/multi-cloud/docs/azure/how-to/update-node-pool).\n\nThe cluster autoscaler increases or decreases the size of the node pool\nautomatically, based on the resource requests (rather than actual resource\nutilization) in that node pool. The cluster autoscaler adds nodes if Pod objects\nare unschedulable and there is not enough capacity in the node pool to meet\nrequests.\n\nThe cluster autoscaler also removes nodes if they are underutilized and all Pod\nobjects could be scheduled on a smaller number of nodes. If the node cannot be\ndrained gracefully after 10 minutes, the node is forcibly terminated. This\nperiod is not configurable.\n\nIf a Pod requests too few resources (for example, if the defaults are\ninsufficient), the cluster autoscaler does not correct the situation. You can\nhelp ensure that the cluster autoscaler works as accurately as possible by\ncreating adequate resource requests for all of your workloads. For more\ninformation, see\n[Managing resources for containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).\n\nPod annotations and cluster autoscaler behavior\n-----------------------------------------------\n\nThe cluster autoscaler considers certain Pod annotations when making scaling\ndecisions. For example, the cluster autoscaler supports Pod annotations such as\n`\"cluster-autoscaler.kubernetes.io/safe-to-evict\": \"false\"`. This annotation,\nwhen set to \"false\", prevents the Node hosting the Pod from being removed during\na scale-down event. Understanding and using these annotations can help you\nfine-tune the autoscaler's behavior to meet your workload requirements.\n\nFor more information about Pod annotations and their effects on the cluster\nautoscaler, see the following resources:\n\n- [What types of pods can prevent CA from removing a node?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node) in the cluster autoscaler FAQ.\n- [Official Kubernetes Cluster Autoscaler documentation](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#cluster-autoscaler)\n\nOperating criteria\n------------------\n\nThe cluster autoscaler makes the following assumptions when resizing a node pool:\n\n- All replicated Pod objects can be restarted on some other node, possibly causing a brief disruption. If your workload doesn't tolerate disruption, configure the workload to run on a node pool with autoscaling disabled. For more information, see [Controlling scheduling with node taints](/kubernetes-engine/docs/how-to/node-taints).\n- The cluster autoscaler can override any manual node management operations that you perform.\n- All nodes in a single node pool have the same set of labels.\n- The cluster autoscaler selects a node group that has the least idle CPU or unused memory after scaling up. This behavior affects which node pools are scaled up if you have different sizes of nodes (for example, high CPU or high memory nodes) in the same cluster.\n\nMinimum and maximum node pool size\n----------------------------------\n\nYou can specify the minimum and maximum size for each node pool in your cluster\nwith the `min-nodes` and `max-nodes` flags. To disable auto scaling, set\n`min-nodes` and `max-nodes` to the same number. The cluster autoscaler makes\nscaling decisions within these size boundaries.\n\nWhen you set the maximum size of your node pools, make sure that it is large\nenough to run all of your workloads. If the node pools in your cluster don't\nhave enough memory and CPU available to run all of your workloads, outages might\noccur.\n\nUse a `PodDisruptionBudget` to protect workloads\n------------------------------------------------\n\nYou can configure GKE on Azure to protect against workload disruption\nwith a `PodDisruptionBudget`. When you create a `PodDisruptionBudget`, you specify\nthe minimum number of Pod replicas that should be available, or the maximum\nnumber of Pod replicas that can be unavailable at any given time. For more\ninformation, see\n[Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/).\n\nMore information\n----------------\n\nTo learn more about the cluster autoscaler and how to prevent disruptions, see\nthe following resources:\n\n- [Kubernetes cluster autoscaler FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)\n- [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-does-scale-down-work)\n- [Does Cluster autoscaler work with `PodDisruptionBudget` in scale-down?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#does-ca-work-with-poddisruptionbudget-in-scale-down)\n\nWhat's next\n-----------\n\n- [Create a node pool](/kubernetes-engine/multi-cloud/docs/azure/how-to/create-node-pool).\n- [Update a node pool](/kubernetes-engine/multi-cloud/docs/azure/how-to/update-node-pool)."]]