쿠버네티스 실습: 리소스 Requests & Limits와 Pod QoS Class 이해하기

쿠버네티스 실습: 리소스 Requests & Limits와 Pod QoS Class 이해하기

앞선 글에서는 Liveness/Readiness Probe로 애플리케이션 상태를 자동으로 감지하고, 준비되지 않은 Pod를 트래픽에서 제외하거나 죽은 컨테이너를 자동 재시작하는 방법을 실습했습니다.
이번 글에서는 리소스 관리의 핵심인 Requests와 Limits를 설정해보고, 쿠버네티스가 Pod를 어떻게 분류(QoS Class)하는지 실습합니다.

---

1) 왜 리소스 Requests와 Limits가 중요한가?

• Requests: Pod가 구동될 때 최소한으로 필요한 리소스.
  → 스케줄러가 이 값을 기준으로 어느 노드에 배치할지 결정.
• Limits: Pod가 사용할 수 있는 최대치.
  → 컨테이너가 이 값을 넘으면 CPU는 throttling(속도 제한), 메모리는 OOMKilled(강제 종료).

설정하지 않으면?

• Pod가 필요 이상으로 리소스를 잡아먹거나,
• 노드에 리소스가 부족해져 다른 Pod가 스케줄링되지 못하는 상황 발생.

---

2) Requests & Limits 설정 예시

nestjs-deployment.yaml 일부 수정:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nestjs-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nestjs
  template:
    metadata:
      labels:
        app: nestjs
    spec:
      containers:
      - name: nestjs
        image: <DOCKER_USERNAME>/nestjs-app:latest
        ports:
        - containerPort: 3000
        resources:
          requests:
            cpu: "250m"      # 최소 0.25 CPU
            memory: "256Mi"  # 최소 256MB 메모리
          limits:
            cpu: "500m"      # 최대 0.5 CPU
            memory: "512Mi"  # 최대 512MB 메모리

적용:

kubectl apply -f nestjs-deployment.yaml

확인:

kubectl describe pod <POD_NAME> | grep -A5 "Limits"

출력 예시:

Limits:
  cpu:     500m
  memory:  512Mi
Requests:
  cpu:     250m
  memory:  256Mi

---

3) Pod QoS Class

반응형

쿠버네티스는 Pod를 다음 세 가지 QoS(Quality of Service) 클래스로 분류합니다.

1. Guaranteed
   • 모든 컨테이너에 requests와 limits가 동일하게 설정된 경우.
   • 가장 높은 우선순위, 자원 보장이 확실.
2. Burstable
   • requests와 limits가 다르거나 일부만 지정된 경우.
   • 기본적으로 이 클래스가 가장 많음.
3. BestEffort
   • requests/limits가 전혀 없는 경우.
   • 리소스가 부족하면 가장 먼저 축출(evict)됨.

확인 명령어:

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

---

4) CPU/메모리 사용량 테스트

Pod 내부에 들어가서 메모리를 의도적으로 초과해봅니다.

kubectl exec -it <POD_NAME> -- /bin/sh

메모리 폭주 시뮬레이션(노드에 따라 조정 필요):

head -c 700M </dev/zero | tail

→ Pod가 강제로 종료되고 상태가 OOMKilled로 표시됩니다.

kubectl get pods
kubectl describe pod <POD_NAME> | grep -A3 "Last State"

---

5) 구조 이해

• 스케줄링 단계: Requests 값이 기준.
• 실행 중: Limits를 초과하면 CPU는 throttling, 메모리는 OOMKill.
• 자원 부족 상황: QoS Class가 낮은 Pod부터 제거.

즉, Requests = 최소치, Limits = 최대치, QoS Class = 우선순위.

---

6) 정리

• Requests와 Limits를 설정해야 리소스를 예측 가능하게 운영할 수 있음.
• QoS Class는 자원 부족 시 어떤 Pod를 살릴지 결정하는 기준.
• 실습을 통해 OOMKill, throttling 같은 현상을 직접 확인 가능.

다음 글에서는 쿠버네티스 네임스페이스와 RBAC(Role-Based Access Control) 기초를 실습해, 여러 팀/서비스가 같은 클러스터를 사용할 때 어떻게 권한을 나누는지 배워보겠습니다.

---

 

쿠버네티스,리소스관리,Requests,Limits,PodQoS,DevOps,클라우드네이티브,컨테이너운영,Minikube,K8s실습

 

 

보강을 추천드리는 핵심 포인트

1. QoS 분류 기준의 공식 정의 추가

QoS Class는 단순하게 요청/한도 설정 여부가 아니라 다음과 같이 구체적으로 지정됩니다:

• Guaranteed: 모든 컨테이너가 CPU 및 메모리 요청(requests)과 한도(limits)가 모두 설정되어 있고, 그 값들이 완전히 동일한 경우에 부여됩니다. 이 클래스는 가장 우선순위가 높아 자원 부족 시 가장 늦게 추출됩니다.
  (Kubernetes, k21academy.com)
• Burstable: requests와 limits 중 일부만 설정되어 있거나, 값이 다를 때 할당됩니다. 자원이 여유 있을 때는 더 활용하지만, 부족할 때는 먼저 축출되지는 않습니다.
  (Last9, Kubernetes)
• BestEffort: 어떤 컨테이너에도 요청이나 한도 설정이 없을 때 지정되며, 가장 낮은 우선순위이므로 자원이 부족할 경우 가장 먼저 축출됩니다.
  (Kubernetes, The Linux Notes)

---

2. 리소스 사용 한계 시의 동작 방식 명확화

• CPU 초과: 컨테이너는 throttling됩니다. 즉, 속도를 제한받지만 강제 종료되지는 않습니다.
  (Reddit)
• 메모리 초과: OOMKilled 상태가 발생하며, Linux 커널이 프로세스를 강제 종료시킵니다.
  (Komodor)

이 점이 교육적으로 매우 중요합니다 — 특히 ‘메모리가 부족할 땐 어떻게 되는지’를 분명히 이해하게 도와줍니다.

---

3. QoS Class에 따른 파드 추출 우선순위 정리

쿠버네티스는 노드에 자원 압력이 있을 때 QoS Class를 기준으로 파드를 추출합니다:

1. BestEffort
2. Burstable
3. Guaranteed

즉, requests와 limits가 제대로 설정된 파드일수록 안정적인 운영이 가능합니다.
(Kubernetes, Sematext)

---

요약 및 반영 제안

항목 설명

QoS 클래스 기준	Guaranteed, Burstable, BestEffort 공식 정의 및 조건 명확화
리소스 초과 시 동작	CPU 초과 → throttling / 메모리 초과 → OOMKilled
Eviction 우선순위	BestEffort → Burstable → Guaranteed 순서로 추출