Skip to main content

Traefik Kubernetes Knative Routing Configuration

Since v3.6

The Kubernetes Provider for Knative Serving workloads.

Experimental Feature

The Knative provider is currently an experimental feature in Traefik Hub API Gateway. To use it, you must explicitly enable it in the experimental section of your configuration.

Overview​

Traefik Hub API Gateway's Knative provider enables seamless integration with Knative Serving, allowing you to use Traefik as the networking layer for serverless workloads. This integration brings together the power of Traefik's advanced routing capabilities with Knative's scale-to-zero serverless architecture.

The Knative provider watches for Knative Service events and automatically derives the corresponding routing configuration, creating the necessary routers, services, and handlers to expose your serverless applications.

Knative Service Discovery​

The Knative provider discovers Knative Service resources by monitoring the Knative Ingress Custom Resource Definitions (CRDs). Traefik leverages these CRDs to obtain routing configuration and manage traffic direction to backend services.

Supported Version​

The Knative provider supports Knative Serving specification version 1.19.0.

Service Deployment​

A Knative Service is the primary entry point for traffic in Knative Serving. Each service is linked to a Knative Ingress resource that manages traffic routing to backend services.

Basic Service Example​

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: whoami
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: traefik/whoami:latest
          env:
            - name: WHOAMI_NAME
              value: "whoami-v1"

This basic service will be automatically discovered by Traefik and exposed according to your Knative domain configuration.

Scale-to-Zero with Autoscaling​

One of Knative's most powerful features is automatic scale-to-zero, which terminates idle pods to save resources and costs. When a request arrives for a scaled-down service, Knative automatically starts the necessary pods. This is particularly valuable for AI/ML workloads where you want to avoid consuming expensive GPU resources when they're not actively processing requests.

Traefik Hub API Gateway seamlessly handles this behavior:

  • Routes are maintained even when pods are scaled to zero
  • Requests trigger automatic pod startup through Knative's activator
  • Traffic is routed to pods once they become ready
  • No manual intervention required

Autoscaling Configuration Example​

Knative supports sophisticated autoscaling policies through annotations. Here's an example that demonstrates request-per-second (RPS) based autoscaling:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: whoami
  namespace: serverless
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "rps"
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/max-scale: "10"
    spec:
      containers:
        - image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: WHOAMI_NAME
              value: "Knative Test Service"

In this configuration:

  • Autoscaling class: Uses Knative Pod Autoscaler (KPA) for request-based scaling
  • Metric: Scales based on requests-per-second (RPS) per pod instance
  • Target: Triggers scaling when each pod receives 10 RPS
  • Max scale: Limits scaling to a maximum of 10 replicas

Traffic Routing Features​

Tag-Based Routing​

Knative Services support sophisticated traffic management through a traffic section in the service specification. This allows you to route traffic to multiple revisions with specific identifiers and percentage-based distribution.

Key Features​

  • Tags: Assign custom tags to specific revisions for accessing them via unique subdomains
  • Percentage-based traffic splitting: Distribute traffic across multiple revisions
  • Revision targeting: Route traffic to specific revisions by name

Traffic Splitting Example​

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: whoami
  namespace: default
spec:
  template:
    metadata:
      name: whoami-v2
    spec:
      containers:
        - image: traefik/whoami:latest
          env:
            - name: WHOAMI_NAME
              value: "whoami-v2"
  traffic:
    - tag: v1
      revisionName: whoami-00001
      percent: 50
    - tag: v2
      revisionName: whoami-00002
      percent: 50

In this example:

  • 50% of traffic routes to the whoami-00001 revision (tagged as v1)
  • 50% of traffic routes to the whoami-00002 revision (tagged as v2)
  • Each tagged revision is accessible via its own subdomain

Access Patterns​

When using Knative with Traefik, services are accessible through the following URL patterns:

  • Default route: [service].[namespace].[domain-suffix]
    • Routes traffic according to the percentage-based configuration
  • Tagged revision: [tag]-[service].[namespace].[domain-suffix]
    • Direct access to a specific tagged revision

The domain suffix is configured during the Traefik Hub API Gateway installation and is set in the Knative domain configuration.

Example URLs​

If your domain suffix is example.com and you have the service configuration above:

  • Default URL: whoami.default.example.com (50/50 split between v1 and v2)
  • V1 tagged URL: v1-whoami.default.example.com (always routes to v1)
  • V2 tagged URL: v2-whoami.default.example.com (always routes to v2)

Use Cases​

Canary Deployments​

Use percentage-based traffic splitting to gradually roll out new versions:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - image: my-app:v2
  traffic:
    - revisionName: my-app-00001
      percent: 90
    - revisionName: my-app-00002
      percent: 10

A/B Testing​

Use tags to create stable URLs for different versions while controlling the default traffic split:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - image: my-app:variant-b
  traffic:
    - tag: variant-a
      revisionName: my-app-00001
      percent: 50
    - tag: variant-b
      revisionName: my-app-00002
      percent: 50

Blue/Green Deployments​

Deploy a new version without routing traffic to it, then switch traffic instantly:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - image: my-app:green
  traffic:
    - tag: blue
      revisionName: my-app-00001
      percent: 100
    - tag: green
      revisionName: my-app-00002
      percent: 0

To switch traffic, update the percentages to blue: 0 and green: 100.

TLS Configuration​

For HTTPS/TLS configuration of your Knative services, refer to the Knative documentation on external domain TLS.

Traefik Hub API Gateway integrates with Knative's TLS configuration and supports automatic certificate management through certificate resolvers like cert-manager.

Automatic Service Discovery​

The Knative provider automatically:

  • Discovers new Knative Services and Ingresses
  • Updates routing configuration when services are modified
  • Removes routes when services are deleted
  • Handles scaling events transparently

No manual intervention is required to keep Traefik's routing configuration synchronized with your Knative workloads.

Related Content​