Accomplish a task¶
Find directions for a concrete goal in your application or cluster. These guides assume you know what you want to do; check each guide's prerequisites, permissions, and required components. If you are trying Knative for the first time, choose a guided learning route instead.
Develop and deploy functions¶
- Create a function project.
- Build a function and run it locally.
- Deploy a function and invoke it. For an existing published function image, use the no-build/no-push deployment route.
- If you need Broker events, subscribe a function to events. Event subscription is optional, not a prerequisite for local execution or an HTTP-only deployment.
Start with local project creation and execution; build separately when that is your goal. Deployment and event subscription are separate tasks with cluster, registry, and component prerequisites described in their guides.
For tooling setup, see installing func and
installing kn. For cluster-facing Functions commands,
use the effective kubeconfig/current-context guard.
A context selected only through a kubectl or kn flag does not select the
cluster for a later func command.
Deploy and manage HTTP services¶
- Have a container image? Deploy an HTTP container as a Knative Service.
- Manage traffic between revisions.
- Set and verify a concurrency target.
- Configure a custom domain for a Service.
Adapting an existing Kubernetes Deployment? Consult the Deployment-to-Service mapping reference for manifest correspondence and workload-fit constraints. It is not a migration or cutover procedure; creating a separate Service does not redirect existing clients.
For related scaling guides and settings, use the autoscaling topic overview, including scale bounds.
Route and process events¶
- Create a Broker.
- Use a Trigger to subscribe to Broker events.
- Create a PingSource.
- Bind an event producer to a sink.
- Configure Broker retries and a dead-letter sink, with an isolated failure test and receipt verification.
Source and Broker implementations have their own requirements. Use the Eventing overview to locate related resource guides.
Operate a Knative cluster¶
Cluster-level changes generally require administrator permissions. Application configuration and cluster defaults are different scopes; follow the guide for the scope you intend to change.
| Goal | Starting point |
|---|---|
| Install | Choose an installation path for an existing cluster. |
| Configure | Work with ConfigMaps or use the generic Operator-managed ConfigMap workflow, according to how your installation is managed. For other Operator changes, choose a Serving configuration goal or Eventing configuration goal. |
| Secure | Choose a security configuration or artifact-verification task. For security boundaries, read the threat model. |
| Observe | Collect Serving metrics or Eventing metrics. |
| Upgrade | Check the installed version, then consult the upgrade guidance. |
The administrator overview connects these responsibilities. Installation alone does not establish production readiness.
Secure a Knative installation¶
- Verify release images or verify client binaries.
- Configure Serving encryption for the communication path you intend to protect.
- For Eventing, consult transport encryption and authorization. These are feature-dependent paths: check the documented release, feature configuration, implementation compatibility, and prerequisites before changing a cluster. Transport encryption requires certificate setup; authorization requires sender identity/authentication. Do not assume either is enabled or applies uniformly to every component.
For trust boundaries and private vulnerability reporting, use security guidance and disclosure. Artifact verification and installation alone do not establish a secure deployment.
Investigate a problem¶
- Installation failing? Start with installation troubleshooting.
- Service not behaving as expected? Use Serving application debugging. Some checks are ingress-specific; use those matching your installation.
- Events not reaching a subscriber? Follow existing Broker/Trigger route checks.
- Confirmed delivery errors, retries, or dead-letter receipts? Use Events repeatedly fail delivery.
To practice debugging rather than repair your own route, use the Channel/Subscription demonstration.
For the reasons behind a setting, switch to explanation. For exact fields, defaults, and implementation constraints, use reference.