Knative: Serverless Containers and Event Routing on Kubernetes

Knative is an open-source layer that sits on top of Kubernetes and gives it two things a plain cluster does not have: a request-driven, scale-to-zero runtime for HTTP containers (Knative Serving), and a declarative event-routing layer that delivers CloudEvents to those containers (Knative Eventing). A third part, Knative Functions, builds and deploys small functions as Knative services. Google created Knative in 2018, with early contributions from IBM, Red Hat, VMware and SAP; it reached version 1.0 in 2021, joined the CNCF as an incubating project in 2022, and CNCF announced its graduation on October 8, 2025. This brief explains Knative from the problem it solves to installing, configuring, securing and operating it, and is candid about where the documentation lags the code.

CNCF daily · Sprint 5, post 6 of 14 · Scheduling & Orchestration

At a glance

Category	Orchestration & Management, subcategory Scheduling & Orchestration (CNCF Landscape)
CNCF status	Graduated. CNCF’s announcement is dated October 8, 2025; the Landscape file records graduation as 11 September 2025, so the two sources differ on the date
Written in	Go
License	Apache-2.0
Components	Serving, Eventing, Functions (func), Client (kn), Operator, plus extensions such as the Apache Kafka broker and source
Current release	v1.24.0 (26 October 2026); v1.23 and v1.24 are the supported lines. Releases arrive roughly every quarter
Kubernetes required	v1.24 needs Kubernetes 1.35 or later; v1.23 needs 1.34
Networking layers	Kourier (lightweight, Envoy-based), Contour, Istio, Gateway API (beta)
Install routes	Quickstart (local), YAML manifests, Knative Operator (manifests, Helm or CLI plugin)
Support window	About six months per release (v1.24 supported until about May 2027, per endoflife.date)

The problem Knative solves

Two jobs look simple and turn out to be repetitive on Kubernetes.

Running HTTP services that sit idle most of the time. A Deployment keeps its pods running whether or not anyone calls it, and the Horizontal Pod Autoscaler reacts to CPU, not to requests, and cannot go to zero. For services that are called in bursts, you either pay for idle pods or hand-build scaling, routing, canary releases and TLS yourself.

Wiring producers to consumers. Event-driven designs need ingestion, filtering, retry, dead-lettering and delivery. Putting that inside every application ties each one to a particular broker and library.

Knative’s answer is to make both a Kubernetes API. You describe a service or a subscription in YAML; controllers create the Deployments, routes, autoscalers, brokers and subscriptions. Events travel as CloudEvents over HTTP, so a consumer is just a web server that receives a POST.

Key concepts

Term	Meaning
Knative Service (ksvc)	The top-level Serving resource. It owns a Route and a Configuration and creates a new Revision on every change to its template.
Revision	An immutable snapshot of code and configuration. Each Revision scales on its own.
Route	Maps a URL to one or more Revisions, with percentages and named tags.
KPA / HPA	The Knative Pod Autoscaler (request-based, can scale to zero) and the Kubernetes Horizontal Pod Autoscaler (CPU-based, cannot scale to zero). KPA is the default.
Concurrency	Requests in flight per pod. Knative scales on concurrency or requests per second, not CPU.
Source	A resource that turns something external (a Kafka topic, a timer, the Kubernetes API) into CloudEvents.
Sink	Any addressable destination: a Knative Service, a Kubernetes Service, a Broker, a Channel or a URI.
Broker and Trigger	A Broker is an event mailbox. A Trigger subscribes a consumer to it, with a filter on CloudEvent attributes.
Channel and Subscription	A lower-level fan-out pair: events sent to a Channel are delivered to every Subscription.
Delivery spec	Retry count, backoff policy and delay, and a dead letter sink for events that cannot be delivered.
Eventing extensions	The Apache Kafka Broker, KafkaSource, KafkaChannel and RabbitMQ and other implementations, maintained next to the core.

Architecture

Serving (top) handles request routing and scaling; Eventing (bottom) routes events into Serving workloads. Blue is a client or source, dark grey is the networking layer, purple is a Knative component and green is a workload. Open the zoomable diagram, or download it as SVG or PNG.

Component	Responsibility
Controller	Watches Knative resources, creates the Deployments, Services and autoscaler objects behind them and updates their status.
Webhooks	Validate and default Knative resources when they are created or changed.
Networking layer	The ingress gateway (Kourier, Contour, Istio or Gateway API). A controller translates Knative’s internal KIngress resource into gateway configuration.
Activator	In the data path when a Revision is at zero or short of capacity. It queues requests, tells the autoscaler to start pods, and forwards the requests once pods are ready. It also works as a request buffer for bursts.
Autoscaler	Collects metrics from the activator and the queue-proxies, decides how many pods each Revision needs and updates its Deployment.
Queue-proxy	A sidecar in every workload pod. It reports metrics and enforces the concurrency limit before requests reach your container.
Eventing controllers and data plane	Reconcile Brokers, Triggers, Channels, Subscriptions and Sources, and carry events to subscribers.
Kafka broker and source	Native Kafka implementations that reduce network hops. The Kafka Broker supports a shared or per-namespace data plane and ordered delivery by CloudEvents partitioning.

Design principle. Keep the platform in Kubernetes objects and keep the application in plain containers. A workload only has to speak HTTP on a port; scaling, revisions, routing, retries and dead-lettering are configuration that the platform owns.

One request and one event

A cold request on the left, an event on the right. Open the zoomable diagram, or download it as SVG or PNG.

1. A client sends an HTTP request. The gateway routes it to the activator, because the Revision is at zero.
2. The activator counts and buffers the request and reports it to the autoscaler.
3. The autoscaler raises the Deployment’s replicas and switches the Revision from proxy mode to serve mode.
4. When the new pod is ready, the activator forwards the buffered request; later requests go straight to pods through the gateway.
5. For events, a KafkaSource reads a topic and posts CloudEvents to a Broker; a Trigger with a filter delivers matching events to a Knative Service.
6. If delivery fails, the delivery spec retries with backoff and finally sends the event to the dead letter sink.

Knative Serving architecture · Request flow

Install Knative

Route	Use it for
Quickstart plugin	A local kind or minikube cluster, for learning
YAML manifests	Production, especially with GitOps tools such as Flux or Argo CD; the most granular route
Knative Operator	Production, with KnativeServing and KnativeEventing custom resources; install by manifest, Helm or the kn operator CLI plugin. Since v1.22 one operator can also deploy to another cluster

Sizing in the docs: one node needs at least 6 CPUs, 6 GB of memory and 30 GB of disk; multiple nodes need 2 CPUs, 4 GB and 20 GB each. Check the Kubernetes minimum for your release first (1.34 for v1.23, 1.35 for v1.24).

Serving with YAML and Kourier

Set KN to the release you chose and follow the docs for that release:

KN=knative-v1.24.0
kubectl apply -f https://github.com/knative/serving/releases/download/$KN/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/$KN/serving-core.yaml
kubectl apply -f https://github.com/knative-extensions/net-kourier/releases/download/$KN/kourier.yaml
kubectl patch configmap/config-network -n knative-serving --type merge \
  -p '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'
kubectl -n kourier-system get service kourier   # external address for DNS

Older guides use the key ingress.class; the current install page uses ingress-class. Use the one in the docs for your version. The serving-default-domain.yaml job sets up a development domain (it needs a LoadBalancer address and does not work on IPv6-only clusters).

Eventing

kubectl apply -f https://github.com/knative/eventing/releases/download/$KN/eventing-crds.yaml
kubectl apply -f https://github.com/knative/eventing/releases/download/$KN/eventing-core.yaml
# Optional: Apache Kafka broker and source from knative-extensions/eventing-kafka-broker

I have not run these commands; asset names follow the install pages, so confirm them on the release you pick. For Kafka, install the Strimzi or another Kafka cluster first (see the Strimzi and Apache Kafka briefs).

Using Knative

Examples use neutral sensor data. They follow the official docs and are untested here.

A Knative Service with autoscaling

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: reading-handler
  namespace: demo
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
        autoscaling.knative.dev/max-scale: "20"
        autoscaling.knative.dev/metric: concurrency
        autoscaling.knative.dev/target: "20"
        autoscaling.knative.dev/scale-down-delay: "2m"
    spec:
      containerConcurrency: 0        # 0 = no hard limit, target is a soft limit
      containers:
        - image: registry.example.com/reading-handler:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests: { cpu: 100m, memory: 128Mi }

Each change to spec.template creates a new Revision. kn service create and kn service update do the same from the command line, including --scale-min, --scale-max and --scale-target.

Split traffic between Revisions

spec:
  traffic:
    - revisionName: reading-handler-00001
      percent: 90
    - revisionName: reading-handler-00002
      percent: 10
      tag: candidate        # also reachable at its own tagged URL
    - latestRevision: true
      percent: 0
      tag: latest

kn service update reading-handler --traffic reading-handler-00001=80 --traffic reading-handler-00002=20 is the CLI form. A tag with percent: 0 gives a preview URL without live traffic.

Route Kafka messages to the service

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: demo
  annotations:
    eventing.knative.dev/broker.class: Kafka
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: kafka-broker-config
    namespace: knative-eventing
  delivery:
    retry: 5
    backoffPolicy: exponential
    backoffDelay: PT1S
    deadLetterSink:
      ref: { apiVersion: serving.knative.dev/v1, kind: Service, name: dead-letters }
---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: handle-excursions
  namespace: demo
spec:
  broker: default
  filter:
    attributes:
      type: org.example.reading.excursion
  subscriber:
    ref: { apiVersion: serving.knative.dev/v1, kind: Service, name: reading-handler }
---
apiVersion: sources.knative.dev/v1
kind: KafkaSource
metadata:
  name: readings-source
  namespace: demo
spec:
  consumerGroup: knative-readings
  bootstrapServers: ["my-cluster-kafka-bootstrap.kafka:9092"]
  topics: ["readings"]
  sink:
    ref: { apiVersion: eventing.knative.dev/v1, kind: Broker, name: default }

The KafkaSource turns each Kafka message into a CloudEvent and waits for a successful response before delivering the next message in the same partition, so per-partition order is preserved. Whether a message arrives with the right type attribute depends on how it was produced; set the CloudEvents headers in the producer, or add a transformation step.

Send an event by hand

curl -X POST "$BROKER_URL" \
  -H "Content-Type: application/json" \
  -H "Ce-Id: 1" -H "Ce-Source: test" \
  -H "Ce-Type: org.example.reading.excursion" -H "Ce-Specversion: 1.0" \
  -d '{"device_id":"d001","temp_c":9.4}'

kubectl get broker default -n demo shows the broker URL in its status.

Advanced filters

spec.filters accepts exact, prefix, suffix, cesql, and combinations with all, any and not. The docs mark this field experimental, and if both filter and filters are set, filters wins.

Features

Feature	What it gives you
Scale to zero and back	Idle Revisions cost no pods; the activator buffers the first requests
Request-based autoscaling	Concurrency or requests-per-second targets, stable and panic windows, burst capacity
Revisions and traffic splitting	Immutable snapshots, canary, blue-green, tagged preview URLs
Pluggable networking	Kourier, Contour, Istio, Gateway API
Brokers and Triggers	Attribute and expression filters over CloudEvents
Channels and Subscriptions	Fan-out to several subscribers
Delivery guarantees	Retry, exponential or linear backoff, dead letter sink; support varies by Broker class
Sources	KafkaSource (stable), Ceph, PingSource, ApiServerSource, SinkBinding, ContainerSource and third-party sources such as Debezium
Kafka-native broker	Control plane HA, horizontally scalable data plane, ordered delivery
Functions	kn func builds and deploys functions as Knative services; since v1.21 also as plain Deployments, and v1.22 added a KEDA deployer
Operator	Declarative install and upgrade, including multi-cluster since v1.22
Gateway-level TLS and certificates	cert-manager integration for Serving and Eventing

Autoscaler settings

Defaults from config-autoscaler in the knative-serving namespace:

Setting	Default	Meaning
enable-scale-to-zero	true	Global only; works with KPA only
scale-to-zero-grace-period	30s	Upper bound waited so the activator is in the path before the last pod goes
scale-to-zero-pod-retention-period	0s	Minimum time the last pod stays after the decision to scale to zero
stable-window	60s	Averaging window in steady state
panic-window-percentage / panic-threshold-percentage	10 / 200	Faster reaction to spikes
container-concurrency-target-default	100	Soft concurrency target; the target percentage defaults to 70
requests-per-second-target-default	200	Used when the metric is rps
target-burst-capacity	200 (docs example)	Keeps the activator in the path when spare capacity is lower; -1 means always
max-scale-up-rate / max-scale-down-rate	1000 / 2	Limits on pod-count change per evaluation
min-scale / initial-scale	0 / 1	Cluster-wide defaults for scale bounds

The autoscaler evaluates about every two seconds. Per-Revision annotations override most of these; check the autoscaling pages for which keys are global only.

Production reference design

A design suggestion for AWS, not an official reference, and not deployed by me.

Layer	Suggestion
Cluster	Amazon EKS on a Kubernetes version your Knative release supports; spread nodes over three Availability Zones
Ingress	Kourier behind an AWS Network Load Balancer (one fewer moving part than a service mesh), or Gateway API if you already run it
Control plane	Run the controllers, webhooks, activator and autoscaler with more than one replica and a PodDisruptionBudget; the activator is stateless and scales out
Node capacity	Keep headroom or use a node autoscaler such as Karpenter; scale-from-zero is only as fast as a pod can be scheduled
Events	Kafka Broker backed by a managed or self-run Kafka (Amazon MSK or Strimzi); one data plane per tenant namespace if isolation matters
Workloads	Set min-scale: "1" for latency-critical services and keep scale-to-zero for bursty ones
Install	Operator or YAML under GitOps; pin versions and upgrade one minor release at a time
Observability	Scrape the Knative metrics and use the dashboards in the docs; alert on revision readiness and delivery failures

Security

Control	Detail
Transport encryption (Eventing)	transport-encryption in config-features exposes HTTPS broker and channel endpoints; listed as beta and off by default when I read the docs. The v1.22 release notes mention a default minimum TLS version of 1.3
Sender identity (Eventing)	authentication-oidc makes addressables announce an OIDC audience and sources attach a token from a per-source ServiceAccount; listed as alpha. Enable TLS with it so tokens do not travel in clear text
Authorization (Eventing)	default-authorization-mode and the EventPolicy resource (v1alpha1) restrict which identities may send to a broker, channel or sink
Serving TLS	Certificates for external and optionally internal traffic, typically via cert-manager; authentication for Serving is done at the gateway
Transport credentials	Kafka and RabbitMQ brokers use TLS and per-namespace credentials; set matching access control on the message system itself
Pod defaults	v1.21 added secure-pod-defaults with an AllowRootBounded mode, disabled by default; the docs publish a threat model
Cross-namespace links	cross-namespace-event-links (alpha) lets triggers and subscriptions refer to brokers in other namespaces; leave it off unless you need it

Eventing feature maturity moves between releases, so read the config-features page for your version. By default, in-cluster event delivery is unauthenticated, so treat brokers as open inside the cluster until you enable identity and policy.

Monitoring and day-2 operations

Task	How
Health	kubectl get ksvc,revision,route,broker,trigger -A; the Ready condition and reason show most problems
Debug scaling	Check the autoscaler logs, the revision’s pod count and kn revision list; compare concurrency with the target
Upgrade	One minor version at a time; apply CRDs, then core, then networking layer and extensions; read the release notes for removals
Capacity	Watch node headroom and the activator’s capacity (activator-capacity)
Clean up	Prune old Revisions through Service garbage collection settings

Symptom	First checks
First request slow or timing out	Cold start: image pull, readiness probe, node scheduling; consider min-scale, a smaller image or scale-to-zero-pod-retention-period
Service stuck not ready	Progress deadline in config-deployment (raise it if nodes must be created first), image digest resolution, probes
Events not delivered	Trigger filter and CloudEvents attributes, subscriber readiness, delivery spec and the dead letter sink
Requests dropped when scaling to zero	scale-to-zero-grace-period, especially behind a mesh
Scaling too eager or slow	Metric, target, windows and burst capacity; remember only one metric applies per Revision

Usage cases

• Bursty HTTP services. APIs, webhooks and web back-ends that are idle for long stretches and need to scale quickly.
• Event handlers. Small consumers of Kafka messages, timers or Kubernetes events that need retry and dead-letter handling without custom code.
• Safe rollouts. Canary and blue-green releases through Revisions and tagged URLs.
• Functions. Building and deploying small stateless functions with kn func.
• Model and AI serving. The project documents request-based scaling and traffic splitting for inference services, including GPU-backed ones; check how GPU scheduling and cold starts fit your case.
• Cold-chain sprint project. The Sprint 5 final project runs event-driven excursion and geofence handlers as Knative services that wake on an event and scale back to zero.

Operational considerations

• Cold starts are real. A pod must be scheduled, pulled and made ready. The first request waits in the activator. Use min-scale where latency matters.
• Scale to zero is KPA-only and global. The HPA class cannot scale to zero and the switch is a cluster-wide setting.
• Extra hops. Every pod has a queue-proxy sidecar and requests may pass the activator; budget a little CPU, memory and latency for them.
• Choose the networking layer deliberately. Kourier is the lightest; Istio or Gateway API make sense if you already run them.
• Kubernetes version pressure. Recent releases raise the minimum Kubernetes version quickly (1.34, then 1.35), so plan cluster upgrades alongside Knative upgrades.
• Eventing maturity varies. Some Eventing features are alpha or beta; Kafka Broker and KafkaSource are the safer paths for production.
• Documentation age. Several pages carry page ages of hundreds or thousands of days and some examples still use older key names; trust the release notes and the CRDs for your version.
• Not a Lambda clone. Knative runs containers with HTTP and CloudEvents contracts on your cluster; you still operate the cluster.

Adoption

CNCF’s graduation announcement names end users: Scaleway uses Knative for its Serverless Functions and Containers products; Alibaba Cloud offers serverless containers on Knative; Y Meadows runs hundreds of Knative services for its AI process-automation platform; Gojek has used Knative since 2020 and reports more than 100,000 requests per second at peak. The announcement also says the project formalised its governance under one Steering Committee by December 2024 and completed technical reviews and security audits.

Alternatives

Solution	Model	Best suited to
KEDA	Event-driven pod autoscaler for existing Deployments	Scaling any workload on queue depth or metrics, without Knative’s routing and revisions
Argo Events	Event sensors that trigger workflows and resources	Event-driven automation on the Argo stack
OpenFaaS	Function platform for Kubernetes	Functions-first teams; compare feature tiers and licensing
AWS Lambda	Managed functions	Teams that want no cluster to run; different packaging and limits
Plain Deployment with HPA	Standard Kubernetes	Always-on services that do not need scale to zero
Cloud-managed Knative (for example Alibaba Cloud’s offering)	Managed Serving	Avoiding the operation of the control plane

Strengths and limitations

Strengths	Limitations
Graduated CNCF project with a vendor-neutral Steering Committee	Cold starts and extra hops on the request path
Scale to zero, revisions and traffic splitting built in	Quickly rising Kubernetes version minimums
CloudEvents-based Eventing with retry and dead-lettering	Several Eventing security features still alpha or beta
Works with any container that speaks HTTP	Large surface: several components, networking layers and extensions to choose and operate
Active quarterly releases and a Kubernetes-native API	Documentation unevenly maintained

Project status and roadmap

Knative is a CNCF graduated project, with v1.24.0 released on 26 October 2026 and v1.23 still supported. Recent releases added multi-cluster deployment through the Operator and net-gateway-api (v1.22), a default minimum TLS version of 1.3 in Eventing (v1.22), secure pod defaults (v1.21), ephemeral volume support and Kourier IPv6 improvements (v1.23), and the raw Functions deployer (v1.21). A press report on the graduation mentions a planned RequestReply Eventing resource to bridge synchronous and asynchronous workloads; I treat it as a plan, not a commitment, and did not verify it against the project’s roadmap.

Recommendation

Adopt Knative Serving where you have bursty HTTP services on Kubernetes and want scale to zero, revisions and traffic splitting without writing the machinery yourself, with the cold-start and Kubernetes-version trade-offs understood. Trial Eventing with the Kafka broker for event handlers, and enable transport encryption, sender identity and policies before exposing it to more than one team. If you only need event-based scaling of existing workloads, evaluate KEDA first. Start with the Quickstart plugin on a local cluster, then install Serving with Kourier, deploy one service, split traffic, and add one Broker and Trigger.

References: Knative documentation · Serving architecture · Request flow · Autoscaler types · Configuring scale to zero · Traffic management · Install overview · Install Serving with YAML · Knative Operator CLI plugin · Eventing overview · Kafka Broker · Kafka Source · Handling delivery failure · Eventing features · Sender identity · Threat model · v1.23 release · v1.22 release · CNCF graduation announcement · Release support dates