ScaledObject (KEDA)
Does ZopNight manage ScaledObject (KEDA)?
ScaledObjects scale a target workload on external signals such as queue depth, and unlike an HPA can hold it at 0 replicas between events. ZopNight lists them through the keda.sh/v1alpha1 API, recording scale target, minReplicaCount, maxReplicaCount, and trigger types, and uses KEDA presence to keep namespace schedules from fighting event-driven scaling.
Rules that fire on ScaledObject (KEDA)
No active rule family targets ScaledObject (KEDA) today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A KEDA ScaledObject scales a workload on external signals such as queue depth, stream lag, and cron windows rather than pod CPU. Its defining trick is the one an HPA cannot do: holding a workload at zero replicas between events, so idle event consumers cost nothing at all.
Event scaling with a real zero
Discovery records the scale target’s name and kind, minReplicaCount, maxReplicaCount, and the trigger list with each trigger’s type and metadata. A min of 0 is the cost-relevant setting: the workload’s capacity reservation disappears entirely until the trigger source shows work. The single-replica reliability rule explicitly skips workloads a ScaledObject targets for the same reason it skips HPA targets: a count of 1 there is the autoscaler’s deliberate choice, not missing redundancy.
Read through keda.sh/v1alpha1, tolerated when absent
ScaledObjects are custom resources, so discovery lists them through the dynamic client against keda.sh/v1alpha1. When KEDA is not installed the listing simply returns empty rather than erroring. KEDA presence is detected from the cluster’s CRD inventory, and that detection is what switches the rest of the platform into KEDA-aware behavior.
The TriggerAuthentication half of the pair
Triggers that poll authenticated sources (cloud queues, databases, SaaS APIs) reference a TriggerAuthentication object for their credentials. The two types ship as a pair: the ScaledObject says what to watch and how to scale, the TriggerAuthentication says how to log in to the source. A ScaledObject whose authentication reference is broken stops scaling silently, which is why both halves are inventoried together.
kubectl get scaledobjects -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,TARGET:.spec.scaleTargetRef.name,MIN:.spec.minReplicaCount,MAX:.spec.maxReplicaCountScheduling around KEDA instead of against it
A namespace schedule that scales workloads to 0 would ordinarily be undone by any autoscaler watching them. ZopNight uses its ScaledObject inventory to coordinate: KEDA-managed workloads are handled so event-driven scaling and scheduled downtime do not fight, and everything is restored to KEDA’s control at resume. The alternative, a scheduler and an autoscaler flapping a Deployment between 0 and 4 replicas all night, is exactly the failure mode the coordination exists to prevent.