목차
"자동화 + 자동화 = 완벽?"
Kubernetes 생태계에서 HPA(Horizontal Pod Autoscaler)와 Karpenter는 각각 파드와 노드 스케일링의 표준으로 자리 잡았다. 이론적으로 이 둘의 조합은 완벽해 보인다.
"파드가 늘어나면(HPA) 공간이 부족해지고, 공간이 부족하면 노드가 늘어난다(Karpenter)."
하지만 지난 프로젝트에서 이 둘을 결합했을 때, 우리는 예상치 못한 Race Condition에 직면했다. 이것은 코드 레벨의 버그가 아니라, 서로 다른 곳을 바라보는 두 제어 루프(Control Loop)가 만들어낸 구조적인 엇박자였다.
스케일링의 시차(Time Lag)와 플래핑
우리가 겪은 문제는 전형적인 "내릴 땐 급하고, 올릴 땐 늦는" 현상이었다.
엇갈린 시선
•
HPA: 오직 '파드의 리소스 사용량'만 본다. 트래픽이 줄면 파드를 즉시 줄인다.
•
Karpenter: 오직 '노드의 빈 공간'만 본다. 파드가 줄어 노드가 비면, 비용 절감을 위해 노드를 삭제(Consolidation)한다.
피드백 루프 (The Feedback Loop)
문제는 이 두 로직이 맞물릴 때 발생한다.
1.
Traffic Drop: 트래픽이 일시적으로 감소한다.
2.
HPA Scale-in: HPA가 파드 개수를 급격히 줄인다.
3.
Node Consolidation: 노드 사용률이 떨어지자 Karpenter가 "이 노드는 불필요하다"고 판단하고 삭제한다.
4.
Traffic Spike: 다시 트래픽이 튀거나, HPA가 너무 많이 줄였다고 판단하여 Scale-out을 시도한다.
5.
Pending: 파드는 늘려야 하는데, 노드는 이미 사라졌다. 새로운 노드가 뜰 때까지(약 60초+) 파드는 Pending 상태에 빠지고, 서비스는 지연된다.
결국 "과도한 최적화(Aggressive Optimization)"가 시스템의 유연성(Resilience)을 해치는 상황이 된 것이다.
해결: minReplicas로 '바닥'을 높이다
우리는 복잡한 튜닝 대신, HPA의 minReplicas 값을 조정하는 본질적인 접근을 택했다.
왜 minReplicas인가?
초기에는 비용을 아끼기 위해 minReplicas를 매우 낮게(예: 1~2) 설정했다. 하지만 이는 Karpenter에게 "노드를 줄여도 좋다"는 신호를 너무 쉽게 주는 결과를 낳았다.
우리는 minReplicas를 "최저 트래픽 시간대에도 시스템이 즉시 응답 가능한 수준"으로 상향 조정했다.
{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: {{ include "product-service.fullname" . }}
namespace: {{ .Values.namespace }}
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: {{ include "product-service.fullname" . }}
minReplicas: {{ .Values.autoscaling.minReplicas }} # 평시 Pod의 150%로 설정
maxReplicas: {{ .Values.autoscaling.maxReplicas }}
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}
{{- end }}
YAML
복사
적용 효과
1.
Buffer Zone 확보: 파드 수가 일정 수준 이하로 떨어지지 않으므로, 노드가 완전히 비는(Empty) 상황이 줄어든다.
2.
Karpenter 진정 효과: 노드가 유휴 상태가 되지 않으니 Karpenter의 공격적인 축소(Consolidation)가 자연스럽게 억제된다.
3.
Cold Start 방지: 트래픽이 급증해도, 이미 확보된 노드와 파드(Warm Pool)가 1차 방어선 역할을 수행하며 노드 증설 시간을 벌어준다.
개선점
minReplicas가 가장 큰 효과를 보았지만, 운영 환경의 견고함을 위해 몇 가지 설정을 더할 수 있다.
1.
HPA Stabilization Window:
스케일 다운에 쿨다운(Cooldown)을 둔다. "파드를 줄여라"라는 신호가 와도, 예를 들어 5분(300초) 동안은 천천히 줄이도록 설정하여 플래핑을 막는다.
...
behavior:
scaleDown:
stabilizationWindowSeconds: 300
...
YAML
복사
2.
Karpenter Disruption Budget:
Karpenter가 노드를 삭제하는 속도를 제한한다. 한 번에 너무 많은 노드가 사라지지 않도록 metrics 기반의 제동 장치를 건다.
결론
“비용과 안정성, 그 사이의 균형”
클라우드 엔지니어링은 언제나 Trade-off의 연속이다. HPA와 Karpenter를 도입한 초기 목적은 분명 '비용 절감'과 '자동화'였다. 하지만 무조건적인 리소스 최소화가 오히려 서비스 품질을 떨어뜨린다면, 그것은 잘못된 최적화다.
minReplicas를 높인 것은 비용 낭비로 비춰질 수 있지만, 그것은 예측 불가능한 트래픽 변화에 대응하기 위한 최소한의 보험이자, 시스템의 안정성을 위한 투자였다.
