CPU/memory의 request와 limit의 차이는 무엇이며, 스케줄링, eviction, QoS에 어떻게 영향을 주는가?

Question

IT Interview Practice · Accepted Answer

**Request**는 컨테이너에게 *보장되는* 것이고(스케줄링에 사용); **limit**은 초과할 수 없는 *상한*이다(런타임에 강제됨). 둘이 함께 Pod가 어디에 배치되는지, 압박 상황에서 어떻게 throttle되거나 죽는지, 그리고 Pod가 어떤 **Quality of Service (QoS)** 클래스를 받는지를 결정한다.

## Request vs limit

```text
REQUEST → 컨테이너에게 예약된(RESERVED) 양. SCHEDULER는 request의 합을 사용해
          노드에 자리가 있는지 결정한다. 이것이 당신의 보장된 하한이다.
LIMIT   → 컨테이너가 사용할 수 있는 최대치. 런타임에 강제:
          CPU가 limit 초과    → THROTTLED (느려짐, 죽지는 않음)
          memory가 limit 초과 → OOM-KILLED (컨테이너 종료 후 재시작)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 코어의 0.25, 보장됨
          memory: "256Mi"
        limits:
          cpu: "500m"        # 0.5 코어까지 버스트 가능, 이후 throttle
          memory: "512Mi"    # 이를 초과하면 → OOMKilled
```

## 스케줄링이 request를 사용하는 방식

```text
노드가 4 CPU / 8Gi 할당 가능.
Scheduler는 이미 배치된 Pod들의 REQUEST를 합산한다; 새 Pod는 그 request가
남은 용량에 맞을 때만 들어간다. (limit은 배치에 사용되지 않는다.)
→ request를 너무 낮게 설정 → 노드 오버커밋, Pod들이 리소스를 두고 다툼.
→ request를 너무 높게 설정 → 용량 낭비, Pod가 Pending에 멈춤 (맞는 게 없음).
```

## QoS 클래스 (메모리 압박 시 eviction 순서를 결정)

```text
Guaranteed  → cpu & memory 둘 다 request == limit (모든 컨테이너)
              → 마지막으로 evict됨 (최고 우선순위)
Burstable   → request가 있지만 limit보다 작음 (또는 부분적으로 설정)
              → BestEffort 다음으로 evict됨
BestEffort  → request도 limit도 전혀 없음
              → 노드의 메모리가 부족해지면 가장 먼저 evict됨
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # 실제 CPU/memory 사용량
kubectl describe node <node>               # 할당된 리소스 vs 용량
```

## 실무 지침

```text
✓ 중요한 앱에서는 예측 가능하고 OOM-안전한 동작을 위해 항상 memory request = limit
✓ CPU request는 정상 상태 필요치로 설정; CPU limit은 버스트 허용을 위해 종종 생략
✓ 추측이 아니라 실제 사용량(kubectl top / metrics)으로 적정 크기 산정
✓ LimitRange / ResourceQuota로 namespace별 합리적 기본값 강제
```

## 왜 중요한가

Request와 limit은 Kubernetes가 유한한 노드 리소스를 공정하고 예측 가능하게 공유하는 방식이므로, 그 구분과 결과를 이해하는 것은 필수적인 성능·신뢰성 지식이다. 핵심 통찰은 둘이 다른 목적을 가진다는 것이다: **request**는 **scheduler**가 Pod를 배치하는 데 사용하는 보장된 예약이고(request를 합산하여 노드에 자리가 있는지 결정하며, limit은 무시), **limit**은 리소스마다 다르게 강제되는 런타임 상한이다 — **CPU** limit 초과는 **throttle**(느려짐)되지만, **memory** limit 초과는 컨테이너가 **OOM-kill**되고 재시작된다. request를 잘못 잡으면 양쪽 다 실제 비용이 든다: 너무 낮으면 노드가 오버커밋되어 Pod들이 서로를 굶기고; 너무 높으면 맞는 게 없어 Pod가 Pending에 앉아 용량이 낭비된다. 세 가지 **QoS 클래스** — Guaranteed(request가 limit과 같음), Burstable(request가 limit보다 낮음), BestEffort(아무것도 설정 안 함) — 는 메모리 압박 하의 eviction 순서를 결정하는데, BestEffort가 먼저 죽고 Guaranteed가 마지막에 죽으며, 이것이 바로 중요한 워크로드를 보호하기 위해 이해해야 할 부분이다. 실무 지침(중요한 앱은 memory request를 limit과 같게, `kubectl top`으로 실제 사용량 기반 적정 크기 산정, LimitRange/ResourceQuota로 기본값 강제)을 아는 것은 이를 이론에서 건전한 용량 계획으로 바꾼다. 리소스 오설정은 실제 클러스터에서 불안정, 낭비 지출, Pending Pod의 가장 흔한 원인 중 하나이므로, request, limit, QoS를 숙달하는 것은 효율적이고 안정적인 Kubernetes 워크로드를 실행하는 데 기초가 된다.

Request vs limit

스케줄링이 request를 사용하는 방식

QoS 클래스 (메모리 압박 시 eviction 순서를 결정)

실무 지침

왜 중요한가

관련 질문