How does Knative Serving's Activator intercept requests to scaled down revisions?
As described here, Knative's Activator receives and buffers requests to inactive revisions.
How is this routing implemented? All I see in the Namespace of my application is a VirtualService routing requests to the revisions, so I don't see how traffic coming into the mesh is redirected to the Activator.
Knative serving version: 0.9.0
Similar Questions
1 Answer
Knative has a new concept (CRD) known as the Serverless service which is created for each Knative Service.
The serverless service creates two Kubernetes Services:
- The Private service which targets your application pods. It is needed to discover the Pod IPs.
- The Public service is being targeted by the ingress gateway and according to the Mode it is in (more about it later) it will either point to the same endpoints as the first service or to the endpoints of the activator service.
Serverless Service Modes
Serverless Services can be in one of the following modes:
- Serve
- Proxy
Serve Mode
The serverless service is in Serve mode as long as there are pod instances of your application running. As such your Public service is configured with the endpoints from your private service, meaning that requests forwarded by the ingress gateway reach your application as shown in the diagram below:
- hello-go-pb - is the public service.
- hello-go-pr - is the private service.
Proxy Mode
When the instances of your application are scaled down by the autoscaler, the serverless service controller updates the public service to be configured with the IPs discovered by the Activator Service. Which triggers autoscaling buffers the request until one service is up and running and forwards the request. Proxy mode can be seen in the diagram below:
As a summary, the Serverless controller sets the endpoints of the public service by alternating between the endpoints of the Private Service or if it's scaled down to zero to the endpoints of the Activator Service.