lander.log

K8s QoS 클래스

4 min read

K8s QoS 클래스

정의 (Definition)

Kubernetes의 QoS(Quality of Service) 클래스는 파드를 request/limit 설정 패턴으로 분류 한 결과이며, 주로 노드 압박 상황에서 어떤 파드가 먼저 축출/종료될지 에 영향을 주는 “생존 우선순위”입니다.

문제가 되는 배경 (Problem Context)

평상시에는 파드가 같은 노드에 공존할 수 있지만, 노드가 메모리 압박에 빠지면 누군가는 희생되어야 합니다. 이때 무작위 OOM이 아니라, 운영자가 의도한 중요도(리소스 보장 의지)를 반영한 우선순위가 필요합니다.

핵심 메커니즘 (How it Works)

QoS는 컨테이너들의 request/limit 조합으로 결정됩니다.

QoS조건(요약)압박 시 생존 우선순위(일반적)
Guaranteed모든 컨테이너에 request/limit가 있고, CPU/메모리 각각 request=limit높음
Burstablerequest는 있으나 Guaranteed 조건을 만족하지 않음중간
BestEffortrequest/limit가 없음낮음

노드 압박이 오면 kubelet은 eviction을 통해 노드를 보호하며, QoS는 그 과정(및 커널 OOM score 조정)에 영향을 줍니다.

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

  • 보장: QoS는 request/limit 설정으로 결정됩니다(런타임에서 임의로 바꿀 수 있는 값이 아님).
  • 비보장: Guaranteed라고 해서 “절대 죽지 않는다”는 보장은 없습니다(자기 limit 초과 OOM, 노드 장애 등).

비유 (Analogy)

침몰하는 배에서 구명보트가 부족할 때, “티켓(리소스 보장 의지)”을 명확히 산 사람(Guaranteed)이 먼저 보호되고, 무임승차(BestEffort)가 먼저 내리게 되는 상황에 가깝습니다.

실무적 함의 (Operational Implications)

  • 죽으면 안 되는 핵심 서비스는 QoS 목표(예: Guaranteed) 부터 정하고, 그에 맞게 request/limit 구조를 설계해야 합니다.
  • QoS는 “평상시 성능 차등”보다 “압박 시 장애 반경”에 더 직접적인 영향을 줍니다.

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

  • QoS는 스케줄러의 노드 선택을 직접 바꾸지 않습니다. 스케줄링은 주로 request 총량과 제약(affinity/taint 등)으로 결정됩니다.
  • Guaranteed를 만들기 위해 CPU limit까지 강제하면, 일부 워크로드에서는 CPU throttling에 따른 지연이 악화될 수 있습니다(트레이드오프). (관련: K8s CPU와 메모리 Limit 정책)

References

Recent Posts