KEDA 롤아웃 프로브 워밍업

증상

다음과 같은 반복 가능한 오류에 대해 이 가이드를 사용하세요.

keda-metrics-apiserver 또는 KEDA 운영자가 CrashLoopBackOff를 입력하거나 롤아웃 후 준비 상태가 되지 않습니다.
지속적인 CPU 수요가 낮더라도 lumie-backend는 첫 번째 가벼운 트래픽에서 확장됩니다.

현재 저장소에서 기대하는 것

체크인된 KEDA 제어 평면 값은 이미 4월 초 기본값보다 더 긴 프로브 준비 시간과 더 큰 메모리 한도를 가지고 있습니다.

resources:
  operator:
    requests:
      cpu: 50m
      memory: 128Mi
    limits:
      memory: 192Mi
...
operator:
  livenessProbe:
    initialDelaySeconds: 45
...
metricsServer:
  readinessProbe:
    initialDelaySeconds: 20

출처: lumie-infra/platform/keda/helm-values.yaml

백엔드 ScaledObject는 명시적인 확장 댐핑도 수행합니다.

minReplicaCount: 1
maxReplicaCount: 2
advanced:
  horizontalPodAutoscalerConfig:
    behavior:
      scaleUp:
        stabilizationWindowSeconds: 120
        policies:
          - type: Pods
            value: 1
            periodSeconds: 60

출처: lumie-infra/applications/lumie/backend/manifests/scaled-object.yaml

이 실패 모드가 발생한 이유

커밋	변경	운영 레슨
`55ec012b`	Helm 값 키 구조 수정	잘못된 중첩은 차트가 의도한 리소스 설정을 무시했음을 의미합니다.
`6650bd47`	메트릭 서버 메모리 및 프로브 지연 증가	메트릭 API 서버를 시작하는 데 약 19초가 필요했습니다.
`865c7ece`	운영자 프로브 임계값 증가 및 CPU 제한 제거	프로세스가 정상일 때에도 느린 API 호출로 인해 기본 프로브가 플랩될 수 있음
`f4581593`	백엔드 확장 안정화 추가	JVM 준비 버스트가 즉시 최대 복제본 배포를 추진해서는 안 됩니다.

진단 경로

KEDA 출시가 실패한 경우

kubectl get pods -n keda-system
kubectl describe pod -n keda-system -l app.kubernetes.io/name=keda-metrics-apiserver
kubectl describe pod -n keda-system -l app.kubernetes.io/name=keda-operator

스케일러 로직 자체가 손상되었다고 가정하기 전에 프로브 오류를 찾아보십시오. 4월 수정 사항은 RabbitMQ 또는 CPU 트리거 구문이 아닌 시작 및 API 응답 타이밍에 관한 것입니다.

준비 시 `lumie-backend`가 과도하게 확장되는 경우

kubectl get scaledobject,hpa -n lumie-backend
kubectl describe scaledobject -n lumie-backend lumie-backend
kubectl get deploy -n lumie-backend lumie-backend -o yaml | rg -n "cpu:|memory:"

조정 트리거는 여전히 CPU 사용률 70이며 KEDA는 포드 CPU 요청에 대해 이를 계산합니다. 그 분모는 ScaledObject만큼 중요합니다.

변경하기 전에 확인할 현재 드리프트

2026년 6월 1일 준비 수정으로 인해 백엔드 CPU 요청이 250m로 명시적으로 발생했지만 현재 체크인된 백엔드 값은 이제 다음과 같이 표시됩니다.

resources:
  requests:
    cpu: 25m
    memory: 512Mi

출처: lumie-infra/applications/lumie/backend/common-values.yaml

따라서 현재 저장소는 ScaledObject 안정화 가드를 유지하지만 커밋 f4581593에 설명된 원래의 더 높은 CPU 요청 분모는 유지하지 않습니다. 워밍업으로 인해 과도한 확장이 발생하는 경우 6월 수정 사항이 아직 완전히 존재한다고 가정하기보다는 이를 라이브 계약 드리프트로 처리하십시오.

수정

컨트롤 플레인 롤아웃 오류의 경우 platform/keda/helm-values.yaml의 프로브 및 메모리 설정을 현재 체크인된 값과 일치하도록 유지합니다.
백엔드 준비가 급증하는 경우 백엔드 ScaledObject에서 scaleUp 안정화 블록을 유지합니다.
CPU 트리거 AutoScaling을 변경할 때마다 백엔드 CPU 요청을 다시 확인합니다. 요청은 확장 계약의 일부입니다.
KEDA 자체가 정상인 후에만 워커 큐 스케일러를 확인하세요. 예를 들어, 현재 report-svc 계약은 applications/lumie/worker/report-svc/manifests/scaled-object.yaml의 minReplicaCount: 3 및 maxReplicaCount: 5를 포함하는 큐 길이 40입니다.

예방

KEDA 차트 값 키를 차트가 예상하는 정확한 구조로 유지하세요. 의도한 리소스 재정의가 무시되었기 때문에 4월 초 실패가 발생했습니다.
롤아웃 프로브 및 자동 크기 조정 임계값을 하나의 작동 표면으로 처리합니다. 메트릭 서버가 준비 상태가 되지 않으면 정상 ScaledObject는 유용하지 않습니다.
백엔드 AutoScaling 변경 시 manifests/scaled-object.yaml와 common-values.yaml를 함께 검토하세요.

확인

kubectl get applications.argoproj.io -n argocd keda
kubectl get pods -n keda-system
kubectl get scaledobject,hpa -n lumie-backend
kubectl get scaledobject -n lumie-worker report-svc -o yaml

성공은 KEDA 제어 평면 포드가 준비되었고 백엔드 ScaledObject에 안정화 블록이 있으며 워커 스케일러가 probe 관련 제어 평면 이탈 없이 Git에서 렌더링된다는 것을 의미합니다.

운영 세부사항

이 가이드는 서로 관련 있지만 다른 두 실패군을 다룹니다.

실패군	주요 신호	주요 owner
KEDA control-plane rollout instability	KEDA pod가 probe에 실패하거나 crash-loop합니다.	`platform/keda/helm-values.yaml`.
Workload warmup over-scaling	application replica가 일시적인 startup CPU에 반응해 급증합니다.	workload `ScaledObject`와 CPU request.

KEDA metrics API server가 건강하지 않을 때는 workload scaling을 조정하지 않습니다. workload 증상은 불안정한 scaling control plane의 부작용일 수 있습니다.

backend warmup case는 CPU utilization이 비율이기 때문에 특히 민감합니다. CPU request를 낮추면 같은 JVM warmup burst도 HPA/KEDA 수식에서 더 크게 보입니다.

복구 절차

KEDA pod를 먼저 확인합니다. Ready가 아니면 어떤 ScaledObject보다 control-plane resource와 probe를 먼저 고칩니다.
chart values가 Helm chart가 실제 소비하는 key 아래에 render되는지 확인합니다.
backend over-scaling은 live HPA target, backend CPU request, scaleUp behavior를 함께 비교합니다.
steady warmed traffic이 아니라 first-request 또는 cold-start traffic으로 재현합니다.
June fix 이후 CPU request가 바뀌었다면 stabilization window만으로 workload를 보호하는지 다시 평가합니다.

검증 증거

다음을 캡처합니다.

KEDA operator와 metrics API server readiness.
KEDA pod의 live resource request와 limit.
live backend ScaledObject와 생성된 HPA behavior.
autoscaling denominator로 사용되는 backend CPU request.
warmup 중 replica count와 stabilization window 이후 replica count.

피해야 할 패턴

warmup jitter를 숨기려고 maxReplicaCount를 늘리는 것.
CPU request 검토 없이 CPU trigger threshold만 바꾸는 것.
KEDA control-plane probe가 실패하는데 worker queue scaler를 조정하는 것.
chart upgrade 후 실제 startup time을 확인하지 않고 probe delay를 제거하는 것.

증상​

현재 저장소에서 기대하는 것​

이 실패 모드가 발생한 이유​

진단 경로​

KEDA 출시가 실패한 경우​

준비 시 lumie-backend가 과도하게 확장되는 경우​

변경하기 전에 확인할 현재 드리프트​

수정​

예방​

확인​

관련 페이지​

운영 세부사항​

복구 절차​

검증 증거​

피해야 할 패턴​

증상