Uncategorised

Knative Tutorials – Chapter – 10 – Knative Tutorials: servicing workflow between Components

December 1, 2023 Leave a Comment
  1. Request Initiation:
    • A user sends a request to an application hosted on Knative.
    • This request first hits the Istio Ingress Gateway, which is the entry point for external traffic into the Kubernetes cluster.
  2. VirtualService Routing:
    • The Istio Ingress Gateway uses Istio VirtualService to determine where to route the request. Knative sets up these VirtualServices when a service is created or updated.
    • Typically, the VirtualService will point to the Knative Activator when the application is scaled to zero or during scaling up from zero.
  3. Activator:
    • The Activator is responsible for starting up instances of the application (Pods) when there are none running. It plays a crucial role in scale-to-zero functionality.
    • If an application is scaled to zero (no active pods), the Activator receives the incoming request, triggers the Kubernetes deployment to start a new pod, and then buffers incoming requests until the pod is ready to handle them.
    • Once the pod is running and ready, the Activator forwards the buffered requests to the pod.
  4. Autoscaler:
    • The Autoscaler component in Knative observes traffic load and scales the application pods up or down based on the configuration (like concurrency-based metrics) and actual traffic.
    • It receives metrics about ongoing traffic and makes decisions on when to scale. The Activator also plays a part in this by sending metrics to the Autoscaler when it’s buffering requests for scaled-to-zero applications.
  5. Knative Service and Revisions:
    • In Knative, when you create a Service (not to be confused with Kubernetes Service), it represents a specific configuration of your application.
    • Each time you modify the Service, Knative creates a new Revision. Each Revision is a snapshot of the code and configurations for a particular version of the service.
    • The actual running code is encapsulated in a Kubernetes deployment associated with that Revision.
  6. Knative Route:
    • The Route is responsible for determining which Revision of a Service receives traffic. You can set up the Route to split traffic between multiple Revisions for blue-green deployments, canary releases, etc.
    • Combined with VirtualService, it ensures the right revisions of your application are being routed traffic.
  7. Request Completion:
    • After the application processes the request, the response travels back through the same path: from the pod to (possibly) the Activator, and then out through the Istio Ingress Gateway to the user.
Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x