Updated 9 October 2026 · Published by Zoorik
Short answer. Kubernetes’ own autoscalers each change one thing: the VPA sizes pods, the HPA and KEDA set the pod count, and the Cluster Autoscaler, NAP and Karpenter add and remove nodes. Coral doesn’t replace them. It sizes requests to real use, drains spare nodes for your node autoscaler to remove, and shows what each change saves at list price.
What each autoscaler does
| Autoscaler | What it changes | What it decides from |
|---|---|---|
Vertical Pod Autoscaler (VPA) | Each pod’s CPU and memory requests | Each container’s usage history |
Horizontal Pod Autoscaler (HPA) | The number of pods | Usage divided by request, or custom and external metrics |
KEDA | The number of pods, down to zero | Event sources such as queues, through an HPA it manages |
Cluster Autoscaler | The number of nodes in node groups of fixed machine types | Pending pods, to add nodes; pod requests against node capacity, to remove them |
Node Auto Provisioning (NAP), on AKS | Nodes and their VM sizes | Pending pods’ requests. It also consolidates nodes, and it is built on Karpenter. |
Karpenter, on EKS | Nodes and their instance types | Pending pods’ requests. It also consolidates nodes. |
Every node autoscaler here counts requests, not use. A request set far above real use keeps a node alive.
What Coral does with each
| Autoscaler | With Coral |
|---|---|
VPA | Coral does the VPA’s job with its own recommender and webhook, and doesn’t run the VPA. With automation on, it switches an active VPA to Off and restores it when you switch automation off or disconnect. It never fights a VPA. |
HPA | The HPA keeps deciding how many pods run, and Coral decides how big each pod is. For a CPU-based HPA, Coral replays 3 days of load through the HPA’s settings before it lowers a request. With automation on and the Optimization type “Both”, it creates HPAs for eligible Deployments and Argo Rollouts, and takes over hand-made ones that nothing else manages. |
KEDA | Workload optimization never creates, takes over or edits a KEDA-owned HPA or ScaledObject. KEDA keeps the scaling. |
Cluster Autoscaler | Coral drains spare nodes one at a time, and the Cluster Autoscaler removes them. With only the Cluster Autoscaler, Coral removes nodes but never changes their size. |
NAP | Coral sizes requests so NAP needs fewer or smaller VMs. With NAP, Coral can also move work to smaller or cheaper machines. Pools NAP already consolidates are left to it. |
Karpenter | Coral sizes requests so Karpenter needs fewer or smaller instances. With Karpenter, Coral can also move work to smaller or cheaper machines. Pools Karpenter already consolidates are left to it. |
No autoscaler | Connect sets up NAP on AKS (with Azure CNI) or Karpenter on EKS, with your approval. Until an autoscaler exists, nothing adds nodes. |
What Coral adds
- Requests sized from measured use, by policy or per workload, without editing manifests or Git.
- HPA-aware sizing: a smaller request wins only if its saving beats the cost of unserved load and extra scaling.
- Safe node draining: a scheduler check on the live cluster, one node at a time, within PodDisruptionBudgets.
- Fast raises after OOM kills, failing probes and CPU pressure.
- A cost view at list price: what each node and workload costs, what can be recovered, and a cluster score of 10 × optimal ÷ current cost.
- Nodes held, each with its reason and its fix.
- It honours the markers you already use:
karpenter.andsh/ do-not-disrupt cluster-autoscaler..kubernetes. io/ safe-to-evict
How they work together in a surge
Load rises and the HPA adds pods. While the HPA is scaling up and below its max, Coral holds back its own surge and CPU-pressure raises, and pauses pod replacements until every pod is Ready; an OOM kill still raises memory at once. Pods that don’t fit stay pending, and your node autoscaler adds nodes. Karpenter and NAP can pick bigger machines. Coral keeps no idle spare nodes: the headroom sits inside each pod’s request. When load falls, the HPA removes pods, Coral drains the nodes that empty out, and your autoscaler removes them.
What Coral doesn’t do
- Create machines for demand, or change your autoscaler’s settings.
- Edit your manifests, pod templates or Git sources.
- Forecast. Coral reacts to live usage, and its longest look-back is 8 days. For a known event, set minimums, or pause node optimization and the Evictor.
- Read latency or error rates. It reacts to OOM kills, failing probes and CPU pressure.
- Lower the CPU or memory limits of regular pods.
Sources: kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale (opens in a new tab); github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler (opens in a new tab); github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md (opens in a new tab); keda.sh/docs (opens in a new tab); karpenter.sh/docs (opens in a new tab); learn.microsoft.com/en-us/azure/aks/node-auto-provisioning (opens in a new tab).