이 페이지에서는 수평형 포드 자동 확장을 간략히 설명하고 Google Kubernetes Engine(GKE)에서 작동하는 방식을 설명합니다. 또한 클러스터에서 수평형 포드 자동 확장을 구성하고 사용하는 방법을 알아볼 수 있습니다.
수평형 포드 자동 확장 처리는 워크로드의 CPU 또는 메모리 소비에 따라 또는 Kubernetes 내부에서 보고된 커스텀 측정항목 또는 클러스터 외부 소스의 외부 측정항목에 따라 포드 수를 자동으로 늘리거나 줄임으로써 Kubernetes 워크로드 형태를 변경합니다.
노드 자동 프로비저닝이 포함된 GKE 클러스터는 포드 수 변경에 따라 클러스터의 노드 수를 자동으로 확장합니다. 따라서 모든 클러스터에 수평형 포드 자동 확장을 사용하는 것이 좋습니다.
수평형 포드 자동 확장을 사용하는 이유
Kubernetes 클러스터에 처음 워크로드를 배포하는 경우 리소스 요구사항이 무엇이며 사용 패턴, 외부 종속 항목 또는 기타 요인에 따라 이러한 요구사항이 어떻게 변경될지 확실히 모를 수 있습니다. 수평형 포드 자동 확장은 워크로드가 서로 다른 상황에서 일관적으로 작동하도록 보장하고 필요할 때 추가 용량에 대한 비용만 지불하여 비용을 제어할 수 있도록 도와줍니다.
워크로드의 리소스 부족이나 사용량 미달 여부를 보여주는 지표를 예측하기가 쉽지 않을 때도 있습니다. 수평형 포드 자동 확장 처리는 다음 유형의 측정항목 하나 이상을 기준으로 워크로드에서 포드 수를 자동으로 확장할 수 있습니다.
실제 리소스 사용량: 지정된 포드의 CPU 또는 메모리 사용량이 기준점을 초과하는 경우 이를 기반으로 합니다. 이 수치는 원시 값 또는 해당 리소스에 대한 포드 요청의 양을 나타내는 백분율로 표시될 수 있습니다.
커스텀 측정항목: 초당 클라이언트 요청 속도 또는 초당 I/O 쓰기와 같은 클러스터의 Kubernetes 객체가 보고한 측정항목을 기반으로 합니다.
애플리케이션에서 CPU나 메모리가 아닌 네트워크 병목 현상이 발생하는 경우 유용합니다.
외부 측정항목: 클러스터 외부의 애플리케이션 또는 서비스 측정항목을 기반으로 합니다.
예를 들어 Pub/Sub와 같은 파이프라인에서 많은 요청을 수집할 때 워크로드에 CPU가 더 필요할 수 있습니다. 큐 크기에 대해 외부 측정항목을 만들고 큐 크기가 지정된 기준점에 도달할 때 포드 수를 자동으로 늘리고 큐 크기가 축소될 때 포드 수를 줄이도록 수평형 포드 자동 확장 처리를 구성할 수 있습니다.
약간의 제한사항이 있지만, 수평형 포드 자동 확장 처리와 수직형 포드 자동 확장 처리를 결합할 수 있습니다.
수평형 포드 자동 확장 작동 방법
구성된 각 수평형 포드 자동 확장 처리는 제어 루프를 사용하여 작동합니다.
각 워크로드마다 별도의 수평형 포드 자동 확장 처리가 존재합니다. 각 수평형 포드 자동 확장 처리는 지정된 워크로드의 측정항목을 대상 기준점과 주기적으로 대조하여 확인하고 자동으로 워크로드의 형태를 변경합니다.
포드별 리소스
CPU와 같이 포드별로 할당되는 리소스의 경우 컨트롤러는 포드에서 실행되는 각 컨테이너에 대해 리소스 측정항목 API를 쿼리합니다.
CPU 또는 메모리의 원시 값을 지정하면 이 값이 사용됩니다.
CPU 또는 메모리의 백분율 값을 지정하면 수평형 포드 자동 확장 처리는 평균 사용률 값을 포드의 CPU 또는 메모리 요청의 백분율로 계산합니다.
커스텀 측정항목 및 외부 측정항목은 원시 값 또는 평균 값으로 표시됩니다.
컨트롤러는 보고된 측정항목의 평균 또는 원시 값을 사용하여 비율을 생성하고 이 비율을 사용하여 워크로드를 자동 확장합니다. Kubernetes 프로젝트 문서에서 수평형 포드 자동 확장 처리 알고리즘에 대한 설명을 볼 수 있습니다.
여러 측정항목에 응답
여러 측정항목을 기반으로 워크플로가 자동 확장되도록 구성하면 수평형 포드 자동 확장 처리는 각 측정항목을 개별적으로 평가하고 확장 알고리즘을 사용하여 각 측정항목을 기반으로 새로운 워크로드 규모를 결정합니다. 가장 큰 규모가 자동 확장 작업에 선택됩니다.
특정 이유로 인해 측정항목 하나 이상을 사용할 수 없게 되면 수평형 포드 자동 확장 처리가 계산된 가장 큰 크기를 기준으로 확장될 수 있지만 축소되지는 않습니다.
스래싱 방지
스래싱은 워크로드가 이전 자동 확장 작업에 대한 응답을 완료하기 전에 수평형 포드 자동 확장 처리가 후속 자동 확장 작업을 수행하려고 시도하는 상황을 나타냅니다. 스래싱을 방지하기 위해 수평형 포드 자동 확장 처리는 이전 5분을 기준으로 최대 권장사항을 선택합니다.
제한사항
CPU 또는 메모리에서는 수직형 포드 자동 확장 처리와 함께 수평형 포드 자동 확장 처리를 사용하지 마세요. 다른 측정항목의 수직형 포드 자동 확장 처리와 함께 수평형 포드 자동 확장 처리를 사용할 수 있습니다. 다차원 포드 자동 확장(베타)을 구성하여 CPU를 수평으로 확장하는 동시에 메모리를 수직으로 확장할 수 있습니다.
배포가 있으면 이를 지원하는 ReplicaSet 또는 복제 컨트롤러에서 수평형 포드 자동 확장을 구성하지 마세요. 배포 또는 복제 컨트롤러에서 순차적 업데이트를 수행하면 새 복제 컨트롤러로 대체됩니다. 대신 배포 자체에서 수평형 포드 자동 확장을 구성합니다.
DaemonSets와 같이 확장할 수 없는 워크로드에는 수평형 포드 자동 확장을 사용할 수 없습니다.
수평형 포드 자동 확장은 측정항목을 Kubernetes 리소스로 노출하므로 측정항목 이름에 제한사항이 적용됩니다(예: 대문자 또는 '/' 문자 금지).
측정항목 어댑터에서 이름을 변경할 수 있습니다. 예시는 prometheus-adapteras 연산자를 참조하세요.
[[["이해하기 쉬움","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-01(UTC)"],[],[],null,["# Horizontal Pod autoscaling\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page provides an overview of horizontal Pod autoscaling and explains\nhow it works in Google Kubernetes Engine (GKE). You can also read about how to\n[configure and use horizontal Pod autoscaling](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling)\non your clusters.\n\nThe Horizontal Pod Autoscaler changes the shape of your Kubernetes workload by\nautomatically increasing or decreasing the number of Pods in response to the\nworkload's CPU or memory consumption, or in response to custom metrics reported\nfrom within Kubernetes or external metrics from sources outside of your cluster.\n\nGKE clusters with node auto provisioning automatically scale the\nnumber of nodes in the cluster based on changes in the number of Pods. For that\nreason, we recommend that you use horizontal Pod autoscaling for all clusters.\n\nWhy use horizontal Pod autoscaling\n----------------------------------\n\nWhen you first deploy your workload to a Kubernetes cluster, you may not be sure\nabout its resource requirements and how those requirements might change\ndepending on usage patterns, external dependencies, or other factors. Horizontal\nPod autoscaling helps to ensure that your workload functions consistently in\ndifferent situations, and lets you control costs by only paying for extra\ncapacity when you need it.\n\nIt's not always easy to predict the indicators that show whether your workload\nis under-resourced or under-utilized. The Horizontal Pod Autoscaler can\nautomatically scale the number of Pods in your workload based on one or more\nmetrics of the following types:\n\n- **Actual resource usage**: when a given Pod's CPU or memory usage exceeds a\n threshold. This can be expressed as a raw value or as a percentage of the\n amount the Pod requests for that resource.\n\n- **Custom metrics**: based on any metric reported by a Kubernetes object in\n a cluster, such as the rate of client requests per second or I/O writes per\n second.\n\n This can be useful if your application is prone to network bottlenecks, rather\n than CPU or memory.\n- **External metrics**: based on a metric from an application or service\n external to your cluster.\n\n For example, your workload might need more CPU when ingesting a large number\n of requests from a pipeline such as Pub/Sub. You can create an\n external metric for the size of the queue, and configure the Horizontal Pod Autoscaler to automatically\n increase the number of Pods when the queue size reaches a given threshold, and\n to reduce the number of Pods when the queue size shrinks.\n\nYou can combine a Horizontal Pod Autoscaler with a Vertical Pod Autoscaler, with some\n[limitations](#limitations).\n\nHow horizontal Pod autoscaling works\n------------------------------------\n\nEach configured Horizontal Pod Autoscaler operates using a control loop.\nA separate Horizontal Pod Autoscaler exists for each workload. Each Horizontal Pod Autoscaler periodically\nchecks a given workload's metrics against the target thresholds you configure,\nand changes the shape of the workload automatically.\n\n### Per-Pod resources\n\nFor resources that are allocated per-Pod, such as CPU, the controller queries\nthe resource metrics API for each container running in the Pod.\n\n- If you specify a raw value for CPU or memory, the value is used.\n- If you specify a percentage value for CPU or memory, the Horizontal Pod Autoscaler calculates the **average** utilization value as a percentage of that Pod's CPU or memory requests.\n- Custom and external metrics are expressed as raw values or average values.\n\n| **Note:** To use resource utilization percentage targets with horizontal Pod autoscaling, you must configure requests for that resource for each container running in each Pod in the workload. Otherwise, the Horizontal Pod Autoscaler cannot perform the calculations it needs to, and takes no action related to that metric.\n\nThe controller uses the average or raw value for a reported metric to produce a\nratio, and uses that ration to autoscale the workload. You can read a description\nof the\n[Horizontal Pod Autoscaler algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)\nin the Kubernetes project documentation.\n\n### Responding to multiple metrics\n\nIf you configure a workload to autoscale based on multiple metrics, the\nHorizontal Pod Autoscaler evaluates each metric separately and uses the scaling\nalgorithm to determine the new workload scale based on each one. The **largest**\nscale is selected for the autoscale action.\n\nIf one or more of the metrics are unavailable for some reason, the Horizontal\nPod Autoscaler still scales\n**up** based on the largest size calculated, but does not scale **down**.\n\n### Preventing thrashing\n\n*Thrashing* refers to a situation in which the Horizontal Pod Autoscaler\nattempts to perform subsequent autoscaling actions before the workload finishes\nresponding to prior autoscaling actions. To prevent thrashing, the Horizontal\nPod Autoscaler chooses the largest recommendation based on the last five\nminutes.\n\nLimitations\n-----------\n\n- Don't use the Horizontal Pod Autoscaler together with the [Vertical Pod Autoscaler](/kubernetes-engine/docs/concepts/verticalpodautoscaler) on CPU or memory. You can use the Horizontal Pod Autoscaler with the Vertical Pod Autoscaler for other metrics. You can [configure multidimensional Pod autoscaling (in beta)](/kubernetes-engine/docs/how-to/multidimensional-pod-autoscaling) in order to scale horizontally on CPU and vertically on memory at the same time.\n- If you have a Deployment, don't configure horizontal Pod autoscaling on the ReplicaSet or Replication Controller backing it. When you perform a rolling update on the Deployment or Replication Controller, it is replaced by a new Replication Controller. Instead configure horizontal Pod autoscaling on the Deployment itself.\n- You can't use Horizontal Pod autoscaling for workloads that cannot be scaled, such as DaemonSets.\n- Horizontal Pod autoscaling exposes metrics as Kubernetes resources, which imposes limitations on metric names such as no uppercase or '/' characters. Your metric adapter might allow renaming. For example, see the [`prometheus-adapter` `as` operator](https://github.com/kubernetes-sigs/prometheus-adapter/blob/master/docs/config.md#naming).\n- Horizontal Pod Autoscaler won't scale down if any of the [metrics](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling#multiple-metrics) that it's configured to monitor are unavailable. To check if you have unavailable metrics, see [Viewing details about a Horizontal Pod Autoscaler](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling#viewing).\n\nScalability\n-----------\n\nWhile the Horizontal Pod Autoscaler doesn't have a hard limit on the number of\nsupported HPA objects, its performance can be affected as this number grows.\nSpecifically, the period between HPA recalculations might become longer than the\nstandard 15 seconds.\n\n- In **GKE minor version 1.22 or later** , the recalculation period should stay within 15 seconds with up to **300 HPA objects**.\n- In **GKE minor version 1.31 or later** , if the **Performance HPA profile** is configured, the recalculation period should stay within 15 seconds with up to **1,000 HPA objects** . Learn how to [configure the Performance HPA profile](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling#hpa-profile).\n- In **GKE minor version 1.33 or later** , if the **Performance HPA profile** is configured, the recalculation period should stay within 15 seconds with up to **5,000 HPA objects** . The Performance HPA profile is enabled by default on all clusters that meet the [requirements](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling#requirements_2).\n\nThe following factors can also affect performance:\n\n- **[Scaling on multiple metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#scaling-on-multiple-metrics)**: each metric adds a fetch call for recommendation calculations, which affects the recalculation period.\n- **The latency of the [custom\n metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#scaling-on-custom-metrics)\n stack**: response times over approximately 50 milliseconds would be more than typically observed with the standard Kubernetes metrics, affecting the recalculation period.\n\nInteracting with `HorizontalPodAutoscaler` objects\n--------------------------------------------------\n\nYou can configure a Horizontal Pod Autoscaler for a workload, and get information about autoscaling\nevents and what caused them, by visiting the\n[Workloads](https://console.cloud.google.com/kubernetes/workload/overview)\npage in the Google Cloud console.\n\nEach Horizontal Pod Autoscaler exists in the cluster as a `HorizontalPodAutoscaler` object. You can use commands like\n`kubectl get hpa` or `kubectl describe hpa `\u003cvar translate=\"no\"\u003eHPA_NAME\u003c/var\u003e to\ninteract with these objects.\n\nYou can also create `HorizontalPodAutoscaler` objects using the\n[`kubectl autoscale` command](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#autoscale).\n\nWhat's next\n-----------\n\n- Learn how to [configure horizontal Pod autoscaling](/kubernetes-engine/docs/how-to/horizontal-pod-autoscaling)\n- Learn how to [manually scale an Application](/kubernetes-engine/docs/how-to/scaling-apps)\n- Learn how to [scale to zero using KEDA](/kubernetes-engine/docs/tutorials/scale-to-zero-using-keda)\n- Learn more about [Vertical Pod Autoscaler](/kubernetes-engine/docs/concepts/verticalpodautoscaler)\n- Learn more about [Cluster Autoscaler](/kubernetes-engine/docs/concepts/cluster-autoscaler)"]]
