TIL

Resource Management for Pods and Containers

• 공식 문서 - Resource Management
• Pod 스펙에서 컨테이너가 필요한 리소스 양을 선언하는 메커니즘
• 두 가지 축 — request(스케줄링 기준) / limit(런타임 상한)

Requests and Limits

구분	결정 주체	동작
request	kube-scheduler	Pod을 어느 노드에 배치할지 결정하는 기준. kubelet이 해당 양을 컨테이너에 예약
limit	kubelet + 커널(cgroup)	컨테이너가 사용할 수 있는 상한. 초과 시 throttle 또는 kill

• request만 있으면 — 노드에 여유가 있을 때 request 이상을 사용할 수 있음
• limit만 지정하고 request를 안 쓰면 — K8s가 limit 값을 request로 자동 복사

CPU limit 동작

• 커널의 cgroup CPU throttling으로 강제 — hard limit
• limit에 도달하면 CPU 접근이 제한됨 (kill되지는 않음)

Memory limit 동작

• 커널의 OOM kill로 강제 — limit 초과 시 프로세스가 종료될 수 있음
• 단, 커널이 메모리 압박을 감지할 때만 kill → limit을 넘겨도 즉시 kill되지 않을 수 있음 (reactive enforcement)

Resource types

리소스	기본 단위	비고
cpu	core	물리 코어 또는 vCPU
memory	Bytes
ephemeral-storage	Bytes	노드 로컬 임시 스토리지
hugepages-<size>	Bytes	Linux 전용. overcommit 불가

• 클러스터에 extended resources(커스텀 이름, 보통 device plugin이 노출)도 등록 가능

리소스 단위

CPU

• 1 = 1 물리 코어 / 1 vCPU — 소수점 허용 (0.5 = 500m)
• 밀리코어(millicpu) 표기 — 100m = 0.1 CPU. 최소 정밀도 1m
• 절대량 — 1코어 머신이든 48코어 머신이든 500m은 같은 양

Memory

• 정수 bytes 또는 접미사 — E P T G M k (10진) / Ei Pi Ti Gi Mi Ki (2진)
• 주의 — M(메가바이트) ≠ m(밀리바이트). 400m = 0.4 bytes → 의도한 건 대부분 400Mi

컨테이너·Pod 리소스 선언

• 컨테이너별로 spec.containers[].resources.requests / .limits에 cpu·memory·ephemeral-storage·hugepages 지정
• Pod 전체 리소스 = 모든 컨테이너의 request/limit 합산

spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Pod-level resource (alpha — PodLevelResources feature gate)

• Pod 수준에서 spec.resources로 CPU·Memory 예산을 통째로 선언 가능
• 컨테이너 개별 request/limit 없이도 Pod 전체 예산을 공유 → 컨테이너가 많을 때 유연한 리소스 활용

스케줄링

• 스케줄러는 request 합산 ≤ 노드 용량인 노드를 선택
• 노드의 실제 사용량이 낮더라도 — capacity check 실패 시 배치 거부 (피크 시간대 리소스 부족 방지)

Limits·Requests의 런타임 적용 방식

• kubelet이 컨테이너 시작 시 — request·limit 값을 컨테이너 런타임에 전달 → 런타임이 Linux cgroup으로 강제

항목	적용 방식
CPU limit	cgroup의 hard ceiling. 스케줄링 슬라이스마다 한도 초과 여부 확인 → 초과 시 cgroup 실행 대기
CPU request	경합 시 가중치(weight)로 작용 — request가 큰 컨테이너가 더 많은 CPU 시간 할당받음
Memory request	주로 스케줄링용. cgroup v2 노드에선 런타임이 memory.min·memory.low 힌트로 활용 가능
Memory limit	cgroup memory limit. 초과 시 커널 OOM이 컨테이너 내 프로세스를 kill. PID 1이 죽고 restartable이면 K8s가 재시작

• Memory request 초과 + 노드 메모리 부족 → Pod이 evict될 가능성 높음
• CPU limit 초과는 일정 시간 허용될 수 있음 — 단, CPU 과다 사용으로 컨테이너가 kill되지는 않음
• Memory limit은 memory-backed emptyDir 같은 메모리 볼륨에도 적용됨 — kubelet이 tmpfs emptyDir을 컨테이너 메모리 사용량으로 계산

컨테이너 리소스 리사이징

In-place resize (feature gate InPlacePodVerticalScaling)

• Pod 재생성 없이 실행 중인 컨테이너의 CPU·Memory request/limit를 변경 — in-place Pod vertical scaling
• Pod의 /resize 서브리소스로 업데이트
• 컨테이너의 resizePolicy 필드로 — 변경 시 컨테이너 재시작이 필요한지 제어 가능
• 현재는 컨테이너 단위 리소스에 적용. Pod-level 리사이즈는 별도 방식

교체 Pod 발사(replacement) 방식

• 클라우드 네이티브 표준 접근 — Deployment·StatefulSet 등의 Pod 템플릿을 수정해서 컨트롤러가 새 Pod으로 교체
• 모든 K8s 버전에서 동작, 모든 spec 필드 변경 가능
• [[horizontal-pod-autoscaler]]가 수평 스케일링을 자동화하듯, Vertical Pod Autoscaler(VPA)가 수직 리소스 권장값을 자동 관리

모니터링

• kubelet이 Pod status에 리소스 사용량 보고
• 클러스터에 monitoring 도구가 있으면 — Metrics API나 모니터링 시스템에서 Pod 사용량 조회 가능

Memory-backed emptyDir 주의사항

• sizeLimit을 지정하지 않으면 — emptyDir 볼륨이 Pod의 memory limit까지 소비 가능
• Pod의 memory limit이 없으면 → 노드 메모리 전체를 잠식할 수 있음. emptyDir을 여러 개 만들면 DoS·OOM 위험
• 스케줄러는 request 기준으로만 노드 배치를 판단 — request 초과 메모리 사용은 스케줄링 결정에 반영되지 않음
• 추가 고려사항
  • 메모리 볼륨에 쓴 파일은 언어 GC가 회수하지 않음 — 앱이 직접 관리해야 함
  • K8s·OS가 자동 삭제하지 않으므로 — 메모리 압박 시에도 회수되지 않음
  • 메모리는 디스크보다 비싸고 작음 → 큰 emptyDir은 Pod·노드 운영에 영향
• 운영 안전장치 — ResourceQuota / LimitRange / ValidatingAdmissionPolicy로 namespace·Pod 단위 제한 적용

Local ephemeral storage

• 노드 로컬 임시 스토리지 — ephemeral-storage 리소스로 request/limit 가능
• kubelet은 local ephemeral storage capacity isolation 활성화 시 Pod의 사용량을 측정
• 사용량 집계 대상
  • 컨테이너의 writable layer(rootfs)·이미지
  • 로컬 emptyDir 볼륨
  • Pod 자체 로그 (보통 /var/log/pods 하위)
  • K8s가 Pod에 매핑하는 시스템 파일 (예: /etc/hosts)