[TIL]Kubernetes 리소스 단위, Requests & Limits-2025.09.04

TIL: Kubernetes 리소스 단위, Requests & Limits

1. 리소스 단위 (Mi, Gi)

• Mi (Mebibyte): 2^20 = 1,048,576 바이트
• Gi (Gibibyte): 2^30 = 1,073,741,824 바이트
• Kubernetes는 메모리 계산에서 **2진법 단위(Mi, Gi)**를 사용 → 자원 할당이 더 정확함.
• YAML 예시:

requests:
    memory: "64Mi"
    cpu:"250m"
limits:
  memory:"128Mi"
   cpu:"500m"

• 정리: M, G도 쓸 수 있지만 혼동 방지를 위해 Mi, Gi 명시하는 것이 권장됨.

 

2. Requests (요청)

• 의미: 컨테이너가 최소한으로 필요한 자원 (보장선)
• 역할:
  1. 안정적인 성능 보장: noisy neighbor Pod로부터 보호
  2. 애플리케이션 시작 보장: 최소 메모리 확보 없으면 OOMKilled
  3. 자원 효율화: 스케줄러가 테트리스처럼 자원 빈틈없이 배치
  4. 서비스 우선순위 확보: QoS 등급 결정 (BestEffort < Burstable < Guaranteed)

예시:

requests:
   cpu:"500m"
   memory:"1Gi"

 

3. Limits (제한)

• 의미: 컨테이너가 최대 사용할 수 있는 자원의 상한선
• 역할:
  1. 자원 독점 방지 → 다른 Pod와 노드 보호
  2. 노드 안정성 유지 → 폭주/버그 방어
• 초과 시 동작:
  • CPU: throttling (성능 저하, 종료 X)
  • Memory: OOMKilled (프로세스 강제 종료)
• QoS 클래스에 영향:
  • Guaranteed: requests=limits
  • Burstable: requests < limits
  • BestEffort: 둘 다 없음

 

4. 종합 정리

 

구분	Requests (요청)	Limits (제한)
목적	최소 실행 환경 보장	비정상 자원 사용 방지
작동 시점	스케줄링 (배치 기준)	실행 중 (노드 내 강제 제어)
초과 시 동작	(초과 개념 없음)	CPU: 성능 저하 / Mem: OOMKilled
주체	kube-scheduler	kubelet

5. 배운 점 & 느낌

• requests는 “최소 확보”, limits는 “최대 차단”이라는 개념으로 이해하면 직관적이다.
• 단순히 컨테이너 성능 제어를 넘어서, 클러스터 전체 안정성·비용 최적화·우선순위 관리와 직결된다.
• 특히 메모리는 CPU와 다르게 초과 사용이 불가능해서, limits를 반드시 신중히 잡아야 한다는 점이 인상적이었다.
• 앞으로 YAML 작성할 때는 무조건 requests를 설정하고, 운영 환경에서는 requests=limits(Guaranteed)로 안정성을 확보하는 게 좋겠다.

 

Kubernetes 리소스 관리 = “자원 단위(Mi/Gi) 정확히 → requests로 보장 → limits로 차단”
이 삼박자가 맞아야 예측 가능한 안정적인 서비스 운영이 가능하다.