Mastering Traffic Management in Knative: Blue‑Green Deployments, Autoscaling, and Monitoring

Knative Overview

Knative is an open‑source Kubernetes‑based serverless framework that provides request‑driven autoscaling, zero‑scale capability, multi‑revision traffic routing, blue‑green (gray) releases, function deployment and event‑driven execution.

Traffic Management and Blue‑Green Release

Knative replaces the multiple Service, Deployment, HPA and Ingress resources required in vanilla Kubernetes with a single Knative Service object. Traffic percentages are assigned to revisions; updating the percentages enables gradual rollouts and instant rollbacks.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  traffic:
  - percent: 0
    revisionName: example-service-1
    tag: staging
  - percent: 40
    revisionName: example-service-2
  - percent: 60
    revisionName: example-service-3

Tagging a revision creates a dedicated URL (e.g., staging-example-service.default.example.com) for isolated verification before exposing traffic.

Revision Garbage‑Collection Policy

Each configuration change creates a new Revision. A config-gc ConfigMap controls automatic cleanup. retain-since-create-time: duration after creation to keep a revision (default “48h”). retain-since-last-active-time: duration after last active reference (default “15h”). min-non-active-revisions: minimum number of inactive revisions to retain (default 20). max-non-active-revisions: maximum number of inactive revisions (default 1000).

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-gc
  namespace: knative-serving
  labels:
    app.kubernetes.io/name: knative-serving
    app.kubernetes.io/component: controller
    app.kubernetes.io/version: "1.8.2"
data:
  retain-since-create-time: "48h"
  retain-since-last-active-time: "15h"
  min-non-active-revisions: "20"
  max-non-active-revisions: "1000"

Set a field to "disabled" or a lower numeric value to change the behavior.

Multi‑Gateway Support

Ingress gateway class is selected via the config-network ConfigMap. Example configurations:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
data:
  ingress.class: "alb.ingress.networking.knative.dev"

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
data:
  ingress.class: "mse.ingress.networking.knative.dev"

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
data:
  ingress.class: "istio.ingress.networking.knative.dev"

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
data:
  ingress.class: "kourier.ingress.networking.knative.dev"

Multi‑Protocol Support

Knative services can expose HTTP, gRPC and WebSocket. For a gRPC service set the container port name to h2c:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-grpc
spec:
  template:
    spec:
      containers:
      - image: docker.io/moul/grpcbin
        env:
        - name: TARGET
          value: "Knative"
        ports:
        - containerPort: 9000
          name: h2c
          protocol: TCP

To expose both HTTP and gRPC on the same service, define two ports and add the annotation knative.alibabacloud.com/grpc: grpcbin.GRPCBin:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-grpc
  annotations:
    knative.alibabacloud.com/grpc: grpcbin.GRPCBin
spec:
  template:
    spec:
      containers:
      - image: docker.io/moul/grpcbin
        ports:
        - containerPort: 80
          name: http1
          protocol: TCP
        - containerPort: 9000
          name: h2c
          protocol: TCP

Custom Domain and Path Configuration

Use a DomainMapping resource to assign a custom domain to a specific Knative Service:

apiVersion: serving.knative.dev/v1alpha1
kind: DomainMapping
metadata:
  name: my.custom.domain
  namespace: my-namespace
spec:
  ref:
    name: my-service
    kind: Service
    apiVersion: serving.knative.dev/v1
  tls:
    secretName: my-tls-secret

Global domain suffixes are set in the config-domain ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-domain
  namespace: knative-serving
data:
  mydomain.com: ""

Custom routing paths can be defined with the annotation knative.aliyun.com/serving-ingress: cafe.mydomain.com/coffee on the Service.

Traffic‑Based Autoscaling (KPA)

Knative Pod Autoscaler (KPA) scales pods based on average request concurrency. The default maximum concurrency per pod is 100. The target utilization percentage (e.g., 70%) can be configured. Required pod count is calculated as:

pods = total_concurrent_requests / (max_concurrency_per_pod * target_utilization)

Example: max concurrency = 10, target = 0.7, 100 concurrent requests → ≈15 pods. Scaling to zero occurs when traffic drops to zero.

Observability

The sidecar queue-proxy exposes metrics on port 9091 and management ports on 8012 (HTTP entry), 8013 (HTTP/2 for gRPC), 8022 (health checks), 9090 (autoscaler metrics). Prometheus scrapes these metrics to provide request count, latency, concurrency, etc.

Grafana dashboards are available in the Knative monitoring repository:

https://github.com/knative-extensions/monitoring/tree/main/grafana