How Knative Functions fits together

Knative Functions provides a simple programming model for using functions on Knative, without requiring in-depth knowledge of Knative, Kubernetes, containers, or dockerfiles.

Knative Functions enables you to easily create, build, and deploy stateless, event-driven functions as Knative Services by using the func CLI.

For containerized workflows, func builds an Open Container Initiative (OCI) format image for you. Local builds and runs do not publish that image to a registry by default. Deployment normally builds the image when necessary, publishes it to your configured registry, and creates or updates a Knative Service.

You can create functions and manage function workflows by using the func CLI, or by using the kn func plugin for the Knative CLI.

From project to running service

Creating a function gives you a local project, not a deployed Service. Building prepares its container image; running locally lets you exercise the function before deploying it. Publishing transfers the image to a registry but does not create a running Service. Deployment makes it available on a Knative cluster. These are separate goals, so you can return to the relevant task guide without repeating the whole workflow.

A function deployed as a Knative Service uses Serving's routing and autoscaling. See Knative Serving and how concurrency affects autoscaling for the behavior of that deployed Service. To receive events from a Broker, deployment and subscription to CloudEvents are separate steps.

Function templates

Knative Functions provides templates that can be used to create basic functions, by initiating a function project boilerplate when you run a create command.

Templates allow you to choose the language and invocation format for your function. The built-in templates in Functions from Knative v1.24.0 provide both cloudevents and http formats for the languages below. Run func languages and func templates (or kn func languages and kn func templates) to check what your installed version and registered repositories actually provide:

• Node.js
• Python
• Go
• Quarkus
• Rust
• Spring Boot
• TypeScript

These links open the upstream main guides; select documentation matching the CLI version that generated your project before changing handler signatures. HTTP and CloudEvents templates expose different language-specific APIs. A CloudEvents template does not automatically create a Broker subscription, and support for a language does not imply support by every local builder.

Language packs

Functions can be written in any language supported by the available language packs. The language-pack contract is maintained in the func repository. To use a pack from a repository or a local directory, follow Using language packs.

Local and on-cluster builds

Local requirements depend on the builder. pack and s2i use a Docker-compatible daemon; the experimental host builder in Functions from Knative v1.24.0 uses the local Go or Python toolchain and assembles an OCI image without a Docker daemon. Host-based local run is different again: it starts a process rather than testing the container image. Availability depends on the CLI version and project layout, not just the language name.

An on-cluster build shifts that work to the cluster and requires build infrastructure such as Tekton Pipelines. It can be useful when you do not have a local Docker daemon or when building in a CI/CD workflow. See Building functions for the supported paths and their prerequisites; consult its upstream setup link for the detailed on-cluster build configuration.

What each verification establishes

A successful local build establishes that an image was produced, not that the handler behaves correctly. A local run and direct invocation exercise the handler in that local environment. A successful push establishes registry publication, not cluster pull access. Service readiness and remote invocation test the deployed endpoint, while a matching event sent through the Broker is needed to test a subscription.

These checks isolate different boundaries. A host-run success can coexist with a container dependency problem; a remotely reachable function can coexist with a missing or mismatched Trigger. Use the task guides to verify the boundary relevant to your goal rather than repeating the entire lifecycle.

Next steps

• To try one complete workflow, start the Functions Quickstart.
• To accomplish a specific goal, choose a task from the Functions overview.
• To look up flags and subcommands, use the upstream command reference rather than treating this explanation as a command catalog.