“Serverless” is one of the most misunderstood words in cloud native — and one the KCNA expects you to understand at a conceptual level. Serverless has long been listed among the Cloud Native Architecture topics in the KCNA curriculum, alongside autoscaling and open standards. You won’t deploy a function or write a scaling rule during the exam. You need to recognize what serverless means, what trade-offs it makes, and which CNCF projects bring it to Kubernetes.
This guide teaches serverless at exactly that altitude. We’ll define the term properly, separate Functions as a Service from serverless containers, explain scale-to-zero and its cost (the cold start), and then walk the three CNCF projects that matter most here — Knative, KEDA, and CloudEvents — before finishing with the scenario cues that map a question to an answer. As always, check the current curriculum on the Linux Foundation’s KCNA page for the exact wording of the objectives; the concepts below are stable regardless.
What Serverless Actually Means
There are still servers. Serverless means you do not manage them — and more precisely, it describes a way of running code with these characteristics:
- No server management. You don’t provision, patch, or scale machines or (in most offerings) think about nodes at all.
- Event-driven execution. Code runs in response to something: an HTTP request, a message on a queue, a file upload, a timer.
- Automatic, fine-grained scaling. The platform adds instances as load rises and removes them as it falls, without you configuring replica counts.
- Scale to zero. When there is no work, there are no running instances.
- Pay per use. On a managed platform you are billed for requests and execution time, not for idle capacity. On your own cluster, the equivalent benefit is freed-up capacity.
The CNCF’s serverless working group describes serverless as covering two overlapping models:
| Model | What you provide | What the platform provides | Examples |
|---|---|---|---|
| Functions as a Service (FaaS) | Small, single-purpose functions triggered by events | Runtime, scaling, event wiring | Cloud provider function services; function frameworks on Kubernetes |
| Backend as a Service (BaaS) | Calls to an API | Fully managed building blocks — databases, authentication, object storage, messaging | Managed auth, managed object storage |
FaaS is what most people mean by “serverless”, and it is the part the KCNA focuses on. BaaS matters as vocabulary: a serverless application is typically a set of functions gluing managed backend services together.
Serverless vs Containers vs Serverless Containers
It’s tempting to frame this as serverless versus Kubernetes. In practice they sit on a spectrum of how much the platform does for you.
| Containers on Kubernetes | Serverless containers | Functions (FaaS) | |
|---|---|---|---|
| Unit of deployment | Container image, described by Deployments and Services | Container image, described by one high-level resource | A function (source code or small image) |
| Who manages scaling | You configure replicas and autoscalers | Platform, request-driven | Platform, event-driven |
| Scale to zero | Not by default | Yes | Yes |
| Long-running processes | Yes | Usually request-bound | No — short-lived, often time-limited |
| State | Stateful workloads supported | Stateless | Stateless |
| Control and portability | Highest | High — it is still a container | Lowest on proprietary platforms |
| Operational effort | Highest | Low | Lowest |
Two points the exam likes:
- Serverless functions are stateless and ephemeral. Any state lives in an external service. An instance may be destroyed at any moment, and nothing written to its local disk should be relied on.
- Serverless is not automatically cheaper. It is cost-efficient for spiky, intermittent, or unpredictable workloads. For steady, high-volume traffic, always-on containers are usually cheaper per request. We cover that trade-off from the cost angle in our KCNA cost management and resource efficiency guide.
When Serverless Fits — and When It Doesn’t
Good fits: event processing (resize an image when it’s uploaded), webhooks and lightweight APIs, scheduled tasks, glue code between services, workloads with long idle periods, rapid prototypes.
Poor fits: latency-critical paths that cannot tolerate cold starts, long-running computations, stateful systems like databases, workloads needing specialized hardware or fine-grained control over the runtime, and constant high-throughput services.
Trade-offs to name: cold-start latency, execution time limits, harder local debugging and distributed tracing, and — on proprietary platforms — vendor lock-in, because the triggers and event formats are specific to one provider. That last one is exactly the problem open standards address, which is where the CNCF projects come in.
Scale-to-Zero and the Cold Start
Scale-to-zero is the defining mechanic of serverless, so it’s worth understanding what actually happens.
When a workload has no traffic, the platform removes all its instances. The next request therefore arrives when nothing is running to serve it. The platform must:
- Hold (buffer) the incoming request,
- Start a new instance — schedule a Pod, pull the image if needed, start the container, wait for it to be ready,
- Forward the request.
That delay is the cold start. Subsequent requests hit the already-running instance and are fast (a warm start). Cold start duration depends on image size, runtime start-up time, and whether the image is already cached on the node. Platforms let you trade cost for latency by keeping a minimum number of instances warm.
Why can’t plain Kubernetes do this? The Horizontal Pod Autoscaler scales a workload between a minimum and maximum replica count based on metrics, but in a standard configuration its minimum is 1 — it does not take a workload to zero, and even if it did, nothing would hold the incoming request while a Pod starts. Scale-to-zero needs two extra pieces: something to watch for demand while zero Pods are running, and (for HTTP) something to buffer requests during the cold start. Knative and KEDA each supply these in different ways. For the HPA, VPA, and Cluster Autoscaler fundamentals this builds on, see our KCNA cloud native architecture and observability guide.
Knative: Serverless Containers on Kubernetes
Knative is a CNCF project that adds serverless capabilities to Kubernetes. It’s best described as a platform for serverless containers: you hand it a container image and it handles routing, revisions, and request-driven autoscaling including scale-to-zero. Knative installs as a set of controllers and Custom Resource Definitions — it extends Kubernetes rather than replacing it, the same extension pattern you meet throughout the Kubernetes architecture fundamentals.
Knative has two main components, and telling them apart is the single most useful thing to know.
Knative Serving
Serving runs and scales stateless, request-driven workloads. A developer creates one resource — a Knative Service — and Knative creates the rest:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello
spec:
template:
spec:
containers:
- image: ghcr.io/example/hello:1.0You don’t need to write this for the KCNA; it’s here to show how little there is. Compare it with a Deployment plus a Service plus an Ingress plus an autoscaler in plain Kubernetes.
| Serving resource | Role |
|---|---|
| Service | The top-level object; manages the whole lifecycle of the workload |
| Configuration | The desired state of the workload (image, environment) |
| Revision | An immutable snapshot created every time the Configuration changes |
| Route | Maps a network endpoint to one or more Revisions, with traffic percentages |
Because every change produces an immutable Revision and a Route can split traffic between Revisions by percentage, Knative Serving gives you canary and blue-green rollouts as a built-in feature — the same progressive delivery ideas described in our KCNA application delivery and GitOps guide.
Scaling is driven by requests, not CPU. Knative’s autoscaler watches concurrency or requests per second and adjusts the number of Pods. When traffic stops, it scales the Revision to zero; a component called the activator then receives incoming requests, buffers them, signals the autoscaler to start a Pod, and forwards the request once the Pod is ready.
Knative Eventing
Eventing provides the building blocks for event-driven applications — it routes events from producers to consumers with loose coupling, so neither side needs to know about the other.
| Eventing concept | Role |
|---|---|
| Source | Produces events or brings them in from an external system |
| Broker | An event hub that receives events and holds them for delivery |
| Trigger | A filter subscribed to a Broker: “send events of this type to that service” |
| Sink | The destination that receives events — often a Knative Service |
Events flowing through Knative Eventing use the CloudEvents format, which we’ll get to shortly.
Knative Functions
Knative also offers a functions experience: a developer writes a function, and tooling builds it into a container image and deploys it as a Knative Service. That’s the conceptual bridge — a function on Kubernetes is ultimately a container that a platform builds, runs, and scales for you.
The one-line summary: Serving = run and scale HTTP workloads, including to zero; Eventing = route events between producers and consumers.
KEDA: Event-Driven Autoscaling
KEDA — Kubernetes Event-Driven Autoscaling — is a CNCF graduated project with a narrower job than Knative. It doesn’t change how you deploy applications. It scales the workloads you already have based on external event sources: the length of a message queue, lag on a streaming topic, the number of rows in a database query, a cron schedule, a Prometheus query, and many more.
The key ideas:
- Scalers. KEDA ships a large catalog of scalers, each knowing how to read a metric from a particular system.
- ScaledObject. A custom resource that says “scale this Deployment based on this trigger, between these bounds”. There is also a ScaledJob, which launches Kubernetes Jobs to process events.
- It works with the HPA, not instead of it. KEDA acts as a metrics source for Kubernetes and creates an HPA for your workload. KEDA itself handles the zero-to-one and one-to-zero transitions (activation and deactivation); the HPA handles scaling between one and many.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-worker
spec:
scaleTargetRef:
name: order-worker
minReplicaCount: 0
maxReplicaCount: 20
triggers:
- type: rabbitmq
metadata:
queueName: orders
mode: QueueLength
value: "10"Again, illustration only: the worker Deployment runs zero Pods while the queue is empty, and scales out as messages arrive.
Why does this matter beyond scale-to-zero? Because CPU is often the wrong signal. A queue consumer with 50,000 messages waiting may show modest CPU while falling badly behind. Scaling on the queue length — the actual measure of pending work — is more accurate.
Knative vs KEDA
They are complementary, not competitors, and a KCNA question may ask you to pick the one that fits.
| Knative | KEDA | |
|---|---|---|
| What it is | A serverless platform (Serving + Eventing) | An event-driven autoscaler |
| Scaling signal | HTTP requests and concurrency | External event sources and metrics |
| Changes how you deploy? | Yes — you create Knative Services | No — it scales existing Deployments, StatefulSets, and Jobs |
| Best fit | Request-driven web services and APIs | Queue and stream consumers, background workers, batch |
| Relationship to HPA | Uses its own autoscaler by default | Feeds metrics to the HPA |
| Scale to zero | Yes, with request buffering | Yes, activation based on event presence |
CloudEvents: A Common Language for Events
Every event producer has historically described events differently — different field names, different envelopes, different delivery conventions. Consumers had to write custom handling for each source, and moving between platforms meant rewriting it. That’s lock-in by format.
CloudEvents is a CNCF graduated specification — not a piece of software you run — that defines a common way to describe event data. A CloudEvent has a small set of required context attributes:
| Attribute | Meaning |
|---|---|
id | Unique identifier of the event |
source | Where the event came from |
specversion | The CloudEvents spec version in use |
type | The kind of event, such as com.example.order.created |
Optional attributes such as subject, time, and datacontenttype add detail, and the payload travels in data:
{
"specversion": "1.0",
"id": "a1b2c3",
"source": "/shop/orders",
"type": "com.example.order.created",
"time": "2026-10-04T09:30:00Z",
"datacontenttype": "application/json",
"data": { "orderId": "8841", "total": 59.9 }
}The spec also defines how these events map onto transports such as HTTP, Kafka, and AMQP. The result is interoperability: tools from different vendors can produce, route, and consume events without bespoke adapters.
For the KCNA, file CloudEvents next to the other open standards you already know — OCI for images and runtimes, CRI, CNI, and CSI for Kubernetes plugin interfaces. The pattern is the same each time: a neutral specification that lets implementations be swapped. Our container runtimes, CRI, and OCI guide covers that pattern on the runtime side.
How the Pieces Fit Together
A realistic event-driven flow on Kubernetes might look like this:
- A customer places an order; the order service emits a CloudEvent of type
order.created. - Knative Eventing receives it at a Broker. A Trigger filtering on that type delivers it to an invoice service.
- The invoice service is a Knative Service currently scaled to zero. The activator buffers the event, a Pod starts (a cold start), and the event is delivered.
- Separately, the order service puts a message on a queue for fulfilment. A worker Deployment managed by KEDA scales from zero as the queue grows, and back to zero when it drains.
- Underneath it all, the Cluster Autoscaler adds or removes nodes as the total number of Pods changes.
Each layer does one job, and each is replaceable — which is the cloud native architecture idea in miniature.
Exam Cues: Mapping Scenarios to the Right Answer
| If the question describes… | Think |
|---|---|
| Running code without managing servers, billed per execution | Serverless / FaaS |
| No running instances when there is no traffic | Scale to zero |
| A delay on the first request after an idle period | Cold start |
| A Kubernetes-based platform for serverless workloads with revisions and traffic splitting | Knative (Serving) |
| Routing events from producers to consumers with brokers and triggers | Knative Eventing |
| Scaling a Deployment based on queue length or another external event source | KEDA |
| A vendor-neutral specification for describing event data | CloudEvents |
| Scaling on CPU or memory between a minimum and maximum | Horizontal Pod Autoscaler |
| Adding nodes because Pods are unschedulable | Cluster Autoscaler |
| A workload that is stateful, long-running, or latency-critical | Not a good serverless fit |
| Reducing dependency on one provider’s event formats | Open standards (CloudEvents) |
Watch for two distractors. First, “serverless means there are no servers” is false — the servers are abstracted, not absent. Second, “serverless replaces Kubernetes” is false — Knative and KEDA run on Kubernetes and extend it.
Practice the Concepts Until They’re Reflexive
Serverless questions on the KCNA are recognition questions: a short scenario, four plausible-sounding options, and one term that fits. The knowledge isn’t deep, but the terms sit close together — Knative versus KEDA, Serving versus Eventing, HPA versus KEDA — and under time pressure they blur.
The reliable fix is to answer scenario questions and read why each wrong option is wrong. Sailor.sh’s KCNA: Kubernetes and Cloud Native Associate Mock Exam Bundle offers timed, exam-style questions across the KCNA domains with explanations for every answer, which is a practical way to check whether these distinctions have stuck. For free warm-up material, try our KCNA practice questions, and for how this topic fits into the full syllabus, see the KCNA study guide.
Frequently Asked Questions
What does serverless mean in cloud native?
Serverless is an execution model where the platform manages the servers, scaling, and capacity for you. Code runs in response to events, scales automatically — including down to zero when idle — and on managed platforms is billed per use. Servers still exist; you just don’t operate them.
What is the difference between FaaS and serverless?
Functions as a Service is one form of serverless, where you deploy individual functions triggered by events. Serverless is the broader term and also includes Backend as a Service — fully managed components such as databases and authentication — and serverless containers, where you deploy a container image instead of a function.
What is Knative used for?
Knative is a CNCF project that adds serverless capabilities to Kubernetes. Knative Serving deploys and scales request-driven containers with revisions, traffic splitting, and scale-to-zero. Knative Eventing routes events between producers and consumers using brokers and triggers.
What is the difference between KEDA and the Horizontal Pod Autoscaler?
The HPA scales workloads based on metrics such as CPU and memory between a minimum and maximum replica count. KEDA extends this to external event sources like queue length or stream lag and adds scaling to and from zero. KEDA works with the HPA: it handles activation from zero and supplies metrics, while the HPA handles scaling from one replica upward.
What is a cold start?
A cold start is the delay experienced by the first request after a workload has been scaled to zero. The platform has to start a new instance — schedule a Pod, pull the image, start the container — before it can respond. Later requests are served by the running instance and are faster.
What is CloudEvents?
CloudEvents is a CNCF specification that defines a standard format for describing events, with required attributes id, source, specversion, and type. It makes events portable across services, platforms, and vendors, reducing lock-in. It is a specification, not a runtime or a message broker.
Do I need hands-on Knative or KEDA experience for the KCNA?
No. The KCNA is a multiple-choice, conceptual exam. You should know what serverless is, its trade-offs, and what Knative, KEDA, and CloudEvents each do — not how to install or configure them.
Conclusion
Serverless becomes straightforward once you separate the idea from the products. The idea is running event-driven code without managing servers, with automatic scaling that reaches zero — at the price of cold starts, statelessness, and less control. The products bring that idea to Kubernetes: Knative provides a serverless platform with Serving for request-driven containers and Eventing for event routing; KEDA scales ordinary workloads on external events and cooperates with the HPA; and CloudEvents standardizes how events are described so the pieces interoperate.
Hold on to the distinctions — Serving versus Eventing, Knative versus KEDA, platform versus specification — and the exam scenarios resolve quickly. From here, strengthen the neighboring topics with the cloud native architecture and observability guide and the service mesh concepts guide, then test your recall under timed conditions with the KCNA Mock Exam Bundle.