k8s Pod의 Resource Request와 Limit 측정 방법

k8s Pod에 적절한 resource request와 limit을 설정하는 것은 클러스터 안정성과 비용 효율성을 결정하는 핵심 작업입니다. 하지만 어떤 값을 기준으로 적절할 resource request와 limit을 설정해야 하는걸까요? 이번 글에서는 데이터 기반으로 정확하게 측정하고 설정하는 방법을 단계별로 안내합니다.

 

목 차

• 1. 초기 기준점 설정 (Educated Guess)
• 2. 테스트 환경에서 부하 테스트 및 측정
• 3. 프로덕션 환경에서 모니터링·지속 최적화
• 추가 팁 & 핵심 원칙
• 요약정리

 

1. 초기 기준점 설정 (Educated Guess)

데이터가 전혀 없는 상황에서는, 먼저 합리적인 추정치로 시작하는 것이 좋습니다. 개발자의 로컬PC를 기준으로 추정치를 확인하는 방법을 알아보겠습니다. 

 

가장 간단한 방법은 Windows작업관리자를 활용하는 것입니다. 간단하지만 트래픽에 대한 고려가 되지 않았으므로 초기 기준값 정도로만 활용하는것이 좋습니다. 

 

Windows 작업관리자를 통해 Resource 확인하기

 

1. 작업 관리자 열기 : Ctrl + Alt + Delete 를 누른 후 '작업관리자' 선택 
2. 애플리케이션 실행 : IDE 에서 개발중인 애플리케이션을 running 
3. [세부 정보]탭 클릭 : 애플리케이션의 CPU, 메모리 값 확인 
   • [프로세스] 탭에서 내 애플리케이션 이름 찾기
   • 해당 이름에서 마우스 오른쪽 버튼 클릭 -> 세부정보로 이동 선택
   • [세부 정보] 탭에 있는 프로세스가 자동 선택됨. 
4. 메모리 확인 방법
   • 메모리(활성 개인 작업 집합)인지 확인 : 앱이 단독으로 사용하는 실제 메모리 양을 의미. 
   • 해당열이 보이지 않을 경우 직접 추가 
   • 열 이름에서 마우스 오른쪽 버튼 클릭 > [열 선택] 클릭 > 항목 체크 후 [확인] 버튼 클릭

1. CPU 계산방법
   • CPU 사용량은 %로 조회되므로 계산해야함.
   • (측정된 CPU %) / 100 * (전체 코어 수) * 1000 
   • 예를들어 4core PC 에서 0.1% CPU 사용중일경우 
     0.1/100 * 4 * 1000 = 4m 
   • kubernetes resource 설정파일에 cpu 4m 로 기재

 

Windows 작업관리자를 통해 초기 CPU, Memory 값을 확인하였다면 다음과 같이 spec.resources 의 requests 값을 작성할 수 있습니다. 

resources: 
  requests:
    cpu: "200m" 
    memory: "256Mi" 
  limits: 
    cpu: "1" 
    memory: "1Gi"

 

2. 테스트 환경에서 부하 테스트 및 측정

가장 중요한 단계입니다. 실제처럼 부하를 주고 CPU 및 메모리 사용량을 측정하세요.

1. 측정 도구 준비:
   • Prometheus + Grafana: 클러스터의 Pod 리소스 시각화
   • k6, JMeter, Locust: 실제 트래픽 패턴 기반 부하 테스트
2. 측정 시나리오 실행:
   • 유휴 상태 측정: Idle 상태에서 CPU/메모리 평균값 확인 → 이 값이 request 기준
   • 최대 부하 측정: 동시 사용자 증가, 응답 지연 직전까지 부하 생성 → Peak 값이 limit 기준
3. 데이터 분석 및 설정:
   • requests: idle + 평균 사용량 + 20~30% 버퍼
   • limits: 부하 최대값 + 20~50% 버퍼

3. 프로덕션 환경에서 모니터링 및 최적화

테스트 후 설정한 값을 **프로덕션에 배포**하고, 실사용 데이터를 기반으로 지속적으로 조정하세요.

• 실사용량 모니터링: Prometheus + Grafana로 CPU, 메모리 실사용량 주시
• OOMKilled/CPU Throttling 확인:
  • `kubectl describe pod`에서 `OOMKilled` 상태 체크
  • Grafana에서 CPU Throttling 빈도 확인 → limit 재설정 고려
• 값 재조정:
  • requests가 실제보다 너무 크면 리소스 낭비 → 낮추기
  • limits에 도달하지 않으면 다른 Pod 활용을 위해 제한 낮춤 고려
  • OOMKilled 발생 시 메모리 누수 코드 점검 후 limit 상향

추가 팁 & 핵심 원칙

• 메모리와 CPU는 다르게 접근하세요:
  • 메모리(Memory)는 압축할 수 없는(incompressible) 리소스입니다. limits를 초과하면 Pod는 즉시 OOMKilled로 종료됩니다. 따라서 메모리 limits는 충분한 버퍼를 두는 것이 매우 중요합니다.
  • CPU는 압축 가능한(compressible) 리소스입니다. limits를 초과하면 Pod가 종료되지는 않지만, 해당 Pod의 CPU 사용량이 강제로 제한(throttling)되어 성능이 저하됩니다.
• 중요한 애플리케이션은 Guaranteed QoS 사용: 데이터베이스와 같이 안정성이 매우 중요한 Pod는 requests와 limits를 동일한 값으로 설정하여 Guaranteed QoS 클래스를 부여하는 것이 좋습니다. 이렇게 하면 Eviction 대상에서 가장 마지막 순위가 됩니다.
• VPA (Vertical Pod Autoscaler) 활용: 이 모든 과정을 자동화하고 싶다면 Vertical Pod Autoscaler를 도입하는 것을 고려할 수 있습니다. VPA는 Pod의 실제 사용량을 학습하여 최적의 requests와 limits를 자동으로 추천하거나 적용해줍니다.

 

요약정리

Pod의 리소스를 설정할 때, **“감”이 아니라 “데이터” 기반**으로 접근하는 것이 핵심입니다.

초기 추정→부하 테스트 기반 측정→프로덕션에서 모니터링 및 재조정의 3단계를 충실히 따라주세요.

메모리와 CPU는 성격이 다르므로 따로 고려하고, 중요한 서비스에는 Guaranteed QoS를 설정해 안정성을 높이세요.