이 노트는 Kubernetes 자원 설정을 “Pod 하나의 숫자”가 아니라 scheduler 배치, cgroup 집행, 노드 압력, HPA 입력이 연결된 예산 모델로 설명합니다. request와 limit의 의미를 분리한 뒤 앱 외 구성요소와 관측 신호를 같은 노드 단위로 대조합니다.
Request 배치 기준과 Limit 사용 상한
컨테이너의 CPU request=500m, limit=1이면 scheduler는 요청 자원을 배치 계산에 사용하고 런타임은 설정된 CPU 상한을 집행합니다. request가 최대 사용량이 아니고 limit가 항상 확보되는 CPU도 아닙니다. 노드 경쟁·quota 주기·throttling이 실제 지연에 영향을 줍니다.
메모리는 CPU처럼 실행 시간을 나누어 초과를 해소할 수 없습니다. cgroup의 메모리 한도와 압력에 따라 OOM 종료가 일어날 수 있습니다. 순간 피크·캐시·GC·native 메모리까지 포함하고 평균만으로 limit를 정하지 않습니다.
| 설정·관측 | 역할 | 구분할 실패 |
|---|---|---|
| requests | 배치·자원 경쟁 기준 | 부족하면 Pending 또는 과밀 배치 |
| CPU limit | 사용 시간 quota 상한 | 살아 있지만 throttling으로 느림 |
| memory limit | 메모리 사용 제한 | 컨테이너 OOMKilled 가능 |
| node pressure | 노드 전체 자원 부족 | kubelet eviction·시스템 OOM |
| Pod priority·QoS | 압력·스케줄 정책 요소 | 절대 생존 보장 아님 |
request를 낮추면 scheduler는 같은 노드에 더 많은 Pod를 넣을 수 있지만 정상 피크 때 CPU 경쟁이 커질 수 있고, 높이면 실제 유휴가 있어도 Pending이 될 수 있습니다. 예를 들어 request를 500m에서 250m로 낮추면 8 vCPU 노드의 산술상 배치 수와 HPA utilization 분모가 동시에 바뀝니다. 실제 선택은 p95/p99 사용량, burst 허용 시간, 노드 수·비용, latency SLO를 함께 대입해야 합니다. CPU utilization 기반 HPA는 사용량을 request로 나누어 비율을 계산하므로, 같은 사용량이어도 request를 바꾸면 확장 입력이 달라집니다. 따라서 request 조정은 배치 가능 수와 HPA가 보는 비율을 함께 다시 계산해야 합니다.
QoS 분류와 종료 순서 결정 조건
전통적인 컨테이너별 자원 설정에서 모든 컨테이너의 CPU·메모리 request와 limit가 설정되고 각각 같으면 Guaranteed, 둘 다 전혀 없으면 BestEffort, 그 사이면 Burstable에 해당하는 구성이 일반적입니다. init·sidecar·Pod 수준 자원 기능 등 실제 Kubernetes 버전과 구성의 조건도 확인합니다.
node pressure eviction은 request 대비 초과 사용·priority·상대 사용량 같은 요인과 연결됩니다. QoS가 위험을 설명하는 데 도움되지만 “Guaranteed는 절대 종료되지 않는다”거나 QoS 이름만으로 모든 순서가 결정된다고 말하지 않습니다. Guaranteed 컨테이너도 자기 limit에 걸릴 수 있습니다. OOMKilled·Evicted·node condition·cgroup 지표를 대조합니다.
노드 용량과 앱 외 자원 예산
노드 capacity가 CPU 8, 메모리 32 GiB이고 시스템 예약·kubelet·eviction 여유를 반영한 allocatable이 CPU 7, 28 GiB라고 합시다. 배치될 DaemonSet이 CPU 1, 3 GiB를 요청하면 앱에 남는 요청 예산은 CPU 6, 25 GiB입니다. 앱 Pod가 CPU 2, 8 GiB씩이면 이 산술에서는 3개가 가능하지만 Pod 수·IP·volume attach 등 다른 상한도 만족해야 합니다. 진단에서는 Pending의 scheduler event, CPU throttling, OOMKilled, Evicted, node condition, HPA current/desired replica를 시간축으로 묶습니다. 메모리 limit 초과와 노드 pressure eviction은 모두 “메모리 문제”처럼 보일 수 있지만 조치 대상과 원인이 다릅니다.
그림을 글로 읽기
- Node capacity
- Node allocatable: 시스템 예약·여유 반영
- DaemonSet·기존 요청 제외
- 새 앱 Pod 배치 가능량
- Node capacity → Node allocatable: 노드 예약 정책
- Node allocatable → DaemonSet·기존 요청 제외: 실제 배치 집합
- DaemonSet·기존 요청 제외 → 새 앱 Pod 배치 가능량: CPU·메모리·기타 상한
DaemonSet이 어느 노드에 실제로 들어가는지는 selector·taint toleration·architecture 등 실제 스케줄 조건을 대입해 결정하므로, allocatable에서 모든 DaemonSet을 일괄 차감하지 않고 해당 노드의 실제 배치 집합만 계산합니다. 인스턴스 유형을 넓힐 때는 네트워크·스토리지·GPU·Pod 수 한도를 후보별로 함께 대조합니다.
init container·native sidecar·Pod overhead의 유효 request는 단순 앱 컨테이너 합과 다를 수 있으므로 실제 scheduler 계약으로 계산합니다.
Sidecar 로그 처리와 잔여 자원 비용
로그 sink가 느려지면 sidecar의 큐·재시도·디스크 쓰기가 증가할 수 있습니다. 앱 CPU만 낮다고 문제가 없는 것이 아닙니다. 컨테이너별 CPU·메모리·ephemeral storage와 노드 디스크·네트워크를 같이 봅니다. stdout 경로가 막혀 앱의 로그 호출이 느려지는 경우도 있습니다.
로그 큐 바이트·최대 나이·전송률에 상한을 두고 진단 로그의 sampling·drop과 필수 감사 기록의 보존·실패 정책을 구분합니다. 필수 기록을 무조건 버리거나 모든 로그를 무한 메모리 큐에 넣지 않습니다. sidecar를 다른 Pod로 옮겨도 공유 노드·sink 용량은 여전히 제한됩니다.
자원 설정 조정과 실패 원인별 대조 실험
같은 앱 부하에서 CPU quota·노드 CPU 경쟁·메모리 피크·로그 sink 지연을 하나씩 바꿉니다. throttled time·run queue·GC·OOM·eviction 사건과 p99를 대조합니다. request 조정 뒤 Pending·노드 수·HPA 계산까지 함께 확인합니다.
현재 작업에서는 클러스터 자원 설정이나 OOM 실험을 실행하지 않았습니다. 수치 예는 배치 계산을 설명하는 가정이며 실제 인스턴스의 성능·생존 보장이 아닙니다. Kubernetes 버전·admission 정책·cgroup 모드·노드 이미지에 따른 세부 동작은 대상 클러스터의 공식 문서와 describe/event/metrics 결과로 확인해야 합니다.