🧪 EKS에서 Goldilocks 시도기: 감이 아닌 데이터로 Request/Limit 확인해보기

✅ 배경: 리소스 설정, 왜 중요한가?

Kubernetes에서 Pod의 requests와 limits는

서비스의 안정성과 클러스터 비용 효율성에 핵심적인 역할을 합니다.

하지만 현실은…

“CPU는 그냥 500m 정도 주면 되지 않을까?”

“메모리는 넉넉하게 1Gi?”

이런 감각적 추정에 의존한 리소스 설정은 다음과 같은 문제를 초래합니다:

• 과잉 설정 → 낭비되는 클러스터 리소스, 높은 비용
• 과소 설정 → OOMKilled, CPU Throttling 발생

그래서 이를 데이터 기반으로 개선하기 위한 도구로 Goldilocks를 시도해보았습니다.

---

🧸 Goldilocks란?

Goldilocks는

VPA(Vertical Pod Autoscaler) 를 활용하여

Pod의 실제 리소스 사용량을 수집하고, 이를 기반으로 Request/Limit 추천 값을 제시해주는 도구입니다.

🎯 목표: 너무 많지도, 너무 적지도 않은

---

🛠️ Step 1: VPA 수동 설치

VPA 리포를 직접 클론하여 수동 설치했습니다.

git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler/
./hack/vpa-up.sh

---

🧪 Step 2: Goldilocks 설치 (VPA 자동 조정 OFF)

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm repo update

helm install goldilocks fairwinds-stable/goldilocks \
  --namespace goldilocks --create-namespace \
  --set controller.vpa.enabled=true \
  --set controller.vpa.updateMode=Off

📌 updateMode=Off를 설정한 이유: 실 운영 중인 리소스를 VPA가 자동 조절하지 않도록 막고 추천 값만 참고한 후 수동 적용

---

🔎 Step 3: 대시보드 확인 (포트포워드 방식)

kubectl port-forward -n goldilocks svc/goldilocks-dashboard 8080:80

웹 브라우저에서 http://localhost:8080 접속하여 대시보드 확인 가능.

📌 분석 대상 네임스페이스에 라벨 지정:

kubectl label ns <네임스페이스명> goldilocks.fairwinds.com/enabled=true

---

🔍 관찰 결과 및 인사이트

항목	내용
리소스 설정	일부 서비스는 과도하게 높게 설정됨 (예: CPU 1 → 실제 사용 0.1)
추천 범위	Lower / Target / Upper 값으로 다양하게 제시됨
적용 전략	Helm chart 또는 Kustomize를 통해 향후 수동 반영 예정
안정성	updateMode=Off 설정으로 운영 리스크 없이 분석 가능

---

📌 정리 및 느낀 점

• Goldilocks는 매우 직관적이고 빠르게 사용 가능한 도구
• VPA는 수동 설치로도 무리 없이 구성 가능
• 분석 결과를 기반으로 팀 내 협의 후 점진적 적용을 고려 중
• 실 운영환경에 적용 전, updateMode=Off 설정이 안정적 접근법

---

✍️ 마무리

이번 시도는 운영 리소스를 안정적으로 분석하고 개선 방향을 모색할 수 있는 첫 단계였습니다.

Goldilocks는 생각보다 쉽게 도입할 수 있었고,

VPA + updateMode=Off 조합은 실무 환경에서도 안정성과 유용성을 모두 확보할 수 있는 방식이라 판단됩니다.

---

🔗 참고 링크

• Goldilocks GitHub
• VPA 공식 문서

---