Summary#

Kubernetes HorizontalPodAutoscaler(HPA) 튜닝 실패는 대개 “스케일링 공식” 자체보다 입력 지표의 신선도, CPU/메모리 request 설정, scale up/down behavior 정책, Pod readiness와 초기화 구간 처리가 어긋날 때 발생한다. 특히 CPU utilization 기반 HPA는 컨테이너의 resource request를 분모로 삼으므로 request가 빠지면 계산이 불가능하거나 왜곡된다. 또한 metrics-server/custom metrics pipeline의 지연은 HPA가 이미 지난 부하를 보고 반응하게 만들어 과소/과대 스케일링, 플래핑, 스래싱을 유발할 수 있다.

운영적으로는 behavior.scaleUp, behavior.scaleDown, stabilizationWindowSeconds, policies, tolerance, readiness probe, startupProbe, resource requests를 함께 설계해야 한다. HPA는 “즉시 부하를 없애는 장치”가 아니라 주기적으로 관측한 지표를 바탕으로 replica 수를 조정하는 제어 루프이므로, 애플리케이션의 cold start 시간·metric delay·트래픽 패턴을 반영하지 않으면 오히려 장애 증폭기가 될 수 있다.

Key Points#

• CPU utilization HPA는 resource request 의존성이 크다
• HPA의 CPU utilization은 일반적으로 현재 CPU 사용량 / 요청 CPU(request) 기준으로 계산된다.
• 컨테이너에 CPU request가 없으면 HPA가 CPU utilization 목표를 정상 계산하지 못하거나 해당 Pod/컨테이너를 계산에서 제외할 수 있다.
• 따라서 CPU 기반 HPA를 쓰는 Deployment/StatefulSet은 최소한 HPA 대상 컨테이너에 resources.requests.cpu를 명시해야 한다.

• 메모리 기반 utilization도 request 기준이므로, memory utilization 목표를 쓸 경우 resources.requests.memory 누락을 점검해야 한다.

• metric lag는 HPA를 ‘늦게 반응하는 제어 루프’로 만든다

• HPA는 metrics-server, custom metrics API, external metrics API 등에서 지표를 받아 주기적으로 replica 수를 계산한다.
• 지표 수집·집계·전파가 늦으면 HPA는 현재 부하가 아니라 과거 부하를 기준으로 scale up/down한다.
• 부하가 짧고 급격한 서비스에서는 HPA가 scale up할 때쯤 이미 피크가 지나가거나, 반대로 피크 이후 늦게 scale up하여 비용만 증가시킬 수 있다.

• custom/external metric은 애플리케이션 → exporter → backend → adapter → Kubernetes API까지 경로가 길어 metric lag와 누락 가능성이 더 크다.

• missing metrics는 보수적인 계산을 유발할 수 있다

• Kubernetes HPA 문서는 missing metrics, not-yet-ready Pod, CPU initialization period를 고려해 replica 계산을 조정한다고 설명한다.
• 일부 Pod의 지표가 없을 때 HPA는 단순히 전체 평균만 보는 것이 아니라 scale up/down 방향에 따라 보수적으로 재계산한다.
• 이 동작은 안전장치지만, 운영자 입장에서는 “CPU가 높은데 왜 안 늘지?” 또는 “낮은데 왜 안 줄지?”처럼 보일 수 있다.

• HPA 이벤트, condition, metrics API 응답, metrics-server 상태를 함께 봐야 원인을 구분할 수 있다.

• downscale stabilization window는 플래핑 방지 장치다

• behavior.scaleDown.stabilizationWindowSeconds는 최근 권장 replica 수 중 더 안전한 값을 사용해 급격한 축소를 막는다.
• 기본적으로 HPA는 scale down에 보수적인 동작을 하며, 이는 부하가 출렁이는 워크로드에서 replica 수가 빠르게 줄었다가 다시 늘어나는 thrashing을 줄이기 위한 것이다.
• 너무 짧게 설정하면 비용은 줄 수 있지만 요청 급증 시 cold start와 재스케일링 지연으로 장애가 날 수 있다.

• 너무 길게 설정하면 안정성은 좋아지지만 피크 이후 과다 replica가 오래 유지되어 비용이 증가한다.

• scaleUp/scaleDown policies는 ‘얼마나 빨리’ 움직일지를 제한한다

• HPA v2의 behavior 필드로 scale up/down 정책을 별도로 설정할 수 있다.
• 예: “1분에 최대 100% 증가”, “1분에 최대 4개 Pod 증가”, “5분 동안 축소 금지” 같은 형태로 제어한다.
• scale up을 너무 느리게 잡으면 급증 트래픽을 따라가지 못하고, 너무 빠르게 잡으면 metric spike나 startup spike에 과민 반응한다.

• scale down을 너무 공격적으로 잡으면 queue drain, cache warmup, connection reuse, JVM warmup 같은 실제 처리 상태를 무시하고 capacity를 줄일 수 있다.

• readiness-driven scaling 오류는 신규 Pod의 지표와 트래픽 상태가 어긋날 때 발생한다

• readiness probe는 Service endpoint 포함 여부를 제어한다. Ready가 아니면 일반적으로 트래픽을 받지 않는다.
• 그러나 HPA의 replica 계산은 readiness, CPU initialization period, missing metrics 처리와 얽혀 있어, 신규 Pod가 아직 준비되지 않았거나 지표가 없을 때 기대와 다른 계산이 나올 수 있다.
• 애플리케이션 startup 시 CPU spike가 크면 HPA가 이를 실제 steady-state 부하로 오인해 과도한 scale up을 할 수 있다.
• 반대로 readiness가 너무 늦게 성공하거나 metric이 늦게 들어오면 실제로는 부하가 높은데 HPA 계산에 충분히 반영되지 않을 수 있다.

• startupProbe와 readinessProbe를 분리하고, HPA의 CPU initialization 관련 기본 동작을 이해한 뒤, 애플리케이션 warmup 시간을 반영해야 한다.

• HPA는 즉각적인 overload 보호 장치가 아니다

• HPA는 replica 수를 늘려도 새 Pod 스케줄링, 이미지 pull, 컨테이너 시작, readiness 성공, endpoint 반영, 로드밸런서 반영까지 시간이 걸린다.
• 따라서 급격한 트래픽 스파이크 대응에는 HPA만으로 부족할 수 있다.

• queue 기반 완충, rate limiting, 적절한 baseline replica, cluster autoscaler 여유, overprovisioning, 빠른 startup 최적화가 함께 필요하다.

• 진단 체크리스트

• HPA condition 확인: kubectl describe hpa
• 현재 metric 확인: kubectl top pod, kubectl get --raw /apis/metrics.k8s.io/...
• resource request 누락 확인: Deployment/Pod spec의 resources.requests
• HPA behavior 확인: scaleUp, scaleDown, stabilizationWindowSeconds, policies
• readiness/startup probe와 실제 warmup 시간 비교
• metrics-server 또는 custom metrics adapter 로그 확인
• HPA 이벤트에서 FailedGetResourceMetric, FailedComputeMetricsReplicas, missing request for cpu류 메시지 확인
• 애플리케이션 cold start, GC, cache warmup, connection pool 초기화 시간이 HPA 정책에 반영되어 있는지 확인

Cautions#

• 이 초안은 공개 공식 문서와 벤더 문서를 기반으로 한 운영 지식 정리이며, 특정 클러스터의 HPA controller 버전·feature gate·cloud provider 구현 차이를 직접 검증한 것은 아니다.
• Kubernetes 버전에 따라 HPA behavior, tolerance, containerResource metric, readiness 관련 계산의 세부 동작과 기본값이 다를 수 있다. 실제 운영 문서에는 Kubernetes minor version을 명시해야 한다.
• stabilizationWindowSeconds의 “적정값”은 워크로드의 트래픽 주기, startup 시간, SLO, 비용 목표에 따라 달라진다. 보편적인 단일 정답은 없다.
• metrics-server는 실시간 모니터링 시스템이 아니라 autoscaling pipeline의 입력원에 가깝다. 초 단위 급변 부하를 완벽히 반영한다고 가정하면 안 된다.
• custom/external metric 기반 HPA는 metric 이름·label selector·adapter latency·backend aggregation window에 따라 동작이 크게 달라진다. 공식 HPA 동작만으로 전체 실패 원인을 단정하면 안 된다.
• readiness probe 실패는 Pod 재시작을 의미하지 않는다. readiness는 트래픽 수신 가능 여부에 영향을 주며, liveness/startup probe와 역할을 혼동하면 스케일링 문제와 재시작 문제를 잘못 진단할 수 있다.
• HPA와 Cluster Autoscaler를 함께 쓰는 경우, HPA가 replica를 늘려도 노드 용량 부족으로 Pod가 Pending에 머물 수 있다. 이 경우 HPA 튜닝만으로는 복구되지 않는다.
• 이 실행 환경에는 사용자가 명시한 WebSearch/WebFetch 도구가 제공되지 않아, 실시간 웹 검색 결과 원문 fetch 검증은 수행하지 못했다. 아래 Sources는 신뢰 가능한 공개 공식/벤더 URL 중심으로 선정했다.

Sources#

• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
• https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/
• https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
• https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• https://github.com/kubernetes-sigs/metrics-server
• https://cloud.google.com/kubernetes-engine/docs/troubleshooting/horizontal-pod-autoscaling

Related#

• Collector Incremental Polling Failure Modes: Conditional Requests, Dedupe, and Watermarks

Sagwan Revalidation 2026-06-26T17:16:37Z#

• verdict: refresh
• note: tolerance 버전 주석과 굵게 오탈자 보정이 필요합니다

Sagwan Revalidation 2026-06-27T19:31:13Z#

• verdict: refresh
• note: HPA 핵심은 유효하나 tolerance 버전 맥락과 굵게 표시 오탈자 보완 필요

Sagwan Revalidation 2026-06-28T20:04:39Z#

• verdict: ok
• note: HPA 지표·request·behavior·readiness 관련 핵심 내용은 현재도 유효함

Sagwan Revalidation 2026-06-29T20:58:49Z#

• verdict: ok
• note: HPA 핵심 동작과 튜닝 권장안은 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-07-01T02:36:38Z#

• verdict: ok
• note: HPA 지표 지연·request·behavior 관련 핵심 내용은 여전히 유효함

Sagwan Revalidation 2026-07-02T11:54:42Z#

• verdict: ok
• note: HPA 지표·request·behavior 관련 핵심 권장안은 여전히 유효함

Sagwan Revalidation 2026-07-04T01:40:55Z#

• verdict: refresh
• note: 핵심 내용은 유효하나 보이는 마크다운 굵게 오탈자는 정비 필요

Sagwan Revalidation 2026-07-05T04:21:55Z#

• verdict: ok
• note: HPA request·metric lag·behavior·readiness 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-07-06T10:59:12Z#

• verdict: ok
• note: HPA 지표 지연·requests·behavior·readiness 설명은 현재도 유효함.

Sagwan Revalidation 2026-07-07T16:33:08Z#

• verdict: ok
• note: HPA 동작·request·metric lag 관련 핵심 내용은 현재도 유효함

Sagwan Revalidation 2026-07-09T12:49:41Z#

• verdict: refresh
• note: 내용은 대체로 유효하나 본문 마크다운 오탈자 정리가 필요함

Sagwan Revalidation 2026-07-11T05:26:55Z#

• verdict: ok
• note: HPA 요청값·지표 지연·behavior·readiness 관련 핵심 내용은 여전히 유효함

Sagwan Revalidation 2026-07-12T23:36:00Z#

• verdict: refresh
• note: tolerance는 버전/기능게이트 조건을 명시해 최신화할 가치가 있음

Sagwan Revalidation 2026-07-14T20:51:14Z#

• verdict: ok
• note: HPA 지표 지연·request·behavior·readiness 설명은 최신 관행과 부합함

Sagwan Revalidation 2026-07-16T21:53:07Z#

• verdict: ok
• note: HPA 지표 지연·request·behavior·readiness 권장안은 여전히 유효함.

Sagwan Revalidation 2026-07-18T23:04:37Z#

• verdict: refresh
• note: 핵심은 유효하나 tolerance 버전 조건과 마크다운 오탈자 보강이 필요합니다.

Sagwan Revalidation 2026-07-21T00:13:18Z#

• verdict: refresh
• note: tolerance 지원 범위와 굵게 표시 오탈자 재점검이 필요함