KEDA

​

Coverage Matrix

​

KEDA Overview

KEDA (Kubernetes Event-driven Autoscaler) extends the native Horizontal Pod Autoscaler (HPA) to scale workloads based on external events such as queue depth, database activity, or cloud metrics. By adding its own operator and metrics adapter, KEDA exposes these external metrics to Kubernetes, allowing pods to dynamically scale up—or even down to zero—when no events are pending. This approach optimizes resource usage, handling spikes automatically and freeing up capacity during idle periods. KEDA supports a wide range of event sources (e.g., Kafka, RabbitMQ, Azure Event Hubs), making it easy to integrate with diverse environments while retaining the standard Kubernetes scaling model.

​

Chkk Coverage

​

Curated Release Notes

Chkk curates official KEDA release notes, highlighting important updates, deprecations, and security advisories. Instead of going through every changelog, platform teams get a concise summary of changes—like dropped support for older Kubernetes versions or new scalers—that may affect autoscaling configurations. Chkk flags breaking changes and features, helping you prioritize upgrades aligned with your operational needs.

​

Preflight & Postflight Checks

Before a KEDA upgrade, Chkk runs preflight checks to detect potential incompatibilities—such as renamed CRD fields, changed scaler parameters, or missing permissions. It also ensures your existing ScaledObjects and TriggerAuthentications will remain valid. After the upgrade, postflight checks confirm that the updated KEDA operator is healthy, verifying event triggers, metrics reporting, and successful pod scaling. Any issues—like broken triggers or pods stuck at zero replicas—are flagged for quick remediation.

​

Version Recommendations

Chkk continuously monitors KEDA’s release lifecycle and alerts you if your version is nearing end-of-life or has known vulnerabilities. It cross-references Kubernetes compatibility, patch availability, and bug reports to suggest the next stable version. By following Chkk’s guidance, you can keep KEDA up to date without risking untested or unsupported releases.

​

Upgrade Templates

Chkk offers two main upgrade strategies for KEDA: in-place and blue-green. In-place updates the existing operator, ensuring minimal downtime through a carefully orchestrated restart. Blue-green introduces a parallel “green” deployment of KEDA alongside the old “blue” one, then cuts over once validated—ideal for zero-downtime requirements or major version jumps. Both templates preserve your autoscaling configurations, preventing disruptions to event-driven scaling.

​

Preverification

For major or potentially disruptive upgrades, Chkk conducts a preverification process in a controlled environment. It deploys the new KEDA version, applies your existing manifests, and simulates the scaling behavior. This test reveals any problems with event source compatibility, authentication, or changed CRD fields before production, allowing you to address them proactively and reduce deployment risks.

​

Supported Packages

Chkk supports KEDA deployments via Helm, Kustomize, or plain Kubernetes YAML. Regardless of your chosen method, Chkk detects and manages the operator’s current version, ensuring that upgrades respect custom images or private registries. This integration aligns with typical GitOps workflows, letting you maintain KEDA the same way you handle other Kubernetes resources.

​

Common Operational Considerations

• Scale-to-Zero Latency: KEDA polls external triggers (e.g., Kafka, Prometheus) every 30s by default. A too-long polling interval leads to cold-start delays. Lower it for latency-sensitive workloads, but watch out for excessive API calls.
• Trigger Failures: If a trigger source (like Azure Service Bus) is unreachable or slow, KEDA returns zero metrics. Configure fallback replicas to avoid unintentional scale-to-zero during outages. Monitor operator logs for repeated “failed to fetch metrics” errors.
• HA Deployment: Running multiple KEDA operator pods provides failover (single-active leader). The metrics server can also run multiple pods, but only one instance serves external metrics at a time. Give operator and adapter enough CPU/memory for high-volume events.
• CRD & Config Pitfalls: Old CRDs or typos in TriggerAuthentication can silently break autoscaling. Always update CRDs alongside the operator, and confirm ScaledObject status is Ready. Use KEDA’s admission webhook to prevent duplicate HPAs or invalid triggers.
• Upgrade Impact: When jumping major versions (v1→v2), reapply updated CRDs and rewrite any old fields. For minor releases, watch for changes that might invalidate triggers (like renamed fields). Prefer a test cluster or Chkk’s preverification feature before production.

​

Additional Resources

• KEDA Documentation
• KEDA Releases