Knative Serving sub-components
Currently, the Knative Serving consists of the following sub-components:
$ kubectl get deployment --namespace knative-serving NAME READY UP-TO-DATE AVAILABLE AGE activator 1/1 1 1 159d autoscaler 1/1 1 1 159d controller 1/1 1 1 159d webhook 1/1 1 1 159d
When a service is scaled to zero, its request are routed to the activator
which waits for a Pod to become ready (wake up) and proxies the traffic while
editing the underlying
Endpoints to route the traffic directly to the Pod(s).
Knative Pod Autoscaler (KPA) is described here.
The main component responsible for watching API objects for Knative CRDs (KService, Configuration, Route, Revision) and manage their lifecycle, create the underlying Kubernetes resources and garbage-collect old objects.
The webhook application is a Kubernetes Admission Webhook. It acts both as a “validating admission controller” (read-only) and “mutating admission controller” (modifying).
The webhook will receives these API objects upon creation/edits:
- Knative API types (KService, Route, Revision etc.)
- Knative ConfigMaps (that are used to tune Knative itself)
Then, it is responsible for:
- defaulting: modify the object and set default values for the unspecified fields
- validation: make sure invalid fields/values are not set, and config is valid