이 페이지에서는 커스텀, 외부 또는 Prometheus 측정항목을 사용하여 특정 워크로드의 복제본 수를 자동으로 늘리거나 줄이는 방법을 설명합니다.
측정항목을 기준으로 자동 확장하는 이유
큐에서 작업을 가져와서 완료하는 애플리케이션을 생각해 보세요. 애플리케이션은 작업을 처리하는 시간 또는 대기중인 작업 수에 대한 서비스 수준 목표(SLO)를 가질 수 있습니다. 큐가 증가하는 경우 워크로드의 복제본이 늘어나면 워크로드의 SLO를 충족할 수 있습니다. 큐가 비어 있거나 예상보다 빠르게 감소하는 경우 워크로드 SLO를 유지하면서 복제본을 줄여 비용을 절약할 수 있습니다.
커스텀, Prometheus, 외부 측정항목 정보
커스텀, Prometheus 또는 외부 측정항목을 기반으로 워크로드를 확장할 수 있습니다.
외부 측정항목은 클러스터에서 실행되지 않지만 Kubernetes 애플리케이션에 영향을 주는 성능을 가진 애플리케이션이나 서비스에서 보고됩니다. 예를 들어 Pub/Sub 또는 Dataflow를 비롯한 Cloud Monitoring의 모든 측정항목을 자동 확장할 수 있습니다. Prometheus 측정항목에는 자동 확장에 사용할 수 있는 클러스터에서 내보낸 데이터가 포함되어 있습니다. 자세한 내용은 외부 측정항목을 참조하세요.
커스텀 및 Prometheus 측정항목
커스텀 측정항목을 만들고 관리하려면 Managed Service for Prometheus를 사용하는 것이 좋습니다. Prometheus Query Language(PromQL)를 사용하여 Monitoring의 모든 측정항목을 쿼리할 수 있습니다. 자세한 내용은 Managed Service for Prometheus의 수평형 포드 자동 확장을 참조하세요.
애플리케이션에서는 Monitoring에 커스텀 측정항목을 보고할 수 있습니다. 이러한 측정항목에 응답하고 워크로드를 자동으로 확장하도록 Kubernetes를 구성할 수 있습니다. 예를 들어 초당 쿼리 수, 초당 쓰기, 네트워크 성능, 다른 애플리케이션과 통신할 때의 지연 시간 또는 워크로드에 적합한 기타 측정항목 등의 측정항목을 기반으로 애플리케이션을 확장할 수 있습니다. 자세한 내용은 측정항목을 기준으로 포드 자동 확장 최적화를 참조하세요.
외부 측정항목
Kubernetes 외부의 애플리케이션 또는 서비스 성능을 기반으로 워크로드를 확장해야 하는 경우 외부 측정항목을 구성할 수 있습니다. 예를 들어 전달되지 않은 메시지 수가 증가하는 추세를 보이는 경우 Pub/Sub에서 메시지를 수집하기 위해 애플리케이션의 용량을 늘려야 할 수 있습니다. 외부 애플리케이션은 클러스터가 액세스할 수 있는 Monitoring 인스턴스로 측정항목을 내보내야 합니다. 시간 경과에 따라 각 측정항목의 추세를 기반으로 수평형 포드 자동 확장 처리에서 워크로드의 복제본 수를 자동으로 변경합니다. 자세한 내용은 측정항목을 기준으로 포드 자동 확장 최적화를 참조하세요.
[[["이해하기 쉬움","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,["# About autoscaling workloads based on metrics\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the ways that you can automatically increase or decrease\nthe number of replicas of a given workload using custom, external, or Prometheus\nmetrics.\n\nWhy autoscale based on metrics\n------------------------------\n\nConsider an application that pulls tasks from a queue and completes them. The\napplication might have a Service-Level objective (SLO) for time to process a\ntask, or for the number of tasks pending. If the queue is increasing, more\nreplicas of the workload might meet the workloads SLO. If the queue is empty or\nis decreasing more quickly than expected, you could save money by running fewer\nreplicas, while still meeting the workloads SLO.\n\nAbout custom, Prometheus, and external metrics\n----------------------------------------------\n\nYou can scale workloads based on custom, Prometheus, or external metrics.\n\nA *custom metric* is reported from your application running in Kubernetes. To\nlearn more, see\n[Custom and Prometheus metrics](#custom-prometheus-metrics).\n\nMetrics coming from\n[Managed Service for Prometheus](/stackdriver/docs/managed-prometheus) are\nconsidered a type of custom metric.\n\nAn *external metric* is reported from an application or service not running on\nyour cluster, but whose performance impacts your Kubernetes application. For\nexample, you can autoscale on any metric in Cloud Monitoring, including\nPub/Sub or Dataflow. Prometheus metrics contain data emitted\nfrom your cluster that you can use to autoscale on. To learn more, see\n[External metrics](#external-metrics).\n\n### Custom and Prometheus metrics\n\nWe recommend that you use Managed Service for Prometheus to create and manage\ncustom metrics. You can use Prometheus Query Language (PromQL) to query all\nmetrics in Monitoring. For more information, see\n[Horizontal Pod autoscaling for Managed Service for Prometheus](/stackdriver/docs/managed-prometheus/hpa).\n\nYour application can report a custom metric to Monitoring. You\ncan configure Kubernetes to respond to these metrics and scale your workload\nautomatically. For example, you can scale your application based on metrics such\nas queries per second, writes per second, network performance, latency when\ncommunicating with a different application, or other metrics that make sense for\nyour workload. For more information, see\n[Optimize Pod autoscaling based on metrics](/kubernetes-engine/docs/tutorials/autoscaling-metrics).\n\n### External metrics\n\nIf you need to scale your workload based on the performance of an application\nor service outside of Kubernetes, you can configure an external metric. For\nexample, you might need to increase the capacity of your application to ingest\nmessages from Pub/Sub if the number of undelivered messages is\ntrending upward. The external application needs to export the metric to a\nMonitoring instance that the cluster can access. The trend of\neach metric over time causes Horizontal Pod Autoscaler to change the number of\nreplicas in the workload automatically. For more information, see\n[Optimize Pod autoscaling based on metrics](/kubernetes-engine/docs/tutorials/autoscaling-metrics).\n\nImport metrics to Monitoring\n----------------------------\n\nTo import metrics to Monitoring, you can either:\n\n- Configure [Managed Service for Prometheus](/stackdriver/docs/managed-prometheus) (recommended), **or**\n- Export metrics from the application using the [Cloud Monitoring API](/monitoring/custom-metrics/creating-metrics).\n\nWhat's next\n-----------\n\n- Learn how to [enable horizontal Pod autoscaling for Managed Service for Prometheus](/stackdriver/docs/managed-prometheus/hpa).\n- Learn more about [Horizontal Pod Autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n- Learn more about [Vertical Pod autoscaling](/kubernetes-engine/docs/concepts/verticalpodautoscaler)."]]
