Who does what
| Job | KEDA | Coral |
|---|---|---|
Setting how many pods run | Sets the count from its triggers, down to zero, through the HPA it creates. | Never takes over or changes that HPA. |
Pod CPU and memory requests | Doesn’t change them. | Rebalances them to real use, once you switch on “Automatically optimize”. |
Running the workload’s HPA | Creates and runs its own. | Creates none of its own for a workload KEDA scales. |
Starting a new copy before a pod moves in a rebalance | Passes Coral’s raised minimum to its HPA, which adds the new copy. | Can raise the ScaledObject’s minimum while a pod moves, so a new copy runs healthy on another node first. |
Removing spare nodes | Doesn’t add or remove nodes. | Empties spare nodes so your node autoscaler can remove them. |
How they work together
KEDA reads its triggers and sets how many pods run, through the HPA it creates.
Coral reads your ScaledObjects, so it knows which HPAs KEDA owns and leaves them alone.
Once you switch on “Automatically optimize”, Coral rebalances each pod’s CPU and memory requests to real use.
With a CPU trigger, unless the ScaledObject is paused, Coral replays recent load through its settings before it picks the CPU request.
In a rebalance, Coral can raise the ScaledObject’s minimum, so a new copy runs healthy on another node before the old pod stops.
What Coral leaves to KEDA
- How many pods run, scaling to zero included. Coral never takes over, converts or changes the HPA that KEDA creates.
- Your triggers and every other ScaledObject setting. Coral changes only the minimum and maximum, and only during a rebalance.
- Your Git. Coral never edits Git or your workload’s template.
Set up
- Nothing to install for KEDA. Connect lets the agent read your ScaledObjects and, in a rebalance, change only their minimum and maximum. Admission policies limit what the agent may change.
- Pod sizing is opt-in. Coral only recommends until you switch on “Automatically optimize” for a policy or a workload.
- Rebalancing needs Karpenter or AKS node auto provisioning (NAP). It also needs Node optimization on and the permission to remove nodes.
Questions
Will Coral and KEDA fight over the replica count?
No. KEDA decides how many pods run, and Coral decides how big each pod is. Coral never takes over or changes the HPA that KEDA creates.
Does Coral ever change my ScaledObject?
Only during a rebalance, and only its minimum and maximum. To move a pod, Coral can raise the minimum, so a new copy runs healthy on another node before the old pod stops. Then it puts your values back.
Could smaller requests make KEDA add more pods?
It could, with a CPU or memory trigger on utilization, since the same load reads as higher use of a smaller request. For a CPU trigger on a ScaledObject that isn’t paused, Coral replays recent load through its settings. In that replay, a smaller request wins only if its saving beats the cost of unserved load and extra scaling.
Does Coral create its own HPA for a KEDA workload?
No. Coral creates an HPA only for a Deployment or Argo Rollout that has none, and never for one KEDA scales.
What happens to KEDA’s pods when Coral empties a spare node?
Outside a rebalance, Coral moves them without starting a new copy first, so a pod can get a short restart. To prevent that, mark the pod karpenter.sh/do-not-disrupt, which also keeps its node.
Read more
- Coral product guide: HPAs and VPAs: which HPAs Coral creates, takes over or leaves alone.
- Coral FAQ: Working with HPA: who wins when the HPA and Coral both act.
- KEDA vs Karpenter: pods, nodes and the requests in between: what each one scales, and where Coral fits.
- What is HPA (Horizontal Pod Autoscaler)?: the autoscaler that KEDA creates and drives.
- Coral works with Karpenter: how Coral and Karpenter share the nodes on EKS.