클라우드/Kubernetes

Kubernetes 리소스 요청(requests)과 제한(limits)의 차이 완벽 정리

Jinwookoh 2025. 5. 4. 13:55

 

쿠버네티스(Kubernetes)에서 Pod를 생성할 때 가장 중요한 설정 중 하나는 리소스(Resource) 설정입니다. 특히 requests와 limits는 클러스터 자원을 어떻게 할당하고 제어할지를 결정하는 핵심 요소입니다. 이번 글에서는 아래의 예제를 기준으로 이 두 설정의 의미와 차이를 자세히 설명드리겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-conflict-with-limitrange-cpu
spec:
  containers:
  - name: demo
    image: smlinux/pause:2.0
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 500m
        memory: 100Mi

📌 requests와 limits란?

Kubernetes에서 resources.requests와 resources.limits는 다음과 같은 역할을 합니다.

✅ requests (요청 자원)

  • 컨테이너가 최소한으로 보장받는 자원량입니다.
  • 스케줄러가 파드를 노드에 할당할 때 이 값을 기준으로 리소스를 고려합니다.
  • 즉, cpu: 500m라고 설정하면 이 컨테이너는 최소 0.5개의 CPU가 보장됩니다.

✅ limits (제한 자원)

  • 컨테이너가 최대로 사용할 수 있는 자원량의 상한선입니다.
  • 이 값 이상을 사용하려 하면 제한되거나 종료될 수 있습니다.
    • CPU는 사용이 제한될 뿐 throttling(속도 제한)이 걸림.
    • Memory는 limits를 초과할 경우 컨테이너가 OOMKilled(메모리 초과 종료)됩니다.

🧠 CPU 500m의 의미

  • 500m은 millicore 단위로, 1000m = 1 CPU입니다.
  • cpu: 500m은 0.5개의 CPU를 의미합니다.
  • 예를 들어, 2코어 CPU가 장착된 노드라면 총 2000m까지 할당이 가능합니다.

🔍 참고: Kubernetes에서는 millicore 단위를 사용해 정밀한 리소스 할당이 가능합니다.


💡 예제 분석

해당 YAML 예제는 다음과 같은 의미를 가집니다:

  • Pod 이름: example-conflict-with-limitrange-cpu
  • 컨테이너 이름: demo
  • 이미지: smlinux/pause:2.0 (아무 작업도 하지 않는 기본 컨테이너)
  • 리소스 요청(requests):
    • CPU: 500m (0.5코어 보장)
  • 리소스 제한(limits):
    • CPU: 500m (최대 0.5코어만 사용 가능)
    • Memory: 100Mi (최대 100MiB 메모리 사용 가능)

따라서 이 파드는 클러스터 내에서 0.5개의 CPU와 100MiB 메모리만을 사용할 수 있으며, 그 이상은 절대 초과할 수 없습니다.
(CPU는 바로 kill 시키지는 않지만 메모리는 kill 시킴, 제한이 없으면 제일 먼저 제거 대상이 됨)


⚠️ LimitRange와의 충돌 가능성

예제 이름이 example-conflict-with-limitrange-cpu인 이유는, 클러스터에 LimitRange 리소스가 존재할 경우 아래와 같은 충돌이 발생할 수 있기 때문입니다:

  • 예: LimitRange가 CPU 요청을 최소 1000m로 요구하면, 위 예제의 cpu: 500m은 거절됩니다.

이럴 때는 다음과 같은 에러가 발생합니다:

pods "example-conflict-with-limitrange-cpu" is forbidden: minimum cpu request of 1 not satisfied

✍️ 마무리: 올바른 리소스 설정 전략

  • 개발 환경에서는 requests는 낮게, limits는 적당히 설정해 리소스를 유연하게 사용하는 것이 좋습니다.
  • 운영 환경에서는 requests = limits로 고정하면 성능 안정성과 자원 예측 가능성을 높일 수 있습니다.
  • LimitRange를 통해 네임스페이스 별 최소/최대 리소스 규칙을 설정하면 운영상 실수를 줄일 수 있습니다.