KubeElasti vs KEDA HTTP Add-on

This document provides a comprehensive technical comparison between KubeElasti and KEDA HTTP Add-on, specifically focusing on HTTP-based scaling scenarios with scale-to-zero capabilities.

Architecture Overview

KubeElasti Architecture

KubeElasti implements a dual-mode architecture with intelligent traffic management:

• Controller/Operator: Manages ElastiService CRDs and orchestrates scaling decisions based on configurable triggers
• Resolver: Acts as HTTP proxy/load balancer with dynamic routing capabilities
• Smart Mode Switching: Automatically switches between modes based on replica count
• Dual Mode Operation:
  • Proxy Mode (Replicas = 0): Intercepts/queues and buffers traffic until pods are brought online.
  • Serve Mode (Replicas > 0): Bypasses proxy for direct routing, maximizing throughput and minimizing latency.
• Prometheus Integration: Built-in metrics collection and query-based scaling triggers

KEDA HTTP Add-on Architecture

KEDA HTTP Add-on provides event-driven autoscaling through a proxy-based system:

• KEDA Operator: Manages ScaledObject CRDs and HPA integration
• HTTP Add-on Operator: Manages HTTPScaledObject CRDs and configures interceptors
• HTTP Interceptor: Always-on proxy that handles all HTTP traffic and maintains request queues
• External Scaler: Communicates queue metrics to KEDA using external-push scaler pattern
• HPA Integration: Leverages Kubernetes HPA for actual scaling operations

Scaling Mechanisms

Traffic Management Patterns

KubeElasti Traffic Flow

[In Proxy]
Client Request → Resolver → Target Service
↓
Prometheus Metrics → Controller → Scaling Decision → Mode Switch

[In Serve]
Client Request → Target Service
↓
Prometheus Metrics → Controller → Scaling Decision → Mode Switch

Proxy Mode (Replicas = 0): Resolver acts as reverse proxy, queues requests during scaling Serve Mode (Replicas > 0): Direct routing to target service, resolver out of critical path

KEDA HTTP Add-on Traffic Flow

Client Request → HTTP Interceptor (Always-On) → Target Service
↓
Queue Metrics → External Scaler → KEDA Operator → HPA → Scaling Decision

Always-On Proxy: HTTP interceptor remains in request path regardless of scaling state Queue-Based Metrics: Scaling decisions based on in-flight request count and pending queue depth

Configuration Complexity

KubeElasti Configuration

apiVersion: elasti.truefoundry.com/v1alpha1
kind: ElastiService
metadata:
  name: example-service
  namespace: default
spec:
  service: example-service
  minTargetReplicas: 1
  cooldownPeriod: 300
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: target-deployment
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: 'sum(rate(http_requests_total[1m])) or vector(0)'
        threshold: '0.1'

KEDA HTTP Add-on Configuration

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: example-http-scaledobject
spec:
  hosts:
    - example.com
  scaleTargetRef:
    deployment: target-deployment
    service: target-service
    port: 8080
  replicas:
    min: 0
    max: 10
  scaledownPeriod: 300
  targetPendingRequests: 100
---
# Note: ScaledObject is automatically created by the HTTPScaledObject operator
# with external-push trigger configuration

Performance Characteristics

• KubeElasti: Higher throughput in serve mode due to direct routing bypass
• KEDA HTTP Add-on: Consistent throughput with always-on proxy, but potential bottleneck under high load

Operational Considerations

KubeElasti

Advantages: - Intelligent mode switching reduces proxy overhead during normal operations - Built-in Prometheus integration with flexible query-based triggers - Simpler architecture with fewer moving components - Lower resource footprint when scaled up (serve mode)

Limitations: - Requires Prometheus for advanced scaling capabilities - Newer project with smaller ecosystem and community - Limited scaler types compared to KEDA - Less enterprise adoption

KEDA HTTP Add-on

Advantages: - Mature ecosystem with extensive scaler support (70+ built-in scalers) - Standard HPA integration with Kubernetes-native patterns - Multiple trigger types beyond HTTP (databases, queues, etc.)

Limitations: - Always-on proxy overhead even when not scaling - More complex multi-component architecture (operator + interceptor + scaler) - Beta stage with potential production limitations - Limited customization of scaling algorithms

Technical Trade-offs Summary

Use Case Recommendations

Choose KubeElasti When

• Performance optimization is critical (serve mode benefits are significant)
• Prometheus-centric monitoring stack already in place
• Simplified operational model preferred with fewer components
• Direct routing benefits outweigh always-on proxy patterns
• Resource efficiency during scaled-up state is important

Choose KEDA HTTP Add-on When

• Multi-trigger scaling requirements (HTTP + queue + database triggers)
• Enterprise support and ecosystem maturity needed
• Existing KEDA infrastructure already deployed
• Beta limitations acceptable for your use case
• Consistent proxy behavior preferred over mode switching

Conclusion

Both KubeElasti and KEDA HTTP Add-on solve the scale-to-zero challenge for HTTP workloads but with fundamentally different architectural approaches. KubeElasti's dual-mode architecture offers performance benefits when scaled up. KEDA HTTP Add-on provides proven patterns with extensive ecosystem support but maintains always-on proxy overhead.

The choice between them should be based on your specific requirements for performance, operational complexity, ecosystem maturity, and long-term architectural goals.