Learn KEDA - KEDA HTTP Add-on Deep Dive
Dissecting the KEDA HTTP Add-on architecture: the interceptor that holds requests during scale-to-zero, the operator, HTTPScaledObject, hosts, timeout, and its limitations on Kubernetes 1.30 and how to handle them in production.
#Introduction
In episode 11 you mastered fallback and advanced tuning. Now it's time to dive fully into the most frequently asked-about add-on: KEDA HTTP Add-on. In episode 9 we briefly touched on HTTPScaledObject. The core problem is this: HTTP workloads usually aren't safe to scale-to-zero, because requests arriving when there are zero pods fail immediately. The HTTP Add-on answers this by inserting an interceptor layer in front of the application — and in doing so opens the door to an accurate pending requests scheme. Before writing any configuration, it's important to understand who does what inside this add-on.
#HTTP Add-on Architecture
The request flow with the HTTP Add-on:
Client
| request masuk
v
Ingress -> Interceptor (buffer saat replika 0)
|
+---> Deployment (pod aplikasi) setelah skala naik
|
+---> KEDA operator + HPA (membaca pending requests)Three components work together:
- Interceptor: catches requests, buffers them while there are no pods, counts pending requests, then forwards requests as soon as a pod is ready.
- Add-on operator: manages HTTPScaledObject and creates the interceptor along with its related HPA.
- HTTP scaler: reads the number of requests held by the interceptor as the scaling metric.
These components are installed as a separate Helm chart, not part of the main KEDA installation. After installation, make sure the CRD is recognized via kubectl get httpscaledobjects -n keda.
#Installation
helm repo add kedacore https://kedacore.github.io/charts
helm install keda-add-ons-http kedacore/keda-add-ons-http \
--namespace keda --create-namespace
kubectl get pods -n keda -l app.kubernetes.io/name=keda-add-ons-httpVerify that the add-on's interceptor, operator, and scaler appear in the Running state before creating an HTTPScaledObject.
#Configuring HTTPScaledObject
apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
name: web-app
namespace: production
spec:
hosts:
- api.contoh.com
scaleTargetRef:
deployment: web-app
service: web-app-svc
port: 8080
replicas:
min: 0
max: 10
activation: 20
scalingMetric:
targetPendingRequests: 100
cooldownPeriod: 300| Field | Function |
|---|---|
hosts | Domains routed to the interceptor |
scaleTargetRef.deployment | The Deployment being scaled |
scaleTargetRef.service | The application's internal Service |
replicas.min | Minimum replicas; 0 enables scale-to-zero |
replicas.max | Maximum replicas |
replicas.activation | Pending threshold before scaling from zero |
scalingMetric.targetPendingRequests | Target pending requests per pod |
cooldownPeriod | Delay before scale-down |
When a request arrives, the interceptor counts it as pending. If it exceeds activation, the add-on scales up pods. A new pod is considered ready only after it's able to accept requests — only then are the buffered requests released.
#Handling Requests During Scale-to-Zero
While there are no pods, the interceptor keeps accepting connections and holds requests in memory. Understand that the interceptor is a buffer, not storage: requests held too long will be cancelled by the timeout. For applications with a long cold start, enlarge the scale-up window and the buffer capacity.
Tip
Set the interceptor's buffer capacity larger than your biggest request spike. If the buffer fills up, requests are answered with 503. Make sure the capacity is enough to cover your application's cold start window — for example 30 seconds from zero pods to pod ready.
#Limitations and Production Notes
A few things you must note before taking this to production:
- Kubernetes 1.30+: the interceptor endpoint discovery mechanism changed; older add-on versions based on EndpointSlice are no longer compatible. Make sure the HTTP Add-on version you use already has the latest interceptor before upgrading the cluster.
- One deployment, one HTTPScaledObject: don't create two HTTPScaledObjects for the same deployment, or the HPAs will conflict with each other.
- TLS: TLS termination can be done at the Ingress, or at the interceptor via the
tlsSecretfield onscaleTargetRef. - Multiple hosts: one HTTPScaledObject supports many entries in
hosts, great for routing several domains to the same workload. - Resilience: install fallback (episode 11) and monitor pending request metrics plus
keda_scaler_errors_totalso add-on failures are detected early.
Warning
The interceptor isn't a replacement for an ingress controller — the HTTP Add-on is routed through the Ingress. For production, schedule the interceptor separately from application pods (a dedicated node pool if necessary) so the buffer stays available when the application scales to zero, and never store state in the interceptor.
#Conclusion
- HTTP Add-on = interceptor (request buffer) + operator + HTTP scaler, installed as a separate chart.
- HTTPScaledObject manages hosts, target deployment, min/max/activation, and
targetPendingRequests. - During scale-to-zero, the interceptor holds requests until a pod is ready — but it's a buffer, not storage.
- Set buffer capacity and timeout according to your application's cold start.
- Monitor pending request metrics and
keda_scaler_errors_totalfor early failure detection. - K8s 1.30+ needs the new interceptor version; one deployment can only have one HTTPScaledObject.
Workloads can now be scaled and functionally secured. But there's one side we haven't seriously touched: credential security. In episode 13 we discuss Security & Credentials — secret management best practices, podIdentity IRSA, Azure AD Workload Identity, GCP IAM, HashiCorp Vault integration, rotation, and least privilege policies for accessing queues and streams from the KEDA operator. See you there!