Elastic Pod CPU Auto-Scaler (EPCAS): An Open-Source Kubernetes Operator for Restart-Free Vertical CPU Scaling With Typed-Refusal Semantics
Abstract
Kubernetes 1.35 stabilized in-place Pod resource resizing, but a deployable controller must avoid duplicate actuation, decline infeasible changes safely, and make blocked actions distinguishable from controller failure. This paper presents Elastic Pod CPU Auto-Scaler (EPCAS), an open-source operator for restart-sensitive services. EPCAS combines resize-in-progress detection, metrics-readiness gating, throttling-aware classification, and stability controls whose outcomes are exposed through custom-resource status. Its <monospace>InPlaceOnly</monospace> mode reports typed refusals such as <monospace>WouldChangeQosClass</monospace> before mutation, and its container-scoped policy directs added CPU to hot containers in multi-container Pods. Repeated HTTP trials on a three-node Amazon Elastic Kubernetes Service cluster are supplemented by contract, stateful-service, sidecar, and Google Kubernetes Engine checks, including a source-frozen 12-node heterogeneous protocol. In the core suite, EPCAS records zero time above a fixed 200 ms 95th-percentile latency target, zero Pod replacements, and 3.2 s mean unavailability; a restart-threshold baseline records 196.2 s mean unavailability and 42 replacements with comparable latency relief. EPCAS uses <inline-formula> <tex-math notation="LaTeX">$2.4\times $ </tex-math></inline-formula>–<inline-formula> <tex-math notation="LaTeX">$3.3\times $ </tex-math></inline-formula> the requested CPU of VPA over these short windows, while a longer-horizon VPA check reaches the same measured service outcomes with lower allocation. A sensitivity and break-even analysis makes this continuity premium explicit. The evidence supports EPCAS as a specialized first-cycle protection path, not a generally superior autoscaler. Source, manifests, experiment drivers, and regeneration scripts are public.