This first post of building Knative application on IBM Cloud series mainly focuses on Knative overview.
Knative is a Kubernetes-based platform to deploy, manage serverless workloads. Its’ primary goal is to design a portable solution for developers to benefit serverless architecture like event-driven, auto-scaling, pay as you go while avoid vendor lock-in.
Knative builds on top of Kubernetes and Istio. It utilizes Istio for request routing, request split/fractional traffic etc. Below diagram explains Knative different personas:
Knative has two key components: Serving and Eventing.
Serving component is responsible for running application, providing service, request driven computing, auto scale up/scale down(scale to zero), traffic routing etc. Serving component has a couple of Kubernetes CRDs like Service, Route, Configuration, Revision.
Service (note this is Knative Service not Kubernetes Service) represents your application, it manages workload lifecyle and controls other objects like Route,Configuration creation.
Route is responsible for routing traffic to appropriate revision.
Configuration is expected state of your application, whenever there is configuration change it creates new revision.
Revision is snapshot of code and configuration.
Eventing component manages and delivers events. Knative Eventing component has Broker, Trigger, Channel, Source etc key CRDs.
Broker receives, persists and forwards events. Events are sent to Broker’s ingress, it uses channel(in-memory, Kafka etc) to persist events and use trigger to foward events to appropriate subscribers.
Trigger filters events, represents a desire to subscribe specific events from broker.
Knative now supports kinds of event sources like Kafka, GitHub etc please refer to here for complete list.
