3. Pod - QoS Classes (request, limit)

클러스터 운영 중 자원이 부족할 때 어떤 파드를 먼저 희생시킬지 결정하는 QoS(Quality of Service) 클래스는 서비스의 생존권과 직결되는 아주 중요한 개념이다. 단순히 설정법을 외우는 게 아니라,

 

"자원이 부족해졌을 때, 누가 먼저 죽을 것인가"라는 냉혹한 우선순위의 관점에서 이해해야 한다.

 

---

 

 

1. 파드 QoS(Quality of Service)의 핵심 개념

노드에 자원이 한정된 상황에서 특정 파드가 자원을 더 요구하거나 전체 자원이 고갈되면, 쿠버네티스는 앱의 중요도에 따라 자원을 회수한다. 이때 파드를 다운시키는 우선순위를 결정하는 것이 바로 QoS 클래스다.

제거 우선순위 (Eviction Priority)

자원이 부족할 때 쿠버네티스는 아래 순서대로 파드를 정리하여 자원을 반환(=회수)한다. Node에서 3개의 자원 지원 중.

1. BestEffort (가장 먼저 제거): 자원 반환의 1순위 타겟이다.
2. Burstable (중간 제거): BestEffort가 모두 제거된 후에도 자원이 부족하면 제거된다.
3. Guaranteed (가장 마지막까지 생존): 즉, 서비스의 안정성이 가장 높게 유지되도록 하는 클래스라 할 수 있다.

 

 

2. QoS 클래스 부여 조건

QoS는 별도의 속성을 명시하는 것이 아니라, 컨테이너의 YAML(containers.resources)의 Request(요청)와 Limit(제한) 설정 조합에 따라 자동으로 결정된다.

kind: Pod
spec:
  containers:
    - resources:
       requests:
         memory: 1G
         срu: 2
       limits:
         memory: 2G
         cpu: 4

1) Guaranteed (가장 안정적)

자원이 완벽히 보장되며, 노드 자원 부족 시 가장 나중에 종료되는 안정적인 클래스

• 설정 조건
  1. 파드 내 모든 컨테이너에 설정 필수
  2. Memory와 CPU 모두 설정 필수
  3. Request와 Limit 값이 동일해야 함

2) BestEffort (가장 위험함)

노드의 남는 자원을 자유롭게 쓰지만, 자원이 조금이라도 부족해지면 0순위로 종료(Evicted)되는 가장 불안정한 클래스이다.

• 설정 조건: 어떤 컨테이너에도 Request나 Limit이 전혀 "설정되지 않은" 경우

3) Burstable (유동적)

필요에 따라 제한치까지 자원을 더 사용할 수 있는 유연함을 가졌으나, 자원 부족 시 BestEffort 다음으로 종료 대상이 된다.

• 설정 조건: Guaranteed와 BestEffort 사이의 모든 경우 (예: Request < Limit, 또는 일부 컨테이너만 설정됨)

---

 

 

3. OOM Score: Burstable 사이의 생존 경쟁

같은 Burstable 등급 내에서도 누가 먼저 삭제될지는 OOM(Out Of Memory) Score에 의해 결정된다.

• 판단 기준: 설정된 Request 메모리 대비 실제 앱의 메모리 사용량(%)을 계산한다.
• 로직: OOM Score(사용 비율)가 더 높은 파드가 먼저 제거된다.
  • 예시:
    • Pod2: Request 5Gi ⭤ APP에서의 사용 4Gi = 75% (먼저 제거됨)
    • Pod3: Request 8Gi ⭤ APP에서의 사용 4Gi = 50% (생존 가능성 높음)

 

 

 

💡 꼬리 질문

Q: Guaranteed 클래스로 설정하여 가장 안전하게 보호받는 파드라 할지라도, 노드에 심각한 메모리 압박이 올 때 쿠버네티스가 아닌 OS 레벨의 'OOM Killer'에 의해 죽을 수 있는 예외 상황은 무엇일까?

 

 

결론: 파드가 설정된 Limit(제한) 이상의 자원을 사용하려고 할 때 발생한다.

1. Limit 초과: Guaranteed 파드는 Request와 Limit이 같지만, 실제 앱이 버그나 부하로 인해 설정된 Limit을 초과하는 메모리를 점유하려 들면 시스템은 이를 즉시 차단한다.
2. OS의 개입: 쿠버네티스가 관리하기 전에 시스템 전체의 안정성을 위해 리눅스 커널의 OOM Killer가 해당 프로세스를 강제로 종료(Kill)시킨다.
3. 교훈: 따라서 가장 높은 QoS 등급을 부여하더라도, 앱의 실제 최대 사용량을 정교하게 측정하여 적절한 Limit 값을 설정하는 것이 시니어 엔지니어의 실력이다