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)

Extended resources

kubernetes.io 도메인 밖의 fully-qualified 리소스 이름 — 클러스터 운영자가 빌트인이 아닌 리소스(예: GPU, 커스텀 디바이스)를 노출하고 사용자가 소비
사용 절차 2단계 — ① 운영자가 리소스를 advertise(등록) → ② 사용자가 Pod에서 request

리소스 등록 (advertise)

Node-level (노드에 묶임)
- Device plugin 관리 — device plugin이 노드별로 리소스를 자동 노출 (일반적 방식)
- 수동 등록 — 운영자가 노드의 status.capacity에 PATCH 요청으로 수량 직접 등록
  - kubelet이 status.allocatable을 비동기로 자동 갱신 → 스케줄러는 allocatable 값을 보므로 등록 직후 짧은 지연 발생 가능

# status.capacity에 example.com/foo 5개 등록. ~1은 path 안에서 '/'의 인코딩
curl --header "Content-Type: application/json-patch+json" --request PATCH \
  --data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
  http://k8s-master:8080/api/v1/nodes/k8s-node-1/status

Cluster-level (노드에 묶이지 않음) — scheduler extender가 소비·쿼터를 관리. 스케줄러 설정에서 등록하고 ignoredByScheduler: true로 두면 스케줄러의 PodFitsResources 검사에서 제외
DRA로 할당 — DeviceClass에 extendedResourceName을 지정하면, 그 클래스에 맞는 디바이스를 Pod의 extended resource request로 요청 가능

리소스 소비 (consume)

CPU·Memory처럼 Pod 스펙에서 소비 — 단, 정수만 허용 (유효: 3, 3000m, 3Ki / 무효: 0.5, 1500m → 1.5가 되므로)
overcommit 불가 — request·limit를 둘 다 쓰면 값이 같아야 함. 보통 limits에만 명시
모든 리소스 request(CPU·Memory·extended)가 충족돼야 스케줄됨 — 아니면 PENDING 유지

resources:
  requests:
    cpu: 2
    example.com/foo: 1
  limits:
    example.com/foo: 1    # request와 동일해야 함

PID limiting

kubelet 설정으로 Pod 하나가 소비할 수 있는 PID(프로세스) 개수를 제한 → fork 폭주로 노드가 PID 고갈되는 것을 방지

Troubleshooting

Pod이 `FailedScheduling`으로 pending

스케줄러가 Pod을 배치할 노드를 못 찾으면 — 자리가 날 때까지 unscheduled 상태로 남고, 실패할 때마다 Event 발생
kubectl describe pod <name> Events에서 원인 확인 (예: 0/42 nodes available: insufficient cpu)
해결 시도
- 노드 추가 / 불필요한 Pod 종료로 자리 확보
- Pod이 모든 노드보다 큰 건 아닌지 확인 — 노드 capacity가 cpu: 1인데 Pod이 cpu: 1.1이면 영원히 스케줄 불가
- taint 확인 — 대부분 노드에 taint가 있고 Pod이 toleration이 없으면 남은 노드만 후보가 됨
kubectl describe nodes <name>로 capacity·할당량 확인

필드	의미
`Capacity`	노드의 물리 총량
`Allocatable`	Pod이 실제 쓸 수 있는 양 — 시스템 데몬 몫을 뺀 값이라 Capacity보다 작음

스케줄러는 Allocatable 기준으로 판단 — 이미 할당된 request 합을 빼고 남는 양에 Pod request가 들어가야 배치됨
ResourceQuota로 namespace 단위 총량을 제한 가능 — 단, namespace 쓰기 권한을 가진 사람은 ResourceQuota 자체도 지울 수 있으니 접근 권한도 함께 관리

컨테이너가 종료됨 (terminated)

리소스 부족(resource-starved)으로 kill될 수 있음 — kubectl describe pod <name>로 확인

Last State:     Terminated
  Reason:       OOMKilled    # memory limit 초과로 커널이 kill
  Exit Code:    137          # 128 + SIGKILL(9)
Restart Count:  5            # 지금까지 5번 재시작됨

OOMKilled — 컨테이너가 memory limit보다 많이 쓰려고 했다는 의미
대응 — 앱의 메모리 누수를 점검하거나, 정상 동작이 맞다면 memory limit(필요시 request)를 상향

TIL

Resource Management for Pods and Containers

Requests and Limits

CPU limit 동작

Memory limit 동작

Resource types

리소스 단위

CPU

Memory

컨테이너·Pod 리소스 선언

Pod-level resource (alpha — PodLevelResources feature gate)

스케줄링

Limits·Requests의 런타임 적용 방식

컨테이너 리소스 리사이징

In-place resize (feature gate InPlacePodVerticalScaling)

교체 Pod 발사(replacement) 방식

모니터링

Memory-backed emptyDir 주의사항

Local ephemeral storage

Extended resources

리소스 등록 (advertise)

리소스 소비 (consume)

PID limiting

Troubleshooting

Pod이 FailedScheduling으로 pending

컨테이너가 종료됨 (terminated)

Pod-level resource (alpha — `PodLevelResources` feature gate)

In-place resize (feature gate `InPlacePodVerticalScaling`)

Memory-backed `emptyDir` 주의사항

Pod이 `FailedScheduling`으로 pending