kubernetes에서 Pod requests / limits Tunning

실사용량 대비 Best Practice와 운영 튜닝 방법 정리

Kubernetes를 운영하다 보면 거의 반드시 마주치는 질문이 있다.

“Pod의 CPU / Memory requests 와 limits를 실제 사용량 대비 어느 정도로 잡는 게 맞을까?”

이 글에서는

• 숫자로 보는 Best Practice
• 운영에서 실제로 조절하는 방식
• 자주 터지는 함정들

을 표 중심으로 정리한다.

---

1️⃣ requests / limits 역할 한 번에 정리

 

구분	역할	운영에서 의미
requests	스케줄러 기준 예약값	노드 배치, 오토스케일 판단 기준
CPU limit	CPU 상한	초과 시 throttling (지연 증가)
Memory limit	메모리 상한	초과 시 OOMKill (컨테이너 재시작)

핵심 요약

• requests = “이 Pod가 최소로 필요함”
• limits = “이 이상 쓰면 제재”

---

2️⃣ 실사용량 대비 권장 비율 (가장 중요한 표)

CPU / Memory 권장 시작점

 

리소스	requests 기준	limits 기준	실무 코멘트
CPU	실사용 P50 ~ P70	❌ 없거나 매우 크게	CPU limit은 지연의 주범
Memory	실사용 P70 ~ P90	request의 1.2 ~ 1.5배	OOM 방어용 limit 필수

📌 결론 한 줄

• CPU는 requests 중심
• Memory는 limit 필수

---

3️⃣ 왜 CPU limit을 안 두는 게 유리한가?

CPU throttling 문제 요약

 

상황	결과
CPU limit 도달	CFS throttling 발생
평균 CPU 낮음	그래도 순간 스파이크에서 지연 발생
API 서버	p99 latency 급증
원인 분석	로그/지표로 찾기 매우 어려움

그래서 실무 패턴은:

 

항목	권장
CPU request	명확히 설정
CPU limit	제거하거나 충분히 크게
보호 방식	HPA + 노드 오토스케일

---

4️⃣ QoS 클래스 관점에서 보는 전략

 

QoS	조건	언제 쓰나
Guaranteed	request = limit	핵심 인프라, 안정성 최우선
Burstable	request < limit	대부분의 서비스
BestEffort	설정 없음	운영에선 거의 금지

운영 클러스터에서는

❌ BestEffort → 사고 유발

⭕ Burstable 기본, 일부만 Guaranteed

---

5️⃣ 실제 운영에서 조절하는 흐름 (중요)

운영 튜닝 사이클

 

단계	내용
1️⃣ 측정	CPU/Memory 실제 사용량 수집
2️⃣ 초기값	보수적 requests / 안전한 memory limit
3️⃣ 관측	1~3일 또는 1주 데이터
4️⃣ 조정	P50/P90 기준 재조정
5️⃣ 반복	릴리즈/트래픽 변화 시 반복

---

6️⃣ 운영에서 보는 핵심 지표 정리

 

리소스	반드시 볼 것	의미
CPU	usage, throttling	limit 정책 재검토 신호
Memory	working set, OOMKill	limit 부족 여부
Pod	restarts	메모리 문제 의심
Node	allocatable 대비 requests	과예약 여부

---

7️⃣ VPA를 이용한 자동 추천 (운영 현실 해법)

VPA 사용 패턴 (추천)

 

단계	설정
1단계	updateMode: Off
2단계	Recommendation 확인
3단계	수동 반영
4단계	일부 워크로드만 Auto

⚠️ 주의

• VPA는 Pod 재시작이 발생할 수 있음
• HPA와 동시에 CPU 기준 Auto는 충돌 가능

---

8️⃣ 서비스 유형별 리소스 전략

유형별 Best Practice

 

서비스 유형	CPU	Memory
API / 실시간	limit 제거	limit 필수
배치 / 워커	limit 허용	limit 필수
JVM	CPU limit 신중	heap = limit의 70~80%
캐시성	CPU 여유	memory 넉넉히

---

9️⃣ 자주 터지는 운영 함정 (체크리스트)

 

실수	결과
requests 과대	Pod Pending / 비용 폭증
CPU limit 과소	latency 폭발
Memory limit 과소	OOMKill 반복
requests 미설정	노이즈 / 오토스케일 실패

---

🔟 바로 써먹는 운영 기본 규칙 요약표

 

항목	운영 원칙
CPU request	P50 ~ P70
CPU limit	기본 제거
Memory request	P70 ~ P90
Memory limit	request × 1.2~1.5
QoS	Burstable 기본
조정 주기	릴리즈 후 1~3일

---

마무리

Kubernetes 리소스 튜닝에는 정답은 없지만,

❌ “대충 크게”

❌ “처음 정하고 방치”

이 두 가지만 피해도 비용·안정성·성능이 동시에 좋아진다.

requests는 계획, limits는 안전장치

이 관점만 유지해도 운영 난이도가 확 내려간다.