짧게 정리 - 상세는 아래 참고

[ 추가 설명 ]
- 여기서 "graceful eviction"을 만족하기 위해서는 "Soft eviction"을 설정해야 되는데
	설정 값 중"terminationGracePeriodSeconds"를 지정하면 "SIGTERM => 앱 정리 -> 시간 초과     시 SIGKILL" 순서로 진행

Workload 안정성, 효율성

Overview

K8s 운영 시 Pod가 강제 종료되는 경우는 크게 **K8s 레벨(Pod Disruption)**과 **Linux 레벨(OOM Kill)**로 나뉜다.

주체	관리 범위	동작 결과	동작 방식	한계
kube-scheduler (trigger)	cluster	pod 축출(eviction)	Event 방식 (더 높은 PriorityClass pod scheduling 시)	memory pressure와 무관, preemption 시에 동작
kubelet	node	pod 축출(eviction)	Polling 방식 (노드 가용 메모리가 eviction threshold에 도달 시)	polling으로 인해 node pressure 신호는 늦게 감지될 수 있음. 따라서 OOMKilled의 완전한 차단은 불가
cgroup OOM killer	pod	container OOMKilled	Event 방식 (limit 초과 시)	cgroup V1은 kernel memory, 특히 spike로 문제되는 TCP socket buffer를 다루는데 제약이 크고, V2 및 global 조차 한계가 있음
global OOM killer	node	process OOMKilled	Event 방식 (메모리 할당 실패 시)	kill 대상에 k8s, 시스템 프로세스까지 포함 → node 회복 불가

CPU는 "선점 자원(preemptible resource)"이기 때문에 프로세스 종료를 야기하지 않고 느려지기만 한다. 따라서 주로 memory만 논한다.

Part 1. Pod Disruption (K8s 레벨)

구조

Pod Disruption
├── Voluntary (의도적)
│   ├── API-initiated Eviction
│   └── Preemption (Eviction 아님)
│
└── Involuntary (비의도적)
    └── Node-pressure Eviction

Eviction 정의

Eviction은 "노드에서 실행 중인 Pod를 종료시키는 절차"
핵심은 "절차"인데, 단순히 Pod를 삭제하는 게 아니라 정해진 프로세스를 따름
Preemption은 스케줄러가 Pod를 직접 delete하는 방식이라 Eviction과는 별도 개념

1-1. Voluntary Disruption

누군가(운영자 또는 스케줄러)가 의도를 가지고 Pod를 제거하는 경우