KEDA - Kubernetes Event-driven Autoscaling: AI-Optimized Technical Reference

Overview

KEDA (Kubernetes Event-driven Autoscaler) is a CNCF graduated project that addresses Kubernetes' critical autoscaling limitation: HPA only scales based on CPU/memory metrics, not actual workload events. KEDA scales pods based on real events (message queues, database changes, HTTP requests) and can scale to zero when idle.

Latest Version: v2.17.2 (June 2024)
Kubernetes Requirement: v1.23+ (recommended), v1.17+ (limited features)

Core Problem & Solution

Critical HPA Limitation

• Traditional HPA scales only on CPU/memory metrics
• Real-world example: Redis queue with 40,000-50,000 messages, but low CPU means HPA won't scale
• Result: Response times degrade while HPA remains inactive
• Impact Severity: Production systems fail to scale under actual load conditions

KEDA's Approach

• Monitors 70+ external event sources directly
• Translates external metrics to Kubernetes-compatible format
• Enables scale-to-zero capability (actual zero pods, not minimum 1)
• Scale-up timing: 30-60 seconds from zero (not "within seconds" as marketed)

Architecture Components

KEDA Operator

• Monitors external event sources
• Creates ScaledObjects and ScaledJobs
• Resource Requirements: 400-500MB RAM (not documented 200MB), variable CPU based on scaler count

Metrics Server

• Translates external metrics for Kubernetes HPA consumption
• Single external metrics server per cluster (no multiple KEDA installations)

Scalers

• 70+ supported services including Kafka, Redis, RabbitMQ, AWS SQS, Azure Service Bus, Prometheus
• Polling frequency: Every 30 seconds default
• API cost impact: Each scaler generates constant API calls to event sources

Production Configuration

Resource Requirements (Actual vs Documented)

Component	Documented	Production Reality
RAM	200MB	400-500MB minimum
CPU	100m	Variable, can spike to 700-800MB with 200+ ScaledObjects
Network	Not specified	Constant API polling every 30 seconds per scaler

Critical Configuration Settings

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: worker-deployment
  minReplicaCount: 1    # CRITICAL: Don't set to 0 in production without cold start planning
  maxReplicaCount: 20   # MANDATORY: Prevent resource exhaustion
  triggers:
  - type: redis
    metadata:
      address: redis.default.svc.cluster.local:6379  # Use full Kubernetes service name
      listName: work-queue
      listLength: '5'
    authenticationRef:
      name: redis-auth

Critical Failure Scenarios

Silent Authentication Failures

• Problem: TriggerAuthentication fails without visible errors
• Impact: ScaledObjects remain inactive indefinitely
• Detection: kubectl logs -l app=keda-operator -n keda | grep -i auth
• Common causes: Typos in secret names, incorrect RBAC permissions, missing TriggerAuthentication

Operator Crashes and Recovery

• Failure modes: Memory pressure, certificate issues, network timeouts
• Impact: All scaling stops at current replica count until recovery
• Detection: Monitor keda_scaler_errors_total and keda_scaled_object_paused metrics
• Mitigation: Multiple replicas, proper resource limits, alerting

Scale-to-Zero Production Gotchas

• Cold start reality: 30-60 seconds minimum, longer with large images
• User impact: Timeouts on user-facing APIs
• Infrastructure issues: Some cloud load balancers fail with zero targets
• PVC cleanup: PersistentVolumeClaims not automatically cleaned with ScaledJobs

Scaler Reliability Assessment

Production-Ready Scalers

Scaler	Reliability	Common Issues	Notes
Apache Kafka	High	Consumer lag calculation	Solid for event processing
RabbitMQ	High	Requires management plugin	Queue depth scaling reliable
AWS SQS	High	IRSA configuration	Approximate message count sufficient
Redis	Medium	Connection timeouts	Works well with proper auth
Cron	High	Timezone configuration	Perfect for predictable workloads

Problematic Scalers

Scaler	Issues	Alternative
Prometheus	PromQL debugging difficulty	Test queries in Prometheus first
HTTP Add-on	Experimental status	Use cloud-specific solutions or HPA

Cost Analysis

Cost Savings

• Scale-to-zero: ~60% reduction in staging environment costs
• Event-driven scaling: More precise resource allocation vs CPU-based scaling
• Hidden costs: Increased API calls to event sources, monitoring overhead

Cost Considerations

• AWS CloudWatch API: $0.01 per 1,000 requests (significant with many scalers)
• Increased monitoring complexity
• Operational overhead for scaler management

Deployment Best Practices

Installation Method

# Recommended: Use Helm, not YAML manifests
helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --namespace keda --create-namespace

Time: ~2 minutes success, ~3 hours with YAML manifests due to certificate and RBAC issues

OpenShift Specific

• Use OperatorHub instead of Helm
• Handles security context constraints automatically

Essential Monitoring

# Required Prometheus metrics
- keda_scaler_errors_total        # Scaler failures
- keda_scaled_object_paused       # Broken scaling
- keda_metrics_server_*           # API server health

Decision Criteria

Use KEDA When

• Event-driven workloads with specific triggers
• Variable traffic patterns where CPU scaling fails
• Cost-sensitive environments requiring scale-to-zero
• Integration with external services HPA cannot monitor

Avoid KEDA When

• Simple web applications with predictable CPU-based scaling
• Real-time systems requiring sub-second response times
• Stateful workloads that cannot handle restarts
• Teams lacking understanding of event sources

Migration Strategy

1. Test KEDA alongside HPA on non-production workloads
2. Map existing CPU/memory triggers to KEDA equivalents
3. Remove HPA before deploying ScaledObjects (they conflict)
4. Monitor for scaling storms and resource exhaustion

Common Production Failures

Database Scaling Storm Example

• Scenario: Scaler with unbounded database query scanning entire user table every 30 seconds
• Impact: Database failure, 2-hour recovery time
• Root cause: Missing WHERE clause in monitoring script
• Prevention: Test all queries under load before production deployment

Memory Pressure Incident

• Scenario: 200 ScaledObjects deployed simultaneously
• Impact: KEDA operator memory spike to 700-800MB, eventual crash
• Recovery: 3 hours, manual intervention required
• Prevention: Gradual rollout, resource monitoring, replica limits

Troubleshooting Workflow

1. Check HPA status: kubectl get hpa and kubectl describe hpa [name]
2. Verify KEDA operator logs: kubectl logs -l app=keda-operator -n keda
3. Test authentication separately: Validate TriggerAuthentication before ScaledObject
4. Verify network connectivity: Ensure cluster can reach event sources
5. Monitor scaling metrics: Check for silent failures in Prometheus

Resource Links

• Official Documentation: Complete configuration reference
• Troubleshooting Guide: Production debugging steps
• Scalers Catalog: All 70+ supported event sources
• GitHub Issues: Real production problems and solutions
• KEDA Slack (#keda): Active community support