리소스 요청/제한과 QoS — 압박 상황에서 누가 먼저 쫓겨나는가
Kubernetes 공식 문서(kubernetes.io) 및 운영 블로그 종합 — 아키텍처부터 스케줄링까지 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/overview/components, workloads/pods, services-networking, pod-qos, pod-lifecycle) + 운영 블로그(Komodor, Datadog 등) 교차 확인 Kubernetes 공식문서 Pod Quality of Service Classes
이 모듈을 다 읽으면
- requests와 limits가 각각 스케줄링과 런타임 제한 중 무엇에 쓰이는지 설명할 수 있다
- Guaranteed/Burstable/BestEffort 세 QoS 클래스가 requests/limits로부터 어떻게 결정되는지, 그리고 축출 순서와 어떻게 연결되는지 설명할 수 있다
k8s-learn-01에서 다룬 스케줄러가 실제로 어떤 기준으로 노드를 고르는지(requests), 그리고 노드가 자원 압박을 받을 때 어떤 Pod가 먼저 희생되는지(QoS+limits)를 정리한다.
requests는 스케줄링 기준, limits는 런타임 상한
requests는 컨테이너가 '최소한 이만큼은 필요하다'고 선언하는 값으로, 스케줄러가 이 값을 보고 그만큼의 여유 자원이 있는 노드를 찾아 배정한다. limits는 컨테이너가 '이 이상은 못 쓴다'는 런타임 상한이다 — CPU는 limits를 넘으면 스로틀링되고, 메모리는 limits를 넘으면 OOMKilled로 강제 종료된다. 이 둘은 독립적으로 설정 가능해서, requests보다 limits를 더 높게 잡으면(Burstable) 여유 자원이 있을 때 더 쓸 수 있는 유연함을 얻는다.
핵심 포인트
- requests: 스케줄러가 노드를 고르는 기준('최소 이만큼 필요') / limits: 런타임 상한(CPU는 스로틀링, 메모리는 OOMKilled)
- requests < limits로 설정하면(Burstable) 여유 자원이 있을 때 더 쓸 수 있는 유연성 확보
QoS 클래스 — requests/limits 조합으로 자동 결정된다
Guaranteed는 모든 컨테이너가 CPU·메모리 모두 requests와 limits를 설정하고 그 값이 서로 같아야(request=limit) 한다 — 가장 엄격한 조건이다. Burstable은 Guaranteed 조건을 만족 못 하지만 최소 하나의 컨테이너가(또는 Pod 수준에) CPU·메모리 request나 limit 중 하나라도 설정된 경우다. BestEffort는 어떤 컨테이너도 CPU·메모리 request/limit을 전혀 설정하지 않은 경우다 — 즉 QoS는 사용자가 직접 지정하는 게 아니라 requests/limits 설정 상태로부터 Kubernetes가 자동으로 계산한다.
핵심 포인트
- Guaranteed: 모든 컨테이너의 CPU·메모리 request=limit(둘 다 설정, 값 동일)
- Burstable: Guaranteed 조건 미충족이지만 최소 하나의 request/limit이라도 설정됨 / BestEffort: request/limit을 아예 하나도 설정 안 함
노드 자원 압박 시 축출 순서 — BestEffort부터, Guaranteed는 마지막
노드가 자원이 바닥나면 Kubernetes는 BestEffort Pod를 가장 먼저 축출하고, 그다음 Burstable, 마지막으로 Guaranteed를 축출한다 — 이 압박 상황으로 인한 축출은 requests를 초과해서 쓰고 있는 Pod만 대상이 된다는 점도 중요하다(단순히 낮은 QoS라고 무조건 쫓겨나는 게 아니라, requests 초과분이 있어야 후보가 됨). 결국 requests/limits를 촘촘하게(=Guaranteed에 가깝게) 잡을수록 노드 압박 상황에서 그 Pod가 살아남을 확률이 높아진다.
핵심 포인트
- 축출 순서: BestEffort → Burstable → Guaranteed (Guaranteed가 가장 안전)
- 압박으로 인한 축출은 requests를 초과해서 쓰고 있는 Pod만 대상 — 낮은 QoS라고 무조건 축출 후보가 되는 건 아님