📗 개요 - QOS

🏳️‍🌈 [궁금한점]

• QoS 왜 사용해야 하나
• QoS 와 ResourceQuota 차이

---

🔗[목차]

• QoS (Quality of Service) 개요
  • QoS 클래스의 종류와 기준
  • QoS 요약 비교
  • QoS (Quality of Service) 리소스 설정 방식
• QoS 필요성
  • 리소스 부족 상황에서 우선순위 결정
  • 리소스 사용 예측 및 컨트롤
  • 자원 격리와 공정한 자원 분배
  • 자동 스케일링 및 오토리커버리 지원
  • 운영 표준화 및 정책 적용
• QoS 운영 적용 가이드라인
  • 서비스 중요도에 따른 계층적 전략
• ResourceQuota 개요
  • ResourceQuota 필요성
  • ResourceQuota 주요 제한 항목
  • ResourceQuota 미설정 시 위험 요소
    • 자원 과다 사용으로 인한 노드 자원 고갈
    • 멀티 팀/서비스 환경에서의 "자원 경쟁" 발생
    • 비정상적 Pod 폭증으로 API Server, Scheduler 부하
    • 서비스 레벨 간 SLA 충돌
    • 운영/테스트 환경 간 경계 무력화
  • 리소스쿼터를 설정하면 생기는 이점
  • 추천 최소한의 리소스쿼터 항목
• ResourceQuota와 QoS 비교
• 이 외 리소스 제한 단위
  • LimitRange (네임스페이스 내 Pod/Container 단위 기본값 및 상한 설정)
  • Pod-level 리소스 제한 (resources.requests / resources.limits)
  • Node 수준 자원 제한
  • PriorityClass + Pod Disruption + Preemption
  • Cgroups + RuntimeClass (노드 운영체제 수준 리소스 격리, advanced)
  • 리소스 제한 방법 요약

QoS (Quality of Service) 개요

쿠버네티스(Kubernetes)의 QoS(Quality of Service) 는 Pod의 리소스 요청/제한 설정에 따라 노드에서의 우선순위와 자원 확보 정도를 결정하는 메커니즘이다. 이는 리소스 부족 상황에서 어떤 Pod이 먼저 제거되거나 제한될지를 판단하는 기준이 된다. QoS는 노드에 리소스가 부족할 때, Eviction (축출) 순서에 영향을 준다. Pod 성능 및 안정성 보장을 위해 적절한 QoS 등급 설정이 필요하다.

QoS 클래스의 종류와 기준

QoS 클래스	CPU/메모리 설정 기준	설명
Guaranteed	모든 컨테이너에 대해 requests == limits 가 명시됨	리소스를 가장 안정적으로 보장받으며, 노드 리소스 부족 시 가장 마지막에 축출(evict) 됩니다.
Burstable	일부 또는 전부 컨테이너에 requests ≠ limits, 또는 일부만 명시됨	기본 보장량은 requests이고, 상황에 따라 limits까지 사용할 수 있음. 중간 우선순위입니다.
BestEffort	requests와 limits가 모두 설정되지 않음	리소스가 남는 한 사용할 수 있지만, 가장 먼저 축출되며 안정성 낮음. 실험적 워크로드에 적합.

QoS 요약 비교

항목	Guaranteed	Burstable	BestEffort
안정성	최고	중간	최저
리소스 보장	완전 보장	일부 보장	없음
축출 우선순위	가장 낮음	중간	가장 높음
조건	requests == limits	일부만 설정 or 다르거나 없음	둘 다 없음

QoS (Quality of Service) 리소스 설정 방식

• Pod 단위 리소스 보장 등급
• 노드 자원이 부족하면 우선순위 낮은 Pod부터 강제 종료됨
• requests와 limits 설정 방식에 따라 자동 분류됨

리소스 설정 방식	QoS 등급	설명
requests == limits (모두 명시)	Guaranteed	가장 높은 보장, 절대 먼저 종료 안 됨
일부 requests 지정, limits는 다르거나 없음	Burstable	보통 수준의 보장
requests, limits 둘 다 없음	BestEffort	가장 낮은 보장, 자원 부족 시 가장 먼저 종료

주요 용도: eviction(강제 종료), scheduling, 리소스 충돌 시 우선순위 판단

QoS 필요성

QoS는 단순한 분류가 아니라 클러스터 리소스 관리의 핵심 원칙이다. QoS를 사용하지 않으면 리소스과다 사용현상이 발생하여 핵심 서비스가 먼저 죽는 사고가 발생한다.

리소스 부족 상황에서 우선순위 결정

클러스터에서 CPU나 메모리가 부족해지면, kubelet은 일부 Pod을 강제로 종료(Eviction) 시켜야 한다. 이때, 어떤 Pod을 먼저 죽일지 결정하는 기준이 QoS다.

• BestEffort → 가장 먼저 제거됨
• Burstable → 중간
• Guaranteed → 가장 마지막까지 보호됨

안정적 서비스 유지를 위해 중요 서비스는 Guaranteed로 운영해야 함

리소스 사용 예측 및 컨트롤

QoS는 requests와 limits 설정을 기반으로 결정된다. 이를 통해 Pod이 얼마나 자원을 보장받고, 최대 얼마까지 사용할 수 있는지 제어 가능하다. CPU 스로틀링, 메모리 OOM 등 예측 불가 문제를 줄인다.

운영자가 자원 낭비 없이 효율적으로 클러스터를 관리할 수 있음

자원 격리와 공정한 자원 분배

• QoS가 없으면, 어떤 Pod이 과도하게 자원을 점유할 수 있음 → 다른 Pod 성능 저하 발생
• QoS 설정으로 클러스터 리소스를 격리하고, 공정하게 배분

멀티 테넌시 환경에서 서비스 간 간섭을 방지

자동 스케일링 및 오토리커버리 지원

• requests 기반으로 HPA(Horizontal Pod Autoscaler)가 작동
• QoS + Pod Priority + HPA는 자동 복구 전략의 기반

안정적 Auto-healing & Scaling을 위해 QoS 설정은 필수

운영 표준화 및 정책 적용

• 서비스 종류(예: 백엔드, 프론트엔드, 배치 등)에 따라 QoS 템플릿을 나누어 관리하면, 운영이 일관되고 예측 가능
• 클러스터 정책(예: PodDisruptionBudget, Eviction 정책 등)과 연계하여 세밀한 제어 가능

QoS 운영 적용 가이드라인

운영 환경에서 Kubernetes의 QoS(Quality of Service)는 서비스 안정성 보장과 리소스 최적화를 위한 핵심 요소이다. 아래는 실전 운영 관점에서 QoS를 어떻게 설정해야 하는지에 대한 전략과 실천 방법이다.

• 운영 서비스는 Guaranteed 또는 최소한 Burstable로 설정
• 테스트, 임시 작업은 BestEffort로 해도 무방하지만, 불안정
• 메모리의 경우 limit보다 실제 사용량이 많아지면 OOMKilled될 수 있으니 주의
• HPA(수평 자동 확장)는 requests 값을 기준으로 작동

서비스 중요도에 따른 계층적 전략

서비스 유형	예시	권장 QoS	설정 전략
핵심 서비스	DB, 결제, 인증 서비스 등	Guaranteed	requests == limits (명시적 리소스 고정)
일반 마이크로서비스	웹서버, API 서버 등	Burstable	최소한의 requests, 여유 있는 limits
비중요 백그라운드	로그 수집, 배치 작업 등	BestEffort 또는 Burstable	리소스 설정 안 하거나 낮게 설정

ResourceQuota 개요

Kubernetes의 ResourceQuota는 네임스페이스 단위로 리소스 사용량의 상한선을 설정하는 정책이다. 여러 팀이나 앱이 공유 클러스터를 사용할 때 리소스를 공정하게 나누고 남용을 방지하기 위해 사용된다.

ResourceQuota 필요성

상황	문제	ResourceQuota의 역할
여러 팀이 하나의 클러스터 사용	특정 팀이 과도하게 자원을 점유	팀마다 사용할 수 있는 자원 제한
Pod이 과도하게 생성됨	노드 리소스 고갈 → 전체 장애	Pod 수 제한 설정
PVC 등 스토리지를 무한 생성	클러스터 디스크 공간 소진	PVC 용량 총합 제한

ResourceQuota 주요 제한 항목

항목	설명	예시
pods	생성 가능한 Pod의 개수	pods: 20
requests.cpu	전체 요청 가능한 CPU 합	requests.cpu: "2"
limits.memory	전체 제한 가능한 메모리 합	limits.memory: "4Gi"
persistentvolumeclaims	PVC 수 제한	persistentvolumeclaims: 10
requests.storage	전체 PVC 용량 제한	requests.storage: "500Gi"

ResourceQuota 미설정 시 위험 요소

Kubernetes에서 네임스페이스 단위로 ResourceQuota를 설정하지 않을 경우, 다음과 같은 리스크 및 부작용이 발생할 수 있다

자원 과다 사용으로 인한 노드 자원 고갈

특정 네임스페이스(예: spark)에 자원 제한이 없으면, 무한대로 Pod을 생성하거나 메모리를 사용하게 되어 전체 클러스터 노드 자원이 고갈될 수 있다.

이로 인해, 다른 서비스(Pod)들이 스케줄링되지 않거나 OOMKilled, Pod Pending, Eviction 발생한다. 예시들어, Spark job이 executor를 수십 개 생성하면서 100Gi 이상의 메모리를 소모하면 Trino, Airflow Pod이 Pending 상태로 전환된다.

멀티 팀/서비스 환경에서의 "자원 경쟁" 발생

• 한 팀이 클러스터 자원을 과다 점유하면, 다른 팀의 워크로드가 자원 부족으로 정상 동작하지 않을 수 있음
• 네임스페이스별 경계는 있지만, 자원은 공유되기 때문에 리소스 쿼터 없으면 자원 독식 가능

비정상적 Pod 폭증으로 API Server, Scheduler 부하

무한 루프 등으로 인해 잘못된 매니페스트가 수백 개의 Pod을 생성할 경우 API server 부하 증가, kube-scheduler 과부하, 클러스터 전체가 불안정해진다.
pods 개수 제한을 하지 않으면 방어 불가하다.

서비스 레벨 간 SLA 충돌

• 예: Airflow의 DAG 실행 중 자원 부족 → Spark executor가 자원을 모두 가져감
  → 비즈니스 크리티컬한 워크플로우 실패 가능
• 각 서비스 또는 네임스페이스 단위로 SLA 수준을 보장하려면 리소스 상한이 반드시 필요

운영/테스트 환경 간 경계 무력화

prod 네임스페이스와 test 네임스페이스를 나눴더라도 리소스쿼터 없으면 test 작업이 prod 리소스를 모두 사용 가능
→ 운영 장애 유발 가능

리소스쿼터를 설정하면 생기는 이점

이점	설명
자원 폭주 방지	각 네임스페이스별 자원 상한 설정
팀 간 공정한 자원 사용	서로 영향을 주지 않음
안정적인 서비스 운영	예측 가능한 자원 배분
Pod 수, PVC 수 등 제어 가능	오브젝트 개수도 제어
HPA/Auto Scaling 시 보호막	무한 확장 방지

추천 최소한의 리소스쿼터 항목

requests.cpu, limits.cpu
requests.memory, limits.memory
pods
persistentvolumeclaims

• 필요 시:

services, secrets, configmaps, replicationcontrollers

ResourceQuota와 QoS 비교

항목	QoS (Quality of Service)	ResourceQuota
목적	Pod 우선순위 및 자원 회수 정책	네임스페이스 단위 자원 제한
적용 대상	개별 Pod	개별 Namespace
자동 적용 여부	Kubernetes가 자동 분류	사용자가 명시적으로 설정해야 함
기준	Pod의 requests/limits 설정 조합	Namespace에 할당된 총량 제한
종류/레벨	Guaranteed, Burstable, BestEffort	CPU, Memory, Pods, PVC, ConfigMap 개수 등
자원 부족 시 행동	QoS 낮은 Pod 먼저 제거	Quota 초과 시 새 Pod 생성 불가
삭제 대상 우선순위	QoS: BestEffort → Burstable → Guaranteed	N/A (초과 시 스케줄링 불가)
관련 리소스	PodSpec 내 resources.requests/limits	ResourceQuota, LimitRange
운영 관점 용도	스케줄러/eviction 시 우선순위 결정	자원 통제 및 사용량 제한

이 외 리소스 제한 단위

자원 제한을 직접적으로 설정할 수 있는 유일한 단위는 네임스페이스이다.
하지만 네임스페이스 외에도 자원 사용을 간접적으로 제어할 수 있는 메커니즘이 몇 가지 있다.

LimitRange (네임스페이스 내 Pod/Container 단위 기본값 및 상한 설정)

LimitRange는 Pod 또는 컨테이너 단위의 리소스 기본값과 제한값을 정의한다. 네임스페이스 내의 개별 워크로드가 리소스를 명시하지 않아도 자동으로 적용된다.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: trino
spec:
  limits:
  - default:
      cpu: "1000m"
      memory: "1Gi"
    defaultRequest:
      cpu: "500m"
      memory: "512Mi"
    type: Container

Pod-level 리소스 제한 (resources.requests / resources.limits)

네임스페이스가 같더라도, 각 Pod/Container 수준에서 리소스 제한을 개별적으로 지정 가능.

Node 수준 자원 제한

taints와 tolerations로 특정 워크로드만 특정 노드에 배치

kubectl taint nodes node1 role=spark:NoSchedule

→ tolerations이 설정된 Spark 작업만 이 노드에 배치 가능

nodeSelector 또는 affinity로 배치 제어

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-type
            operator: In
            values:
            - spark

PriorityClass + Pod Disruption + Preemption

• 높은 우선순위의 Pod가 낮은 우선순위 Pod를 밀어내고 리소스를 확보할 수 있게 함
• SLA가 다른 서비스 간의 자원 선점 가능

Cgroups + RuntimeClass (노드 운영체제 수준 리소스 격리, advanced)

• 특정 RuntimeClass를 이용해 cgroup 및 리눅스 네임스페이스 수준의 자원 분리 가능
• 주로 gVisor, kata 등으로 보안 강화할 때 활용

리소스 제한 방법 요약

단위	자원 제한 가능 여부	주요 도구
네임스페이스	직접 설정 가능	ResourceQuota, LimitRange
Pod/Container	리소스 requests/limits 설정	QoS, autoscaler
노드	직접 제한 불가 (하지만 배치 제어 가능)	taint/toleration, affinity
클러스터 전체	직접 제한 불가	컨벤션 또는 정책 기반 툴 필요
가상 클러스터 단위	(vCluster, HNC 등으로 격리)	vCluster, Loft