Kubernetes v1.37은 이 deferred 상태를 위한 scheduler preemption for in-place Pod resize를 Alpha로 추가했다. InPlacePodVerticalScalingSchedulerPreemption feature gate를 켜면 scheduler가 높은 우선순위 Pod의 resize를 만족시키기 위해 같은 node의 낮은 우선순위 Pod를 preempt할 수 있다. 공식 발표의 핵심도 “resize가 자동으로 안전해졌다”가 아니라, 정적 배치 이후 생기는 자원 부족을 scheduler가 해소할 수 있는 경로가 열렸다는 것이다.

이 글은 Kubernetes Rollout 전략, Capacity Planning·Little’s Law·Saturation, Priority Load Shedding·Bulkhead, Node Lifecycle Conditions를 resize 관점으로 연결한다. 중요한 질문은 “API Pod가 restart 없이 커질 수 있는가”가 아니라, 어느 workload를 얼마나 자주, 어떤 복구 증거가 있을 때 중단시켜도 되는가다.

공식 자료는 Kubernetes v1.37의 Scheduler Preemption for In-Place Pod Resize 발표, container resource resize 문서, Pod Priority and Preemption 문서, PodDisruptionBudget 문서를 기준으로 확인했다. Alpha 기능의 세부 동작과 feature gate는 이후 release에서 달라질 수 있으므로, 문서의 example을 production 정책으로 복사하지 않는다.

이 글에서 얻는 것

• ResizeDeferred가 의미하는 node headroom 문제와, v1.37이 scheduler preemption으로 메우려는 범위를 이해합니다.
• resize를 받는 high-priority Pod와 preempt되는 low-priority Pod의 가용성 비용을 분리해서 계산합니다.
• PriorityClass, PDB, termination grace, queue lease, checkpoint를 하나의 퇴출 예산(eviction budget) 으로 묶는 기준을 얻습니다.
• staging → 단일 pool → 제한 canary로 승격하기 위한 지표와 rollback 조건을 숫자로 정합니다.

핵심 개념/이슈

1) Deferred resize는 “더 큰 request"가 아니라 node-local capacity 문제다

실행 중인 Pod의 resource request를 늘리면 kubelet은 해당 node에 추가 allocation을 수용할 여유가 있는지 본다. 여유가 없으면 resize 요청은 ResizeDeferred 상태가 될 수 있다. 이 상태가 곧 애플리케이션이 실패했다는 뜻은 아니지만, latency가 이미 악화됐거나 OOM 위험을 줄이려는 resize라면 기다리는 시간 자체가 SLO 비용이다.

v1.37의 Alpha 기능은 scheduler가 이 신호를 보고 lower-priority Pod를 preempt해 공간을 만든 뒤, deferred resize가 진행되도록 한다. 이것은 새 Pod를 우선 배치할 때의 preemption과 비슷해 보이지만 이미 실행 중인 workload가 resource를 키우는 상황이라는 점이 다르다. high-priority Pod에는 restart 없는 resize일 수 있어도 low-priority Pod에는 명시적인 중단·재시작·재처리 비용이 생긴다.

따라서 용량 문제를 다음처럼 나눠 관찰해야 한다.

CPU utilization 40%라는 평균만 보고 “여유가 있다”고 결론 내리면 안 된다. scheduler는 실제 request와 node-local placement를 본다. 한 node에 특정 request가 몰렸거나 fragmentation이 크면 평균 사용률과 상관없이 deferred가 발생한다.

2) PriorityClass는 권리의 순서이지 희생의 안전 보증이 아니다

PriorityClass는 scheduler에게 상대적 중요도를 알린다. 하지만 priority=1000인 Pod가 priority=100인 Pod를 밀어낼 수 있다는 사실은 낮은 priority Pod가 안전하게 종료된다는 증명이 아니다. preemption 후보에는 최소한 아래 다섯 사실이 있어야 한다.

1. 작업이 멈춰도 고객 데이터나 외부 부작용이 중복되지 않는다.
2. terminationGracePeriodSeconds 안에 checkpoint, offset commit, lease release 또는 safe retry가 끝난다.
3. PDB가 보호해야 할 replica 수와 충돌하지 않는다.
4. 다시 배치될 node/pool 또는 queue 처리 여력이 있다.
5. owner가 event와 job outcome을 보고 복구 여부를 판단할 수 있다.

예를 들어 image thumbnail 생성 worker는 object key 기반 멱등성이 있고 결과를 overwrite할 수 있다면 좋은 초기 후보다. 반면 결제 capture worker, DB primary, migration job, in-memory session owner는 낮은 priority여도 자동 preemption 후보가 아니다. 비용을 줄이려고 priority를 낮게 준 것이 “강제 종료 승인”으로 해석되면 안 된다.

3) PDB는 모든 중단을 막는 안전망이 아니다

PodDisruptionBudget은 voluntary disruption에 대한 availability budget을 표현한다. scheduler preemption, node failure, application crash처럼 모든 경로에 동일하게 적용된다고 가정하면 위험하다. 기능을 켜기 전에 cluster 버전과 실제 preemption 흐름에서 PDB가 어떻게 관찰되는지 staging으로 검증하고, PDB만으로 stateful workload의 안전을 선언하지 않는다.

특히 minAvailable이나 maxUnavailable 값을 정할 때 replica 수만 세면 부족하다. traffic drain, readiness recovery, cache warm-up, leader election, downstream rate limit까지 포함한 실제 회복 시간을 budget에 넣어야 한다. 3 replica API에서 한 Pod가 종료된 뒤 readiness까지 p95 75초가 걸린다면, 30초마다 resize preemption이 반복되는 정책은 replicas가 3개여도 서비스에 압박을 준다.

4) feature gate 일관성은 최소 조건이다

공식 안내에 따르면 이 기능은 Kubernetes v1.37 이상과 함께 control plane 구성요소(kube-apiserver, kube-scheduler) 및 kubelet에 feature gate를 켜야 한다. 일부 node만 다르거나 rollout 중 설정이 섞이면 resize가 특정 node에서만 다르게 보일 수 있다. Gate가 enabled라는 것은 scheduler action이 가능하다는 뜻이지, workload policy가 준비됐다는 뜻이 아니다.

기술 검증과 운영 승인 기준을 분리한다.

실무 적용

1) resize와 퇴출을 같은 capacity budget으로 모델링한다

resize request를 추가 CPU·memory, victim을 해제 가능한 request, node에 남겨야 할 headroom으로 표현한다. 예를 들어 node allocatable이 8 CPU이고, high-priority Pod가 4→6 CPU로 +2 CPU resize를 원하며 현재 headroom이 1 CPU라면 scheduler는 최소 1 CPU 이상의 victim request를 찾아야 한다. 그러나 여기서 “1 CPU짜리 아무 Pod”가 답은 아니다.

다음처럼 정책을 문서로 만든다.

high-priority resize 허용: API tier-0, request delta <= 1 CPU 또는 2 GiB
victim 후보: batch-low, checkpoint 완료 <= 20초, external side effect 없음
보호 대상: database, payment, migration, default-priority API
node reserve: allocatable의 15% 또는 1 CPU 중 큰 값
자동 preemption 상한: node당 1회 / 30분, pool당 3회 / 1시간

수치는 예시이며 workload의 recovery p95와 traffic pattern으로 조정해야 한다. 중요한 것은 PriorityClass만 남기지 않고 “resize request의 상한”, “희생 가능 작업”, “남겨 둘 여유”, “반복 횟수”를 한 정책에서 연결하는 점이다. preemption이 잦다면 feature가 잘 작동하는 것이 아니라 request 산정, node packing, HPA/VPA, pool isolation 중 하나가 틀렸다는 신호로 본다.

2) 먼저 preemption 없이 deferred를 관찰한다

production gate를 바로 활성화하지 말고 staging에서 high/low PriorityClass, 의도적으로 부족한 node headroom, resize subresource RBAC를 만든다. high-priority Pod의 request를 올려 ResizeDeferred event를 확인하고, 다음 이벤트 순서와 실제 cgroup allocation을 기록한다.

ResizeDeferred
  -> scheduler가 victim 선택 또는 보류한 근거
  -> victim Preempted / termination event
  -> ResizeStarted
  -> ResizeCompleted 또는 다시 Deferred

그 다음 production에서는 gate 없이도 deferred 시간, candidate victim, autoscaler action, API SLO를 dashboard로 모은다. 2주 데이터를 보면 resize preemption이 실제로 필요한 희귀 spike인지, 예약 headroom과 node pool 분리로 더 싸게 해결할 구조적 부족인지 구분할 수 있다.

3) 단일 pool에서 48시간 제한 canary를 실행한다

canary는 high-priority API 하나와 재시작 가능한 batch/consumer 하나가 전용 node pool에 있는 경우로 제한한다. customer-facing API와 DB, migration, baseline web workload가 섞인 일반 pool은 첫 대상이 아니다. 48시간 동안 다음 기준을 동시에 통과해야 다음 대상으로 넓힌다.

“preemption 0건”도 성공적인 canary 결과일 수 있다. 실제로는 scheduler가 불필요하게 행동하지 않았고, headroom 또는 autoscaler가 충분했다는 뜻일 수 있다. 이 경우 feature를 더 넓히는 대신 deferred 원인이 node fragmentation인지 request inflation인지 점검하는 편이 좋다.

4) event와 ownership을 runbook에 넣는다

on-call이 high-priority Pod만 보고 “resize가 성공했다”고 끝내면 victim의 backfill·duplicate·queue lag를 놓친다. alert에는 최소한 resize 대상, request delta, node, victim list, PriorityClass, PDB 상태, queue lag, rollback flag가 함께 있어야 한다.

우선순위는 다음처럼 고정할 수 있다.

1. data integrity와 customer action의 중복 여부를 확인한다.
2. victim workload의 recovery/queue lag가 SLO 안인지 확인한다.
3. high-priority Pod의 allocation과 p99가 회복됐는지 확인한다.
4. 같은 node/pool에서 재발하면 preemption을 끄고 capacity·autoscaling·packing을 조사한다.

이 순서는 high-priority API의 latency가 중요하지 않아서가 아니다. preemption으로 만든 숨은 부채가 늦게 나타나도 되돌릴 수 있도록, 먼저 irreversible side effect를 보는 것이다.

트레이드오프/주의점

“무중단"이라는 단어가 비용을 가린다

in-place resize는 high-priority Pod의 restart를 피할 수 있다. 그러나 그 자원을 만들기 위해 victim이 종료된다면 cluster 전체 관점에서는 가용성 비용을 옮긴 것뿐이다. batch가 안전하게 재시작되는지, queue가 중복을 흡수하는지, downstream가 burst를 견디는지를 증명하지 못하면 무중단이라는 표현을 운영 결론으로 쓰지 않는다.

preemption은 capacity planning의 대체품이 아니다

지속적으로 deferred가 발생하는 pool은 피크 capacity가 부족하거나 request가 실제 사용량과 맞지 않거나, heterogeneous workload가 한 node에 섞였을 가능성이 크다. 이 경우 preemption을 자주 허용하면 high-priority 부하는 빨라질 수 있어도 batch starvation, queue lag, noisy-neighbor 문제가 늘어난다. headroom reservation, node pool 분리, HPA/VPA tuning, cluster autoscaler latency를 먼저 비교해야 한다.

Alpha gate는 전체 제어면을 바꾼다

기능이 Alpha이고 feature gate가 여러 component에 걸친다는 점도 중요하다. upgrade·rollback 시 gate 조합, node 교체, scheduler event schema, autoscaler와의 상호작용을 실제 버전에서 확인해야 한다. feature gate를 켠 상태에서 policy 오류가 나면 단순 application rollback으로 scheduler behavior가 사라지지 않을 수 있으므로, gate off 절차와 node rollout 영향을 runbook에 함께 둔다.

체크리스트

• v1.37 이상 control plane과 모든 대상 kubelet의 version/gate 조합을 inventory로 확인했는가?
• ResizeDeferred, ResizeStarted, ResizeCompleted, Preempted event를 workload·node·PriorityClass별로 조회할 수 있는가?
• resize 대상의 최대 delta와 node reserve를 숫자로 정했는가?
• victim 후보가 idempotency, checkpoint/safe retry, termination 시간, queue lease 검증을 통과했는가?
• PriorityClass 기본값을 암묵적으로 사용하는 Pod와 stateful·결제·migration workload를 자동 victim에서 제외했는가?
• PDB를 실제 preemption 흐름과 cluster version에서 검증했으며, PDB만을 data integrity 보증으로 쓰지 않는가?
• 1개 pool·1~2 deployment·48시간 canary의 preemption 상한과 abort 조건을 정했는가?
• gate off, victim scale-out, high-priority resize 취소의 rollback owner와 10분 이내 판단 기준이 문서화됐는가?

연습: restart 없는 확장과 안전한 중단을 함께 증명하기

1. constrained staging node에 4 CPU high-priority Pod와 3 CPU low-priority batch Pod를 배치해 1 CPU headroom을 남긴다.
2. high-priority Pod를 6 CPU로 resize해 ResizeDeferred가 발생하는지 확인한다.
3. feature gate를 시험 환경에만 켠 뒤, low-priority Pod가 preempt됐을 때 checkpoint·queue re-delivery·idempotency key가 중복 side effect 없이 복구되는지 검사한다.
4. high-priority Pod의 allocatedResources, p99, error rate와 low-priority job의 lag·완료 수를 같은 시간축에 놓는다.
5. 마지막으로 victim을 보호 대상(PDB가 있는 stateful Pod 또는 non-idempotent worker)으로 바꾼 fixture에서 automation을 허용하지 않고 alert/abort로 끝나는지 테스트한다.