전체 비유: 아파트 전기/수도 배정#

리소스 관리를 아파트 전기/수도 배정에 비유하면 이해하기 쉽습니다:

이처럼 requests는 “항상 보장받는 기본 전기량"이고, limits는 “절대 넘을 수 없는 최대 사용량"입니다.

대상 독자: Kubernetes에서 리소스를 효율적으로 관리하고 싶은 백엔드 개발자 선수 지식: Pod, Deployment 개념 소요 시간: 약 25-30분 이 문서를 읽으면: requests와 limits의 차이, 적절한 리소스 설정 방법을 이해할 수 있습니다

TL;DR

• requests: 스케줄링에 사용되는 최소 보장 리소스
• limits: 사용 가능한 최대 리소스
• CPU 초과 시 스로틀링, 메모리 초과 시 OOMKilled

왜 리소스 설정이 필요한가?#

리소스 설정 없이 Pod를 실행하면 여러 문제가 발생합니다.

requests와 limits#

Kubernetes는 두 가지 리소스 제어 방식을 제공합니다.

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

flowchart LR
    subgraph Resources
        REQ[requests: 256Mi]
        USE[실제 사용량]
        LIM[limits: 512Mi]
    end
    REQ -->|보장| USE
    USE -->|제한| LIM

requests와 limits를 비교하면 다음과 같습니다.

CPU 리소스#

CPU는 압축 가능한(compressible) 리소스입니다. 초과해도 스로틀링될 뿐 종료되지 않습니다.

CPU 단위#

m은 밀리코어(millicores)를 의미합니다. 1000m = 1 CPU입니다.

CPU 동작#

flowchart LR
    subgraph "requests: 250m"
        A[Pod A]
    end
    subgraph "requests: 500m"
        B[Pod B]
    end
    CPU[1 CPU]
    A -->|보장 250m| CPU
    B -->|보장 500m| CPU
    CPU -->|남은 250m| C[경합]

메모리 리소스#

메모리는 압축 불가능한(incompressible) 리소스입니다. 초과하면 Pod가 종료(OOMKilled)됩니다.

메모리 단위#

Mi vs M
Mi(메비바이트)는 2^20 bytes, M(메가바이트)는 10^6 bytes입니다. Kubernetes에서는 보통 Mi, Gi를 사용합니다.

메모리 동작#

QoS 클래스#

Kubernetes는 리소스 설정에 따라 Pod에 QoS(Quality of Service) 클래스를 할당합니다.

# Guaranteed
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "250m"

# Burstable
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

# BestEffort (리소스 설정 없음)
# resources: {}

노드 메모리가 부족할 때 종료 순서는 다음과 같습니다.

flowchart LR
    M[메모리 부족] --> BE[BestEffort 먼저 종료]
    BE --> BU[Burstable 종료]
    BU --> GU[Guaranteed 마지막]

권장 설정#

워크로드 유형별 권장 설정#

실제 운영에서 자주 사용되는 워크로드 유형별 시작점입니다.

주의
위 값은 시작점입니다. 실제 사용량을 모니터링(kubectl top pods)하여 조정하세요.

Java 애플리케이션#

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "1000m"

Java 애플리케이션 특성상 메모리 limits는 넉넉히 설정하되, JVM 힙 사이즈도 함께 조정해야 합니다.

env:
- name: JAVA_OPTS
  value: "-Xms256m -Xmx768m"

JVM 힙은 컨테이너 메모리 limits의 70-80%로 설정하는 것이 일반적입니다.

리소스 설정 가이드라인#

LimitRange#

네임스페이스 수준에서 기본 리소스 제한을 설정합니다.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:          # 기본 limits
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:   # 기본 requests
      cpu: "100m"
      memory: "128Mi"
    max:              # 최대 허용
      cpu: "2"
      memory: "2Gi"
    min:              # 최소 허용
      cpu: "50m"
      memory: "64Mi"
    type: Container

리소스를 명시하지 않은 Pod에 기본값이 적용됩니다.

ResourceQuota#

네임스페이스 전체의 리소스 총량을 제한합니다.

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

이 설정은 해당 네임스페이스에서 다음을 제한합니다.

실습: 리소스 설정과 확인#

리소스 사용량 확인#

# 노드 리소스 확인
kubectl describe node <node-name>

# Pod 리소스 사용량 (metrics-server 필요)
kubectl top pods
kubectl top nodes

리소스 부족 시뮬레이션#

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

# Pod 생성
kubectl apply -f memory-demo.yaml

# 상태 확인 (OOMKilled 발생)
kubectl get pod memory-demo
kubectl describe pod memory-demo

QoS 클래스 확인#

kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'

다음 단계#

리소스 관리를 이해했다면 다음 단계로 진행하세요: