How Knative Handles Cold‑Start Traffic: From Activator to Pod

1 Introduction – Starting from Auto Scaling

When a service receives traffic, a Serverless platform can automatically scale from 0 to N instances and scale back to 0 when idle. This auto‑scaling capability is the crown of Serverless. Unlike the standard Kubernetes HPA, which can only scale from 1 to N, Serverless must support scaling from 0 to 1, which requires an additional mechanism to hold incoming requests during cold‑start.

The cold‑start process is the key to fast service startup and is a primary optimization target for Serverless platforms such as Knative.

2 Simple but Outdated Traffic Mechanism

Knative creates a Route, Configuration, and Revision when a Service is defined. The Revision creates a Deployment that serves traffic according to the Route configuration.

In older versions, when the replica count is 0, the Istio VirtualService routes traffic to the Activator component, which holds the request while the Autoscaler creates pods. Once pods exist, the VirtualService routes directly to the pods.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: route-f8c50d56-3f47-11e9-9a9a-08002715c9e6
spec:
  gateways:
  - knative-ingress-gateway
  - mesh
  hosts:
  - helloworld-go.default.example.com
  - helloworld-go.default.svc.cluster.local
  http:
  - appendHeaders:
      route:
      - destination:
          host: Activator-Service.knative-serving.svc.cluster.local
          port:
            number: 80
        weight: 100

When the service scales up, the VirtualService destination is updated to point to the actual service pods.

3 Complex but Superior New Traffic Mechanism

In newer Knative releases (e.g., 0.9), the traffic path no longer relies on modifying the VirtualService. Instead, the public Service’s Endpoint is updated directly, moving traffic from the Activator to the real pods at the Service/Endpoint layer. This reduces gateway configuration churn and decouples Knative from specific gateway implementations.

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: hello-go
  namespace: faas
spec:
  template:
    spec:
      containers:
      - image: harbor-yx-jd-dev.yx.netease.com/library/helloworld-go:v0.1
        env:
        - name: TARGET
          value: "Go Sample v1"

After creating the service, Knative automatically creates three Services:

hello-go – an ExternalName Service that maps the Knative Service name to the gateway.

hello-go‑fpmln – a headless Service without a selector; its Endpoints are manually created.

hello-go‑fpmln‑m9mmg and hello-go‑fpmln‑metrics – regular Services that select the pods of the corresponding Revision.

When the replica count is 0, the public Service’s Endpoint points to the Activator pod. After the first request triggers a scale‑up, the Endpoint is updated to the newly created pod IPs.

$ kubectl -n faas get ep
NAME                     ENDPOINTS
hello-go-fpmln           172.31.16.81:8012
hello-go-fpmln-m9mmg     172.31.16.121:8012,172.31.16.121:8022
hello-go-fpmln-metrics   172.31.16.121:9090,172.31.16.121:9091

The ServerlessService (sks) CRD initially operates in Proxy mode, routing through the Activator. After the service is up, it switches to Serve mode, sending traffic directly to the pods.

$ kubectl -n faas get sks
NAME               MODE   SERVICENAME   PRIVATESERVICENAME   READY   REASON
hello-go-fpmln    Proxy  hello-go-fpmln  hello-go-fpmln-m9mmg  True

# After scaling up
hello-go-fpmln    Serve  hello-go-fpmln  hello-go-fpmln-m9mmg  True

Thus, the traffic flow is:

Cold‑start (replicas = 0): Gateway → public Service → Activator After scaling (replicas > 0):

Gateway → public Service → Pod

4 Summary

Knative combines Kubernetes, Service Mesh, and Serverless concepts, resulting in a powerful but complex system. The stability of network traffic is crucial for production‑grade Serverless services. Recent changes that move traffic handling to the native Service/Endpoint layer improve performance, reduce gateway load, and make Knative more adaptable to different gateway implementations.