이 문서에서는 노드 풀 크기를 자동으로 제어하는 클러스터 자동 확장 처리에 대해 설명합니다. 클러스터 자동 확장 처리는 노드 풀의 노드 수에 최솟값과 최댓값을 지정하면 사용 설정됩니다.
노드 풀을 만들거나노드 풀을 업데이트할 때 이러한 값을 지정합니다.
Azure용 GKE는 오픈소스 Kubernetes 클러스터 자동 확장 처리를 사용합니다.
노드 풀 자동 확장
클러스터 자동 확장 처리는 워크로드 수요를 기준으로 지정된 노드 풀에서 노드 수 크기를 자동으로 조정합니다. 수동으로 노드를 추가, 삭제하거나 노드 풀을 과도하게 프로비저닝할 필요가 없습니다. 대신 노드 풀의 최소 및 최대 크기를 지정하면 나머지는 자동으로 지정됩니다.
클러스터를 자동 확장할 때 리소스를 삭제하거나 이동해야 할 경우 워크로드가 일시적으로 중단될 수 있습니다. 예를 들어 워크로드가 단일 복제본이 포함된 컨트롤러로 구성되었으면, 현재 노드가 삭제된 경우 해당 복제본의 Pod를 다른 노드에서 다시 예약할 수 있습니다. 따라서 잠재적인 중단을 견디도록 또는 중요한 포드가 중단되지 않도록 워크로드를 설계해야 합니다.
클러스터 자동 확장 처리 작동 방식
클러스터 자동 확장 처리는 노드당 풀 기준으로 작동합니다. 클러스터 자동 확장 처리를 사용하여 노드 풀을 구성할 때는 노드 풀의 최소 및 최대 크기를 지정합니다. 노드 풀을 만들거나노드 풀을 업데이트할 때 최소 및 최대 크기를 변경할 수 있습니다.
클러스터 자동 확장 처리는 실제 리소스 사용률 대신 노드 풀의 리소스 요청에 따라 자동으로 노드 풀의 크기를 늘리거나 줄입니다. 클러스터 자동 확장 처리는 포드 객체를 예약할 수 없고 요청을 충족하기에 노드 풀에 용량이 충분하지 않은 경우 노드를 추가합니다.
또한 활용률이 낮고 모든 포드 객체를 더 적은 노드 수로 예약할 수 있으면 클러스터 자동 확장 처리가 노드를 삭제합니다. 10분 후에 노드를 정상적으로 드레이닝할 수 없으면 노드가 강제로 종료됩니다. 이 기간은 구성할 수 없습니다.
포드가 너무 적은 리소스를 요청하는 경우(예: 기본값이 부족한 경우) 클러스터 자동 확장 처리는 이러한 상황을 해결하지 않습니다. 모든 워크로드에 적절한 리소스 요청을 만들어서 클러스터 자동 확장 처리가 가능한 한 정확하게 작동하도록 보장할 수 있습니다. 자세한 내용은 컨테이너에 대한 리소스 관리를 참조하세요.
포드 주석 및 클러스터 자동 확장 동작
클러스터 자동 확장 처리는 확장 결정을 내릴 때 특정 포드 주석을 고려합니다. 예를 들어 클러스터 자동 확장 처리는 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"와 같은 포드 주석을 지원합니다. 이 주석을 'false'로 설정하면 축소 이벤트 중에 포드를 호스팅하는 노드가 삭제되지 않습니다. 이러한 주석을 이해하고 사용하면 워크로드 요구사항을 충족하도록 자동 확장 처리의 동작을 미세 조정하는 데 도움이 됩니다.
포드 주석 및 클러스터 자동 확장 처리에 미치는 영향에 관한 자세한 내용은 다음 리소스를 참조하세요.
복제된 모든 포드 객체를 다른 일부 노드에서 다시 시작할 수 있으며, 결과적으로 일시적인 중단이 발생할 수 있습니다. 워크로드에서 중단이 허용되지 않으면 자동 확장이 사용 중지된 노드 풀에서 실행되도록 워크로드를 구성합니다. 자세한 내용은 노드 taint로 예약 관리를 참조하세요.
클러스터 자동 확장 처리는 사용자가 수행하는 수동 노드 관리 작업을 재정의할 수 있습니다.
단일 노드 풀의 모든 노드에 동일한 라벨 집합이 포함됩니다.
클러스터 자동 확장 처리는 확장 후 유휴 CPU 또는 사용되지 않는 메모리가 가장 적은 노드 그룹을 선택합니다. 이 동작은 동일한 클러스터에서 노드 크기가 다를 때(예: 높은 CPU 또는 높은 메모리 노드) 확장되는 노드 풀에 영향을 줍니다.
최소 및 최대 노드 풀 크기
min-nodes 및 max-nodes 플래그를 사용하여 클러스터의 각 노드 풀에 대해 최소 및 최대 크기를 지정할 수 있습니다. 자동 확장을 사용 중지하려면 min-nodes 및 max-nodes를 같은 숫자로 설정합니다. 클러스터 자동 확장 처리가 크기 경계 내에서 확장 결정을 수행합니다.
노드 풀의 최대 크기를 설정할 때 모든 워크로드를 실행하기에 충분히 큰지 확인합니다. 클러스터의 노드 풀에 모든 워크로드를 실행하는데 사용 가능한 메모리 및 CPU가 부족하면 중단이 발생할 수 있습니다.
PodDisruptionBudget을 사용하여 워크로드 보호
PodDisruptionBudget으로 워크로드 중단에 대비하도록 Azure용 GKE를 구성할 수 있습니다. PodDisruptionBudget을 만들 때 사용 가능한 포드 복제본의 최소 개수 또는 언제든지 사용할 수 없는 포드 복제본의 최대 개수를 지정합니다. 자세한 내용은 애플리케이션에 중단 예산 지정을 참조하세요.
추가 정보
클러스터 자동 확장 처리 및 중단 방지 방법에 관한 자세한 내용은 다음 리소스를 참조하세요.
[[["이해하기 쉬움","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)."]]
