Slashing Idle OKE Compute: Pairing KEDA with Cluster Autoscaling for Scale-to-Zero
Oracle Cloud Infrastructure (OCI) published technical architecture guidance detailing how to eliminate non-production compute waste on Oracle Kubernetes Engine (OKE) by combining Kubernetes Event-driven Autoscaling (KEDA) with the OKE Cluster Autoscaler [2.2.1]. The implementation demonstrates how to configure KEDA custom resources—specifically ScaledObjects and the KEDA HTTP Add-on—with scheduled cron triggers to scale non-production workloads down to zero replicas during inactive windows. Once pods are terminated, the OKE Cluster Autoscaler detects empty worker nodes and drains node pool capacity, cutting active compute costs. If off-hours requests arrive, the KEDA HTTP interceptor captures the traffic, restores application replicas, and triggers node scale-up.
Idle compute across development, test, integration, and pre-production environments represents a major driver of runaway enterprise cloud spend. While organizations often provision these clusters with production-like footprints, their actual utilization follows strict business-hour schedules. Standard Kubernetes Horizontal Pod Autoscaler (HPA) mechanisms rely solely on CPU and memory thresholds, which cannot natively scale workloads to zero replicas or proactively anticipate schedule boundaries. By bridging application-layer demand signals directly to infrastructure-layer node management, platform teams can eliminate persistent compute waste across large cluster fleets without requiring engineers to manually start or stop environments.
This architecture reflects a broader industry movement toward granular FinOps automation and event-driven container elasticity. KEDA, a CNCF graduated project, has become the de facto standard for extending Kubernetes autoscaling beyond internal hardware telemetry into external triggers such as message queues, cron schedules, and ingress streams. Oracle's explicit architectural backing of KEDA with OKE's managed node pools aligns OCI with modern cloud-native operational standards, ensuring that elasticity at the container runtime level directly translates into tangible billing reductions at the hypervisor level.
In practice, DevOps practitioners implementing this pattern must account for structural cluster design and latency trade-offs. Teams should isolate scalable non-production deployments into dedicated managed node pools so that scale-to-zero operations do not interfere with system add-ons or stateful components. Furthermore, managing dozens of ScaledObject definitions manually is error-prone, requiring teams to template these manifests using Helm, Kustomize, or GitOps pipelines. Finally, platform engineers must evaluate the cold-start delay incurred when waking applications from zero, configuring appropriate HTTP timeout tolerances while OCI provisions and boots underlying compute instances.
Read original source