쿠버네티스 QoS 클래스 — Guaranteed, Burstable, BestEffort
Kubernetes QoS 클래스의 세 가지 종류(Guaranteed/Burstable/BestEffort), 자동 결정 규칙, 메모리 부족 시 퇴출 우선순위, 실무 설정 가이드를 설명합니다.
지난 글에서 requests와 limits로 컨테이너 자원을 설정하는 방법을 살펴봤습니다. 이번에는 requests와 limits 설정에 따라 자동으로 부여되는 QoS(Quality of Service) 클래스를 다룹니다. QoS 클래스는 노드에 메모리가 부족해질 때 어떤 Pod를 먼저 퇴출할지 결정하는 기준이 됩니다.
QoS 클래스의 세 종류
쿠버네티스는 Pod를 생성할 때 resources 설정을 분석해 세 가지 QoS 클래스 중 하나를 자동으로 부여합니다. 사용자가 직접 설정할 수는 없습니다.
Guaranteed: 가장 높은 보호 등급. 메모리 부족 시 가장 마지막에 퇴출됩니다.
Burstable: 중간 등급. limits를 초과한 사용량 비율이 높은 순으로 퇴출됩니다.
BestEffort: 가장 낮은 등급. 메모리 부족 시 가장 먼저 퇴출됩니다.
QoS 클래스 결정 규칙
Guaranteed 조건: Pod 내 모든 컨테이너에서 requests == limits 이어야 합니다.
- CPU: requests == limits (둘 다 설정)
- Memory: requests == limits (둘 다 설정)
- 모든 컨테이너(init container 포함) 동일 조건
BestEffort 조건: Pod 내 모든 컨테이너에 CPU와 메모리 requests, limits가 전혀 없는 경우.
Burstable 조건: Guaranteed도 BestEffort도 아닌 나머지 모든 경우.
- requests는 있고 limits는 없는 경우
- requests ≠ limits인 경우
- 일부 컨테이너는 설정 있고 일부는 없는 경우
QoS 클래스 확인
# Pod의 QoS 클래스 확인
kubectl get pod web-0 \
-o jsonpath='{.status.qosClass}'
# 네임스페이스 내 모든 Pod QoS 확인
kubectl get pods -o custom-columns=\
'NAME:.metadata.name,QOS:.status.qosClass'
# 출력 예시:
# NAME QOS
# web-0 Guaranteed
# cache-0 Burstable
# batch-0 BestEffort
Burstable 퇴출 우선순위 계산
Burstable Pod들 사이에서 퇴출 순서는 requests 대비 실제 사용 비율로 결정됩니다.
사용 비율 = 실제 메모리 사용량 / requests
비율이 높을수록(requests를 많이 초과할수록) 먼저 퇴출됩니다.
예시:
- Pod A: requests=100Mi, 현재 사용=180Mi → 비율 1.8
- Pod B: requests=500Mi, 현재 사용=600Mi → 비율 1.2
Pod A가 먼저 퇴출됩니다.
실무 권장 설정
# 핵심 서비스 (DB, API 게이트웨이): Guaranteed
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "500m" # requests와 동일
memory: "512Mi"
# 일반 서비스 (웹 앱, 마이크로서비스): Burstable
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
# 배치/비중요 작업: BestEffort
# (resources 미설정 — 운영 환경 비권장)
Guaranteed QoS는 노드에서 정확히 그만큼의 자원을 항상 예약합니다. 오버커밋이 없어 자원 효율은 낮지만 안정성이 높습니다. 핵심 컴포넌트에 사용합니다.
Burstable은 평소에는 requests만큼 예약하고, 남는 자원이 있으면 limits까지 사용할 수 있습니다. 자원 효율과 안정성의 균형을 맞출 수 있습니다.
QoS와 Node MemoryPressure
노드에 메모리가 부족해지면 kubelet이 MemoryPressure 컨디션을 설정하고, 다음 순서로 Pod를 퇴출합니다.
- BestEffort Pod → 메모리 사용량이 많은 순
- Burstable Pod → requests 초과 비율이 높은 순
- Guaranteed Pod → 메모리 사용량이 많은 순 (최후 수단)
Guaranteed Pod도 노드 메모리 절대 부족 상황에서는 퇴출될 수 있습니다. 완전한 보호는 아닙니다.
# 노드 MemoryPressure 확인
kubectl describe node node1 | grep MemoryPressure
# 노드 조건 전체 확인
kubectl get node node1 \
-o jsonpath='{.status.conditions[*].type}'
# Ready MemoryPressure DiskPressure PIDPressure
지난 글: 쿠버네티스 Resources Requests와 Limits — 노드 자원 배분
다음 글: 쿠버네티스 Pod 퇴출(Eviction) — kubelet의 리소스 보호 메커니즘
읽어주셔서 감사합니다. 😊