HTTP Scaling with TLS for Ingress-Based Applications

This guide demonstrates how to scale applications exposed via Kubernetes Ingress with HTTPS enabled using the kedify-http scaler. It builds on standard HTTP-based autoscaling by adding TLS support for end-to-end encrypted workloads.

You’ll deploy a sample application configured with TLS, expose it via NGINX Ingress, and configure a ScaledObject that supports encrypted traffic. This works seamlessly with Kedify’s traffic autowiring system, enabling scaling to zero based on secure HTTP(S) traffic.

Architecture Overview

For TLS workloads using Ingress, Kedify intercepts traffic and collects encrypted traffic metrics without interfering with your TLS setup.

HTTPS Ingress -> kedify-proxy (with TLS support) -> Service -> Deployment

You can use any ingress controller that supports HTTPS. In this guide, we use NGINX Ingress with self-signed certificates.

Prerequisites

A Kubernetes cluster (local or remote)
The kubectl CLI installed and configured
A connected cluster in the Kedify Dashboard
openssl cli (for generating self-signed certs)
hey for load testing

To follow along locally:

Create a k3d cluster with HTTP/HTTPS ports and no Traefik:

k3d cluster create \
  --port "9080:80@loadbalancer" \
  --port "9443:443@loadbalancer" \
  --k3s-arg "--disable=traefik@server:*"

Install NGINX Ingress:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install nginx-ingress ingress-nginx/ingress-nginx \
  --namespace nginx-ingress \
  --create-namespace \
  --set controller.publishService.enabled=true \
  --set controller.service.type=LoadBalancer

Step 1: Deploy a TLS-Enabled Application

Start by generating a self-signed TLS certificate and storing it as a Kubernetes secret:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=tls-demo.keda/O=tls-demo.keda"

kubectl create secret tls http-server-tls \
  --cert=tls.crt --key=tls.key

Now deploy the application with TLS support:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-server-tls
spec:
  replicas: 1
  selector:
    matchLabels:
      app: http-server-tls
  template:
    metadata:
      labels:
        app: http-server-tls
    spec:
      containers:
        - name: http-server
          image: ghcr.io/kedify/sample-http-server:latest
          ports:
            - containerPort: 8443
          env:
            - name: RESPONSE_DELAY
              value: '0.3'
            - name: TLS_ENABLED
              value: 'true'
            - name: TLS_CERT_FILE
              value: '/certs/tls.crt'
            - name: TLS_KEY_FILE
              value: '/certs/tls.key'
          volumeMounts:
            - name: tls-certs
              mountPath: /certs
              readOnly: true
      volumes:
        - name: tls-certs
          secret:
            secretName: http-server-tls
---
apiVersion: v1
kind: Service
metadata:
  name: http-server-tls
spec:
  ports:
    - name: https
      port: 443
      targetPort: 8443
  selector:
    app: http-server-tls

Deployment: A Go-based HTTP server configured to respond over HTTPS.
Service: Exposes the HTTPS port to other cluster resources.
Secret: Contains the TLS certificate and private key.

Apply the resources:

kubectl apply -f http-server-tls.yaml

Step 2: Expose the Application with Ingress

Now expose your service to external traffic via HTTPS with NGINX:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-server-tls
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: 'HTTPS'
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - tls-demo.keda
      secretName: http-server-tls
  rules:
    - host: tls-demo.keda
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: http-server-tls
                port:
                  number: 443

Apply it:

kubectl apply -f http-server-tls-ingress.yaml

Ingress: Exposes the HTTPS endpoint to the outside world using NGINX.
backend-protocol: HTTPS: Ensures NGINX talks to the app using TLS internally.
tls: Points to the TLS secret and hostname.

Step 3: Apply ScaledObject for TLS

Configure a ScaledObject to monitor HTTPS traffic on port 443:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: http-server-tls
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: http-server-tls
  cooldownPeriod: 5
  minReplicaCount: 0
  maxReplicaCount: 10
  fallback:
    failureThreshold: 2
    replicas: 1
  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 5
  triggers:
    - type: kedify-http
      metadata:
        hosts: tls-demo.keda
        service: http-server-tls
        port: '443'
        scalingMetric: requestRate
        targetValue: '10'
        granularity: 1s
        window: 10s
        tlsSecretName: http-server-tls

Apply it:

kubectl apply -f scaledobject-tls.yaml

type (kedify-http): Specifies the Kedify HTTP scaler for monitoring HTTP traffic.
metadata.hosts (application.keda): The hostname to monitor for traffic.
metadata.pathPrefixes (/): The path prefix to monitor.
metadata.service (application-service): The Kubernetes Service associated with the application.
metadata.port (443): The port on the service to monitor.
metadata.scalingMetric (requestRate): The metric used for scaling decisions.
metadata.targetValue (1000): Target request rate; KEDA scales out when traffic meets or exceeds this value.
metadata.granularity (1s): The time unit for the targetValue (requests per second).
metadata.window (10s): Granularity at which the request rate is measured.
metadata.trafficAutowire (ingress): Enables Kedify’s ingress autowiring feature.
metadata.tlsSecretName(http-server-tls) References the Secret with the certificate, ensures KEDA can trust your TLS traffic.

You should see the ScaledObject in the Kedify Dashboard:

Kedify Dashboard With ScaledObject

Step 4: Test HTTPS Autoscaling

To verify the server responds:

# If testing locally with k3d (if testing on a remote cluster, use the Ingress IP or domain)
# we are also skipping self-signed cert verification via -k

You should receive a 200 OK with the server’s HTML:

HTTP/2 200
date: Tue, 29 Apr 2025 12:47:02 GMT
content-type: text/html
content-length: 301
x-keda-http-cold-start: true
x-envoy-upstream-service-time: 3124
strict-transport-security: max-age=31536000; includeSubDomains

To trigger scaling:

# If testing locally with k3d (if testing on a remote cluster, use the Ingress IP or domain)
hey -n 10000 -c 150 -host "tls-demo.keda" https://localhost:9443/

Response time histogram:
  0.301 [1]      |
  0.498 [9749]  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.695 [0]      |
  0.892 [0]      |
  1.090 [0]      |
  1.287 [0]      |
  1.484 [0]      |
  1.681 [53]    |
  1.878 [0]      |
  2.075 [53]    |
  2.272 [44]    |

In the Kedify Dashboard, you can also observe the traffic load and resulting scaling:

Kedify Dashboard ScaledObject Detail

Next Steps

This guide showed how to scale applications securely using HTTPS.
You can extend this setup using production TLS certificates from cert-manager or your preferred provider.
Explore the full HTTP Scaler documentation to tune scaling metrics, fallback behavior, and integration with other Ingress providers.