[k8s] Resource Requirements&limits

1. 요청과 제한이란?

1️⃣ Resource Requests (리소스 요청)

• Pod(혹은 컨테이너)가 최소한으로 보장받아야 하는 CPU/메모리 양을 의미.
• 스케줄링 시점에 사용됨.
  • Kubernetes 스케줄러는 Pod이 요청한 리소스(requests)만큼을 반드시 확보할 수 있는 노드를 찾아서 배치.
  • 만약 노드에 여유 리소스가 충분하지 않으면 Pod은 Pending 상태로 남음.
• Pod이 실행 중일 때, 이 요청량을 우선적으로 보장해줌(특히 CPU의 경우).

2️⃣ Resource Limits (리소스 제한)

• Pod(혹은 컨테이너)가 소비할 수 있는 CPU/메모리의 최대치를 의미.
• 런타임 시점에 사용됨.
  • CPU 제한이 있으면 해당 한계를 넘어서는 CPU 사용이 불가능(시스템이 CPU 사용을 throttle).
  • 메모리 제한이 있으면 해당 한계를 넘어가면 OOM(Out Of Memory) 에러로 Pod이 종료됨.

2. CPU & 메모리 단위

1️⃣ CPU 단위

• 1 CPU = 1 vCPU (가상 CPU)
  • 클라우드(예: AWS)에서는 1 vCPU = 1 코어,
  • 실제 하드웨어에서는 1 하이퍼스레드로 볼 수 있음.
• 소수점 사용 예시:
  • 0.5 → 0.5개의 vCPU
  • 0.1 → 0.1개의 vCPU
• milli 단위 사용 (m):
  • 100m = 0.1 CPU
  • 500m = 0.5 CPU
• 최소값은 1m(0.001 CPU)까지 설정 가능.

2️⃣ 메모리 단위

• M(메가바이트) vs Mi(메비바이트)
  • 1 Mi = 1 Mebibyte = 1024 * 1024 bytes
  • 1 M = 1 Megabyte = 1000 * 1000 bytes
• 예시:
  • 256Mi = 약 256 * 1024 * 1024 bytes
  • 256M = 256 * 1000 * 1000 bytes

3. Pod에 요청과 제한 설정하기

Pod(또는 Container) 스펙에서 resources.requests와 resources.limits를 지정할 수 있음.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          cpu: "0.5"       # 최소 0.5 CPU 보장
          memory: "256Mi"  # 최소 256Mi 보장
        limits:
          cpu: "1"         # 최대 1 CPU만 사용 가능
          memory: "512Mi"  # 최대 512Mi까지만 사용

📌 동작 방식 요약

1. 스케줄러는 requests 기준으로 노드 여유 리소스가 충분한지 판단 후 Pod 배치.
2. 노드에 배치된 후,
   • CPU는 limits까지 사용 가능하되, 초과분은 자동으로 제한(throttle) 됨.
   • 메모리는 limits를 초과하면 OOM(Out Of Memory) 에러로 Pod이 Kill됨.

4. 다양한 케이스별 리소스 설정 예시

Case A: Request와 Limit이 모두 없는 경우

• 기본값: Pod은 원하는 만큼 CPU/메모리를 사용 가능.
• 한 Pod이 노드 리소스를 독점할 수 있어, 다른 Pod이 리소스 부족에 시달릴 수 있음.

Case B: Request 없이 Limit만 설정된 경우

• Kubernetes는 Request = Limit로 간주.
• 즉, Pod은 정해진 limit 만큼만 사용 가능하고, 그보다 적어도 스케줄링 시에는 무조건 Limit만큼을 필요로 하는 것으로 계산됨.
• 서로 다른 Pod이 동일한 Limit이라면, 각 Pod이 노드에서 동일한 정해진 자원을 요구.

Case C: Request와 Limit이 모두 설정된 경우

• 각 Pod은 Request만큼을 반드시 보장받고, 최대 Limit까지만 사용 가능.
• CPU의 경우 사용 가능 여유가 있어도 한 Pod이 Limit 이상 쓸 수 없으므로,유휴 리소스가 있어도 활용을 못하는 단점이 있을 수 있음.
• 메모리는 Limit을 초과하면 OOM Kill 발생.

Case D: Request만 설정하고 Limit은 없는 경우 (가장 유연)

• 각 Pod은 최소한의 Request 자원을 보장받음.
• 남는 리소스가 있을 경우, 해당 Pod이 추가로 사용 가능.
• CPU는 필요 시 자유롭게 가져다 쓸 수 있고, 메모리는 실제 사용이 많으면 노드에서 자원이 소진될 수 있음(메모리는 제한이 없으므로).
• 메모리는 수정이 불가하기 때문에, Pod를 죽여야 다른 파드에 메모리 할당이 가능.

5. LimitRange(리소스 기본값 설정)

네임스페이스 단위로 Pod이나 Container가 생성될 때 기본 Requests/Limits 값을 설정하거나 최소/최대 허용치를 강제할 수 있음.

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
    - type: Container
      max:
        cpu: "1"        # 각 Container는 최대 1 CPU까지 limit 설정 가능
      min:
        cpu: "100m"     # 최소 0.1 CPU는 되어야 한다
      default:
        cpu: "500m"     # 명시적 설정이 없으면 기본 request가 0.5 CPU
      defaultRequest:
        cpu: "300m"     # 명시적 설정이 없으면 기본 request가 0.3 CPU

✔️ 동작 방식

• Pod/Container 생성 시 requests나 limits를 명시하지 않았다면, LimitRange에 정의된 default 값을 적용.
• max, min이 있으면 수동으로 설정한 값이 그 범위를 벗어나면 생성이 거부됨(오류 발생).

6. ResourceQuota(네임스페이스별 전체 리소스 제한)

네임스페이스 전체에 대해 Pod들이 사용 가능한 리소스 총량을 제한할 수 있음.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "4Gi"
    limits.cpu: "10"
    limits.memory: "10Gi"

• 해당 네임스페이스에서 생성된 모든 Pod의 CPU requests 합이 4를 넘어가면 생성 불가.
• CPU limits 합이 10을 넘어가면 안 됨.
• 마찬가지로 메모리는 requests 4Gi, limits 10Gi를 초과할 수 없음.

📌 주요 포인트

• ResourceQuota는 네임스페이스 단위로 적용됨.
• 여러 팀(다른 네임스페이스)이 하나의 클러스터를 공유할 때, 한 네임스페이스가 과도하게 리소스를 소비하는 것을 방지 가능.

7. 종합 정리 & 팁

1. 요청(requests)
   • Pod이 최소한으로 필요한 리소스
   • 스케줄러가 노드에 배치할 때 이 값을 기준으로 판단함.
   • 보장(Guarantee) 기능이 있어, 다른 Pod이 리소스를 많이 써도 내가 요청한 만큼은 확보 가능.
2. 제한(limits)
   • Pod이 최대한으로 사용할 수 있는 리소스
   • CPU는 limit 초과 시 throttle 적용, 메모리는 limit 초과 시 OOMKill 발생.
3. 요청과 제한 설정 패턴
   • Request만 설정, Limit 없음: 유연성 최대화 (Pod이 필요할 때 더 많이 사용 가능)
   • Request와 Limit 모두 설정: 보장 + 제한 (OOM 또는 throttle을 통해 전체 안정성 확보)
   • LimitRange: Pod 생성 시 기본 요청/제한 혹은 최대/최소 허용치 설정 (네임스페이스 단위)
   • ResourceQuota: 네임스페이스 단위로 전체 리소스 소비 총량 제한
4. 실무 팁
   • 기본적으로 모든 Pod이 request를 가지도록 설정(CPU/메모리 부족 사태 방지).
   • limit은 CPU보다 메모리에 더 자주 설정함(메모리는 throttle 불가능하므로).
   • dev/test 환경에서는 유연성을 위해 request만 두는 경우도 있음.
   • prod 환경에서는 request와 limit를 잘 조정해야 리소스 낭비와 OOM을 방지 가능.

---

결론

• Kubernetes 리소스 관리는 Pod의 안정적 동작과 클러스터 전체 자원 효율성을 위해 매우 중요.
• requests와 limits를 제대로 이해하고, LimitRange와 ResourceQuota를 조합해서 사용하면,다양한 사용 시나리오(테스트/프로덕션/멀티테넌트 환경)에서 리소스 경쟁을 효과적으로 제어 가능.

이해 포인트:

1. requests: 스케줄링 & 최소 보장
2. limits: 런타임 최대치(초과 시 CPU는 스로틀, 메모리는 OOMKill)
3. LimitRange: 네임스페이스 내 기본값 & 최소/최대 제한 자동화
4. ResourceQuota: 네임스페이스 전체 리소스 사용량 제한