Knative
Knative adds serverless workload abstractions to Kubernetes. It runs stateless HTTP containers, routes events, manages immutable revisions, and can adjust serving capacity as demand changes.
itCloud native tools and technologies | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Knative
Knative is the layer you add after Kubernetes has already agreed to run containers, but before every application team has rebuilt its own collection of scaling rules, ingress settings, rollout machinery, and event plumbing. Kubernetes still does the foundational work. Knative puts a more application-shaped dashboard on top of it, which is less magical than it sounds and more useful than a pile of slightly different YAML files.
For HTTP work, remember the four names that look as if they arrived in a committee meeting: Service, Configuration, Revision, and Route. The Service owns the workload. The Configuration says what it should be. A Revision is the immutable snapshot created when that declaration changes. The Route decides which Revision receives traffic. That separation is why a new image does not have to receive all requests immediately.
The surprising bit is that scale to zero is not a free lunch with a tiny umbrella in it. Idle services can use no serving replicas, but the next request may wait while a pod is scheduled and becomes ready. The Activator can hold that request during startup. It cannot make slow initialization, missing cluster capacity, or a strict latency objective politely disappear.
Eventing follows the same preference for named boundaries. A producer sends a CloudEvent to a Broker. A Trigger filters it and sends a match to a subscriber. Producers do not need a list of consumers, which is pleasant right up until delivery fails. Retries and dead-letter sinks are platform controls; duplicate-safe business effects remain an application responsibility. The machinery is helpful. It does not become legally responsible for arithmetic.
Functions is a developer workflow, not a secret fourth runtime. It turns function source into an OCI image and deploys it as a Knative Service, so it inherits Serving behavior such as Revisions, Routes, and request-driven scaling. Stateful data still belongs outside the instance that may be scaled down or replaced.
Read the intro when you need the full platform map and its operational boundaries. Use the slides for the request and event flows. Keep the cheatsheet beside you when Service, Route, Broker, Channel, and Trigger begin to look like a word-association test. Then use the practice reference and exercise to create a Service, make a change, and see the second Revision appear. That is the small, respectable proof that the mental model has stopped being decorative.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://knative.dev/docs/
Supports
- Knative as a Kubernetes-based serverless platform
- Serving, Eventing, and Functions component boundaries
- Component interoperability and independent adoption
- Use cases, prerequisites, and platform evaluation
- Quiz answers about the platform boundary and component selection
- https://knative.dev/docs/install/
Supports
- Serving and Eventing as independently installable cluster components
- Functions as a client tool rather than an installed cluster component
- Quickstart and production installation paths
- Kubernetes administration and networking prerequisites
- Installation link rationale
- https://knative.dev/docs/serving/
Supports
- Service, Route, Configuration, and Revision responsibilities
- Immutable Revisions created by configuration changes
- Fractional traffic and named routes
- Stateless HTTP serving and scale-to-zero use cases
- Serving quiz answers and reference rationale
- https://knative.dev/docs/serving/architecture/
Supports
- Activator responsibility during scale from zero
- Autoscaler responsibility
- Networking layer and ingress boundary
- Serving request-path explanations
- https://knative.dev/docs/serving/autoscaling/
Supports
- Knative Pod Autoscaler as the default autoscaler
- Scale to zero and minimum replica behavior
- Concurrency, metric, target, and scale-bound configuration areas
- Startup tradeoff and autoscaling quiz answer
- https://knative.dev/docs/serving/traffic-management/
Supports
- Traffic routing among Revisions
- Percentage-based traffic and revision tags
- Canary, staged release, and rollback mental models
- Route quiz answer and link rationale
- https://knative.dev/docs/eventing/
Supports
- Producer, source, sink, and loosely coupled event relationships
- CloudEvents over HTTP delivery
- Broker and Trigger event flow
- Eventing quiz answers and link rationale
- https://knative.dev/docs/eventing/brokers/
Supports
- Broker as shared event ingress
- Broker relationship with Triggers and subscribers
- Broker-based decoupling quiz answer
- https://knative.dev/docs/eventing/triggers/
Supports
- Trigger association with a Broker, filter, and subscriber
- Filtered event delivery
- Trigger quiz answers
- https://knative.dev/docs/eventing/channels/
Supports
- Channel and Subscription event-delivery relationship
- Contrast between explicit Channel routing and Broker routing
- https://knative.dev/docs/eventing/event-delivery/
Supports
- Retry configuration and delay policies
- Dead-letter sinks
- Consumer responsibility for repeated delivery
- Delivery-failure quiz answer and link rationale
- https://knative.dev/docs/functions/
Supports
- Function templates and func CLI workflow
- OCI image creation
- Deployment of functions as Knative Services
- Local development without Kubernetes
- Functions quiz answer and link rationale
- https://github.com/sindresorhus/awesome
Supports
- Discovery path to curated Kubernetes and serverless lists
- https://github.com/anaibol/awesome-serverless
Supports
- Discovery of Knative, OpenFaaS, Fission, and Serverless Framework
- Selection of non-duplicate serverless ecosystem comparisons
- https://docs.openfaas.com/
Supports
- OpenFaaS as a Kubernetes-oriented function and microservice platform
- Container packaging, autoscaling, metrics, and event integrations
- OpenFaaS Awesome Link rationale
- https://fission.io/docs/
Supports
- Fission as a Kubernetes serverless framework
- Functions, environments, packages, triggers, and architecture
- Fission Awesome Link rationale
- https://www.serverless.com/framework/docs
Supports
- Command-line and YAML workflow
- Deployment of code and provider infrastructure
- Serverless Framework Awesome Link rationale
- https://knative.dev/docs/getting-started/first-service/
Supports
- Local Quickstart setup
- Creating and inspecting a Knative Service
- Exercise success checks
- https://knative.dev/docs/install/knative-offerings/
Supports
- Examples of Knative-based managed and enterprise offerings
- Landscape context
- https://cloud.google.com/run/docs/overview/what-is-cloud-run
Supports
- Cloud Run as a managed container runtime
- Cloud Run landscape entry
- https://docs.redhat.com/en/documentation/red_hat_openshift_serverless/1.37/html/about_openshift_serverless/about-serverless
Supports
- OpenShift Serverless use of Knative Serving and Eventing
- OpenShift Serverless landscape entry
- https://cloud.ibm.com/docs/codeengine?topic=codeengine-about
Supports
- IBM Cloud Code Engine as a managed serverless platform
- IBM Cloud Code Engine landscape entry
- https://knative.dev/docs/eventing/brokers/broker-types/kafka-broker/
Supports
- Kafka-backed Knative Eventing broker implementation
- Knative Kafka Broker landscape entry
- https://knative.dev/docs/eventing/brokers/broker-types/rabbitmq-broker/
Supports
- RabbitMQ-backed Knative Eventing broker implementation
- Knative RabbitMQ Broker landscape entry
