Goldilocks: Kubernetes 리소스 요청값을 "딱 맞게" 설정하는 법
쿠버네티스에서 파드의 CPU·메모리 설정값을 잘못 잡으면 두 가지 문제가 생깁니다. 너무 높으면 클러스터 자원의 상당 부분이 낭비되고, 너무 낮으면 실서비스에서 파드가 강제 종료됩니다. Goldilocks는 쿠버네티스가 내부적으로 계산해 둔 "적정 사용량 권고값"을 가져다가 누구나 볼 수 있는 대시보드로 보여주는 도구로, 특히 서버를 즉시 추가할 수 없는 온프레미스 환경에서 동일한 하드웨어로 더 많은 워크로드를 안정적으로 운영하는 데 실질적인 도움을 줍니다.
쿠버네티스에서 requests와 limits를 어떻게 설정하고 계신가요?
솔직히 말하면 대부분의 팀은 "일단 넉넉하게"를 기본값으로 씁니다. 첫 배포 때 설정한 값이 6개월, 1년이 지나도 그대로 남아있는 경우가 흔합니다. 그 결과는 두 가지 중 하나입니다. 노드 자원의 30~40%가 낭비되거나, 반대로 너무 낮게 잡아서 실서비스에서 OOM Kill을 맞거나.
오늘은 이 만성적인 리소스 설정 문제를 데이터 기반으로 해결해 주는 오픈소스 도구 Goldilocks를 소개합니다.
1. 문제의 본질: 감각에 의존하는 리소스 설정
쿠버네티스의 resources.requests와 resources.limits는 스케줄러가 파드를 배치하고, kubelet이 자원을 보장하는 핵심 설정입니다. 그런데 이 값을 "정확하게" 설정하려면 다음이 필요합니다.
- 실제 워크로드의 CPU/메모리 사용 패턴
- 피크 타임 기준의 최대 사용량
- 충분한 관측 기간 (최소 수 일~수 주)
대부분의 팀에게 이 과정은 현실적으로 불가능합니다. 배포 일정은 빠르고, 모니터링을 꼼꼼히 들여다볼 여유는 없습니다. 결국 직감과 경험에 의존한 "적당한 값"이 프로덕션에 들어갑니다.
이 문제가 오랫동안 해결되지 않은 이유는 기술적 어려움이 아닙니다. 관측에서 권고까지의 워크플로우가 부재했기 때문입니다.
2. Goldilocks란 무엇인가?
Goldilocks는 FairwindsOps가 만든 오픈소스 유틸리티로, GitHub Star 3,200개 이상을 보유한 검증된 Kubernetes 생태계 도구입니다.
핵심 철학은 단순합니다.
"Kubernetes VPA(Vertical Pod Autoscaler)의 추천 데이터를 수집하고, 팀이 바로 활용할 수 있는 대시보드로 시각화한다."
Goldilocks 자체가 리소스를 분석하는 것이 아닙니다. 이미 Kubernetes가 공식 제공하는 VPA Recommender가 실제 사용량을 기반으로 권고값을 계산합니다. Goldilocks는 그 결과를 읽기 쉬운 UI로 모아서 보여주는 레이어입니다.
3. 작동 원리: 3-계층 구조
Goldilocks의 구조는 세 계층으로 이루어집니다.
[Goldilocks Controller] —(VPA 오브젝트 생성)→ [VPA Recommender] —(권고값 기록)→ [Goldilocks Dashboard]
↑
[실제 워크로드 감시]
VPA Recommender
Kubernetes 공식 autoscaler 프로젝트의 컴포넌트입니다. 파드의 실제 CPU·메모리 사용 이력을 수집하여 적절한 requests 권고값을 지속적으로 계산하고, VPA 오브젝트의 status 필드에 기록합니다.
Goldilocks는 VPA 오브젝트를 생성할 때 updateMode: "Off"로 설정합니다. 이 때문에 VPA Recommender가 권고값을 계산하더라도 실제 파드를 재시작하거나 리소스 값을 변경하지 않습니다. vpa-admission-controller와 vpa-updater가 함께 설치되더라도 updateMode: "Off" 상태에서는 두 컴포넌트 모두 실제로 개입하지 않습니다.
Goldilocks Controller
네임스페이스에 라벨(goldilocks.fairwinds.com/enabled=true)을 붙이면 Controller가 해당 네임스페이스의 워크로드(Deployment, DaemonSet, StatefulSet 등)를 감시하며 VPA 오브젝트를 자동으로 생성합니다. 동작 방식은 다음과 같습니다.
- 라벨 부착 시점에 기존 워크로드 전체에 대해 VPA 오브젝트를 일괄 생성
- 이후 새 워크로드가 추가되면 reconcile loop를 통해 VPA 오브젝트를 추가 생성
- 이미 VPA 오브젝트가 존재하면 재생성하지 않고 유지
- 라벨 제거 시 해당 네임스페이스의 VPA 오브젝트를 일괄 삭제
Goldilocks Dashboard
VPA 오브젝트의 status에서 권고값을 읽어 웹 UI로 표시합니다. 각 컨테이너별로 Guaranteed와 Burstable QoS 기준의 권고값(Lower Bound / Target / Upper Bound)을 제공하며, 현재 설정된 requests·limits 값과 나란히 확인할 수 있습니다.
4. 실습: 10분 핸즈온
사전 요구사항
kubectl설정 완료- metrics-server 설치 (VPA의 의존성)
- Helm v3
Step 1 — VPA 설치
Goldilocks는 VPA Recommender만 필요합니다. Admission Webhook은 불필요하며, 오히려 설치하면 예기치 않은 파드 재시작이 발생할 수 있습니다. Fairwinds에서 제공하는 VPA Helm Chart를 사용하면 Recommender만 안전하게 설치됩니다.
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install vpa fairwinds-stable/vpa \
--namespace vpa \
--create-namespace
Step 2 — Goldilocks 설치
kubectl create namespace goldilocks
helm install goldilocks fairwinds-stable/goldilocks \
--namespace goldilocks
Step 3 — 네임스페이스 활성화
분석하고 싶은 애플리케이션 네임스페이스에 라벨을 붙입니다.
# 예시: default 네임스페이스 분석 활성화
kubectl label ns default goldilocks.fairwinds.com/enabled=true
라벨을 붙이는 순간, Controller가 해당 네임스페이스의 모든 워크로드에 대해 VPA 오브젝트를 자동 생성합니다.
# VPA 오브젝트 생성 확인
kubectl get vpa -n default
Step 4 — 대시보드 접속
kubectl -n goldilocks port-forward svc/goldilocks-dashboard 8080:80
브라우저에서 http://localhost:8080 접속. VPA가 충분한 데이터를 수집하면(보통 수 분~수십 분) 각 컨테이너별 권고값이 표시됩니다.
대시보드에서 확인할 수 있는 정보:
| 항목 | 설명 |
|---|---|
| Guaranteed QoS | requests = limits로 설정할 때의 권고값 |
| Burstable QoS | requests만 설정하고 limits는 별도 정책으로 관리할 때의 권고값 |
| 현재 설정값 | 현재 Deployment에 설정된 requests/limits |
| Lower Bound | 안전한 최솟값 |
| Upper Bound | 피크 기준 최댓값 |
5. 주의사항: "그대로 적용"은 금물
Goldilocks가 보여주는 값은 **시작점(starting point)**입니다. 프로덕션에 그대로 복사-붙여넣기 하면 안 되는 이유가 있습니다.
관측 기간이 짧으면 권고값이 낮게 나옵니다. 트래픽이 몰리는 월말 정산 시즌, 배치 작업 실행 시점, 장애 상황의 재처리 등 피크 구간이 VPA 데이터에 충분히 반영되지 않을 수 있습니다. 최소 1~2주 이상의 관측 기간을 확보한 뒤 적용을 검토하는 것이 안전합니다.
또한 Goldilocks는 리소스 설정의 의사결정을 지원하지, 자동으로 배포를 변경하지 않습니다. 권고값을 보고 팀이 판단하고, GitOps 파이프라인을 통해 적용하는 방식이 권장됩니다.
6. 폐쇄망 환경에서의 의미
PAASUP DIP처럼 외부 인터넷이 차단된 폐쇄망(air-gapped) 환경에서는 리소스 최적화의 중요성이 더욱 높아집니다.
퍼블릭 클라우드에서는 노드를 늘리는 것이 몇 분 안에 가능합니다. 하지만 온프레미스 환경에서 서버를 추가하려면 도입 예산, 구매 절차, 납품 기간이 필요합니다. 즉 주어진 하드웨어로 최대한 효율적으로 운영하는 것이 유일한 답입니다.
Spark 워크로드, Flink 실시간 처리, StarRocks 쿼리 엔진, Milvus 벡터 검색 — DIP 위에서 돌아가는 각 컴포넌트의 리소스 설정이 정교할수록 동일한 클러스터에서 더 많은 워크로드를 안정적으로 수용할 수 있습니다.
Goldilocks는 그 정교함을 감각이 아닌 데이터로 만들어주는 도구입니다.
마치며
리소스 설정은 "한 번 정하면 끝"이 아닙니다. 워크로드가 바뀌고, 데이터 볼륨이 늘고, 사용 패턴이 변합니다. Goldilocks를 주기적으로 확인하는 것을 팀의 운영 루틴으로 만드는 것만으로도 클러스터 효율이 눈에 띄게 달라집니다.
동화 속 골디락스가 "너무 뜨겁지도, 너무 차갑지도 않은" 적당한 죽을 찾았던 것처럼 - 지금 여러분의 클러스터도 딱 맞는 리소스 설정을 찾을 준비가 되어 있습니다.