by Zbynek Roubalik

August 12, 2025

Introduction

With HTTP traffic scaling in Kubernetes, most solutions focus on routing by host and path. That works for simple use cases—but what if you want to split or scale traffic based on user type, version headers, or feature flags?

Now you can. Kedify’s HTTP scaler supports routing and scaling by HTTP headers, unlocking use cases like:

• Canary and A/B testing
• Customer-tier specific scaling
• Preview deployments for authenticated users

:::tip On top of autoscaling, this feature also brings several Gateway API-style features to vanilla Kubernetes Ingress setups:

• Load balancing by HTTP headers
• Automatic retries with backoff
• Custom header injection for requests and responses :::

Let’s dive into how it works and why it matters.

Try Kedify’s ROI Calculator now

See how Kedify helps you scale smarter, with real ROI.

Get Started

Why Routing by Headers?

Sometimes host and pathPrefix aren’t enough.

Imagine a scenario when you are rolling out a new feature to 10% of your users using a header like X-Canary-Group: beta. Or you’re serving traffic to enterprise customers with X-Customer-Tier: gold, which requires higher performance and separate scale profiles.

Header-based routing allows you to:

• Route requests more precisely
• Scale independent groups of traffic
• Avoid breaking changes to URL paths or DNS

This gives product and platform teams more flexibility while keeping deployments clean and decoupled.

How It Works

Kedify HTTP scaler now supports defining HTTP headers as part of the routing and scaling trigger:

triggers:
  - type: kedify-http
    metadata:
      hosts: www.my-app.com
      pathPrefixes: '/'
      service: my-app-service
      port: '8080'
      scalingMetric: requestRate
      targetValue: '10'
      headers: |
        - name: X-Customer-Tier
          value: gold

This configuration ensures only requests with the matching header hit this scaled service.

Multiple kedify-http triggers can be defined within the same ScaledObject as long as they use distinct combinations of host, pathPrefix, or headers. This allows fine-grained segmentation while sharing the same deployment.

Defining header rules:

• You can use headers alongside hosts and pathPrefixes
• Headers are matched exactly by name and value
• The most specific match (by host, path, then headers) wins

Example: Canary Rollout

You want to test a new version of your API with a select group of users sending X-API-Version: 2.

triggers:
  - type: kedify-http
    name: stable
    metadata:
      hosts: api.my-company.com
      pathPrefixes: '/v1'
      service: api-v1-service
      port: '8080'
      scalingMetric: requestRate
      targetValue: '100'

  - type: kedify-http
    name: canary
    metadata:
      hosts: api.my-company.com
      pathPrefixes: '/v1'
      service: api-v2-service
      port: '8080'
      scalingMetric: requestRate
      targetValue: '20'
      headers: |
        - name: X-API-Version
          value: 2

This routes most users to api-v1-service, while the X-API-Version: 2 group goes to the canary api-v2-service.

Try It Out

Header-based routing is available now in Kedify’s HTTP scaler. See the docs for more on trigger metadata and routing behavior or book a consult to talk with a founding maintainer of KEDA.

Whether you’re launching new features or managing traffic tiers, this lets you autoscale smarter—with full control over who goes where.

Built by the core maintainers of KEDA. Battle-tested with real workloads.