lander.log

K8s QoS Classes

5 min read

K8s QoS Classes

1. 정의 (Definition)

K8s QoS (Quality of Service) Classes는 리소스 부족 상황(Node Pressure)에서 누구를 먼저 죽일지(Eviction Priority) 결정하기 위해 Kubernetes가 파드(Pod)에 자동으로 부여하는 세 가지 우선순위 등급입니다.

  • Guaranteed: 최상위 등급 (가장 나중에 죽음)
  • Burstable: 중간 등급
  • BestEffort: 최하위 등급 (가장 먼저 죽음)

2. 등장 배경 (Problem Context)

  • 문제: 모든 파드를 동일하게 대우하면, 리소스가 부족할 때 중요한 DB 파드와 일회성 배치 잡(Job) 중 누구를 살려야 할지 커널이 알 수 없습니다.
  • 해결: 사용자가 설정한 requests와 limits를 바탕으로 파드의 중요도를 자동으로 분류하여, 위기 상황에서 **“희생양 순서”**를 정립했습니다.

3. 핵심 메커니즘 (How it Works)

Kubernetes는 파드 생성 시 설정된 리소스 값을 보고 등급을 매깁니다.

3.1. 분류 기준

Class조건OOM Score Adj비고
Guaranteed모든 컨테이너의 requests == limits (CPU & Memory)-997사실상 면책 특권
Burstablerequests < limits 또는 limits 미설정2 ~ 999사용하는 만큼 위험도 증가
BestEffortrequests, limits 모두 미설정10001순위 제거 대상

3.2. 동작 원리

  • OOM Score Adj: Kubelet은 각 컨테이너 프로세스의 /proc/<pid>/oom_score_adj 값을 위 표에 따라 설정합니다.
  • Eviction: 노드 메모리가 부족해지면 Linux 커널(OOM Killer) 또는 Kubelet Eviction Manager가 이 점수가 높은 순서대로 파드를 종료합니다.

4. 불변 조건과 보장 범위 (Invariants & Guarantees)

  • Guaranteed 보호: 시스템 데몬(kubelet 등)이 죽지 않는 한, Guaranteed 파드는 Burstable이나 BestEffort 파드가 모두 축출되기 전에는 축출되지 않습니다.
  • 자동 할당: QoS 클래스는 사용자가 직접 지정할 수 없으며, 오직 리소스 설정(requests, limits)의 조합에 의해서만 결정됩니다.

5. 비유 (Analogy)

비행기 좌석 등급과 유사합니다.

  • Guaranteed (일등석): 정가를 다 내고(Requests=Limits) 탔습니다. 오버부킹 상황에서도 웬만하면 쫓겨나지 않습니다.
  • BestEffort (대기자 탑승): 돈을 안 내거나 확약 없이(No Requests) 탔습니다. 자리가 모자라면 가장 먼저 내려야 합니다.

6. 실무적 함의 (Operational Implications)

  • 프로덕션 DB: 반드시 Guaranteed로 설정해야 합니다. 메모리 튀었다고 DB가 죽으면 안 되기 때문입니다.
  • 개발/테스트 환경: Burstable을 사용하여 리소스 효율(Overcommit)을 높일 수 있습니다.
  • 로그 수집기/배치: BestEffort로 설정하여, 남는 자원을 쓰되 메인 서비스에 영향을 주지 않도록 합니다.

7. 주의사항 / 오해 (Pitfalls & Misconceptions)

  • “Guaranteed는 성능이 더 좋다?”: 평상시 성능은 QoS 클래스와 무관합니다. QoS는 **“자원 부족 시의 생존 우선순위”**일 뿐입니다. (단, Guaranteed는 CPU 독점 할당 등 일부 고급 기능의 전제 조건이 됩니다.)
  • “Burstable은 항상 안전하다?”: 아닙니다. Burstable 파드가 메모리를 많이 써서 limit에 가까워질수록 OOM Score가 높아져 죽을 확률이 Guaranteed보다 훨씬 높습니다.

8. References

References

Recent Posts