What Are the Main Components of Knative: Serving and Eventing?

Knative has two main components: Serving and Eventing. Serving handles request-driven workloads — it serves and scales HTTP/2, gRPC, and MCP traffic on demand. Eventing handles asynchronous workloads — it routes and processes events the same way Serving handles HTTP. They are designed to work together to automate and manage tasks and applications on Kubernetes, and you need both only if your workloads include both request-driven and event-driven paths.

Serving: request-driven workloads

Serving is the component you use when something calls your application and expects a response.

• HTTP-first. It serves and scales HTTP/2, gRPC, and MCP traffic.
• Scale to match demand. Knative optimizes your deployment behind the scenes so capacity follows actual traffic rather than a fixed guess.
• Functions as a pattern. Functions are described as application template patterns you can version and update, which is what makes a function-as-a-service style workload practical on top of Serving.

A useful way to think about it: when a request comes in, Serving can scale a workload up and down on demand. That is the mechanism Kelsey Hightower points to when describing how you would build a function-as-a-service on top of Knative.

Eventing: asynchronous workloads

Eventing is the component you use when something happens and your application needs to react, without a caller waiting on the response.

• Route and handle asynchronous events just like HTTP. The mental model carries over from Serving, which keeps the learning curve short.
• Event Integrations. You can extract events from existing services or define your own.
• Kubernetes-integrated Trigger handlers from the event broker, so event routing is expressed in Kubernetes-native terms.
• Pluggable. Eventing is built to be integrated and extended rather than used as a closed system.

How the two components work together

Serving and Eventing are not competing choices; they cover two different traffic shapes and share the same automation goal.

The practical consequence: if your application only answers requests, Serving alone covers it. If your application only reacts to events, Eventing alone covers it. If a single system does both — for example, an HTTP API that also consumes events from an existing service — you use both, and the value comes from them being managed under one Kubernetes-native model instead of two separate stacks.

What this means for your decision

Knative is described as the easiest way to build and run serverless workloads on Kubernetes, built by the community for modern cloud-native teams, and it is a Cloud Native Computing Foundation graduated project. The two-component split is the reason it can cover both request and event workloads without forcing you to pick one style of application.

Concretely, ask two questions about your workload:

1. Does something call it and wait? If yes, you need Serving.
2. Does something happen and it must react? If yes, you need Eventing.

If both answers are yes, the two components are meant to be used together — that combination is what the project means by automating and managing tasks and applications on Kubernetes. To evaluate it against your own setup, the documented starting points are trying the tutorial or installing Knative on your cluster.