You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/concepts/README.md
+249-4Lines changed: 249 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,18 +7,263 @@ components:
7
7
function: explanation
8
8
---
9
9
10
-
# Concepts
10
+
# Knative Technical Overview
11
11
12
-
The documentation in this section explains commonly referenced Knative concepts and abstractions, and helps to provide you with a better understanding of how Knative works.
12
+
This comprehensive overview explains what Knative is, what problems it solves, and how its components work together. Whether you're evaluating Knative for your use case or need background information to understand the rest of the documentation, this section provides the conceptual foundation you need.
13
13
14
14
## What is Knative?
15
15
16
-
Knative is a platform-agnostic solution for running [serverless](https://en.wikipedia.org/wiki/Serverless_computing){target=_blank} deployments.
16
+
Knative is a Kubernetes-based platform that provides a complete set of middleware components for building, deploying, and managing modern [serverless](https://en.wikipedia.org/wiki/Serverless_computing){target=_blank} workloads. Knative extends Kubernetes to provide higher-level abstractions that simplify the development and operation of cloud-native applications.
17
+
18
+
### Problems Knative Solves
19
+
20
+
Knative addresses several key challenges in modern application development and deployment:
21
+
22
+
**Application Deployment Complexity**: Traditional Kubernetes requires deep knowledge of pods, services, deployments, and ingress resources. These constructs provide a lot of flexibility and complexity that most applications don't need. Knative provides simpler abstractions that handle these details automatically.
23
+
24
+
**Serverless Operations**: Manual scaling, cold starts, and traffic routing are complex to implement. Knative provides automatic scaling from zero to thousands of instances, intelligent traffic routing, and efficient resource utilization.
25
+
26
+
**Event-Driven Architecture**: Building reliable event-driven systems requires complex infrastructure for event ingestion, routing, and delivery. Building event routing and delivery into your application limits your choice of event delivery and architecture; Knative provides standardized event processing capabilities across multiple event implementations using CloudEvents for delivery and Kubernetes for configuration.
27
+
28
+
**Developer Experience**: Moving from code to running applications involves multiple steps and tools. Knative Functions provide a streamlined and standardized developer experience for building and deploying stateless functions as standard containers. Build and test locally without Kubernetes, and avoid managing build details like Dockerfiles and Kubernetes resources until you need them.
29
+
30
+
**Platform Lock-in**: Cloud-specific serverless solutions create vendor lock-in. Knative runs on any Kubernetes cluster, providing portability across cloud providers and on-premises environments.
31
+
32
+
## Background Knowledge
33
+
34
+
While you didn't need any specific programming experience to get started with Knative, you'll pick up the following concepts along the way. Knative will manage a lot of these in the background, so you can dive in deep when you're ready to learn.
35
+
36
+
-**Basic Kubernetes knowledge**: Understanding of pods, services, and deployments
37
+
-**Container concepts**: How to build and manage container images
38
+
-**HTTP/REST APIs**: Understanding of web service fundamentals
39
+
-**Basic YAML**: Ability to read and write Kubernetes resource definitions
40
+
41
+
For event-driven features, familiarity with:
42
+
-**Event-driven patterns**: Basic understanding of producers, consumers, and message routing
43
+
-**CloudEvents specification**: Helpful but not required (Knative handles the details)
44
+
45
+
## Architecture Overview
46
+
47
+
Knative consists of three main components that work together to provide a complete serverless platform:
48
+
49
+
{draggable=false}
50
+
51
+
**Knative Serving**: An HTTP-triggered autoscaling container runtime that manages the complete lifecycle of stateless HTTP services, including deployment, routing, and automatic scaling.
52
+
53
+
**Knative Eventing**: A CloudEvents-over-HTTP asynchronous routing layer that provides infrastructure for consuming and producing events, enabling loose coupling between event producers and consumers.
54
+
55
+
**Knative Functions**: A developer-focused function framework that leverages Serving and Eventing components to provide a simplified experience for building and deploying stateless functions.
56
+
57
+
These components can be used independently or together, allowing you to adopt Knative incrementally based on your needs.
17
58
18
59
## Knative Serving
19
60
20
61
--8<-- "about-serving.md"
21
62
22
-
## Knative Eventing - The Event-driven application platform for Kubernetes
63
+
### Key Serving Features
64
+
65
+
**Automatic Scaling**: Services automatically scale from zero to handle incoming traffic and scale back down when idle, optimizing resource usage and costs.
66
+
67
+
**Traffic Management**: Built-in support for blue-green deployments, canary releases, and traffic splitting between different revisions of your application.
68
+
69
+
**Networking**: Automatic ingress configuration with support for custom domains, TLS termination, and integration with service mesh technologies.
70
+
71
+
**Kubernetes Native**: Knative builds on the Kubernetes Pod abstraction, making it easy to access functionality like service accounts, accelerator access, and container sandboxing.
72
+
73
+
**Configuration Management**: Clean separation between application code and configuration, following twelve-factor app principles.
74
+
75
+
### Request Flow in Serving
76
+
77
+
{draggable=false}
78
+
79
+
When a request is made to a Knative Service:
80
+
81
+
1.**Ingress Layer**: The request enters through the configured networking layer (Kourier, Istio, or Contour)
82
+
2.**Routing Decision**: Based on current traffic patterns and scaling state, requests are routed either to the Activator or directly to application pods
83
+
3.**Scaling**: If no pods are running (scale-to-zero), the Activator queues the request and signals the Autoscaler to create pods
84
+
4.**Queue-Proxy**: All requests pass through the Queue-Proxy sidecar, which enforces concurrency limits and collects metrics
85
+
5.**Application**: The request reaches your application container
86
+
87
+
For detailed information, see the [request flow documentation](../serving/request-flow.md).
88
+
89
+
### GPU Resources and LLM Inference
90
+
91
+
Knative Serving can leverage Kubernetes pod capabilities to access specialized hardware resources like GPUs, making it an excellent platform for AI/ML inference workloads:
92
+
93
+
**GPU Resource Access**: Since Knative Services are implemented as Kubernetes pods, you can request GPU resources using standard Kubernetes resource specifications. This enables running inference models that require GPU acceleration while benefiting from Knative's automatic scaling and traffic management.
94
+
95
+
**LLM Inference Support**: Knative Serving provides an ideal foundation for Large Language Model (LLM) inference services, offering:
96
+
97
+
-**Automatic scaling** from zero to multiple GPU-enabled pods based on request demand
98
+
-**Traffic splitting** for A/B testing different model versions or configurations
99
+
-**Resource efficiency** by scaling down expensive GPU resources when not in use
100
+
-**Standard HTTP interfaces** for model serving and inference endpoints
101
+
102
+
**KServe Integration**: For production LLM deployments, consider using [KServe](https://kserve.github.io/website/latest/), a Kubernetes-native model serving platform built on Knative Serving. KServe provides:
103
+
104
+
- Standardized inference protocols and multi-framework support
105
+
- Advanced features like model ensembling, explainability, and drift detection
106
+
- Optimized serving runtimes for popular ML frameworks (TensorFlow, PyTorch, ONNX, etc.)
107
+
- Built-in support for autoscaling GPU workloads and batching requests
108
+
109
+
Whether using Knative Serving directly for custom inference services or through KServe for standardized model serving, you get the benefits of Kubernetes-native resource management combined with serverless operational characteristics.
110
+
111
+
## Knative Eventing
23
112
24
113
--8<-- "about-eventing.md"
114
+
115
+
### Key Eventing Concepts
116
+
117
+
**Event Sources**: Components that generate events from external systems (databases, message queues, cloud services, etc.) and send them into the Knative event mesh.
118
+
119
+
**Brokers**: Event routers that receive events from sources and forward them to interested consumers based on CloudEvent attributes.
120
+
121
+
**Triggers**: Configuration objects that define which events should be delivered to which consumers, using filtering based on event metadata.
122
+
123
+
**Sinks**: Event consumers that receive and process events. These can be Knative Services, Kubernetes Services, or external endpoints.
124
+
125
+
**Channels**: Lower-level primitives for point-to-point event delivery between producers and consumers.
126
+
127
+
### Event Flow in Eventing
128
+
129
+
{draggable=false}
130
+
131
+
A typical event flow involves:
132
+
133
+
1.**Event Generation**: An event source detects a change or condition and creates a CloudEvent
134
+
2.**Event Ingestion**: The event is sent to a Broker via HTTP POST
135
+
3.**Event Routing**: The Broker evaluates Triggers to determine which consumers should receive the event
136
+
4.**Event Delivery**: The event is delivered to matching consumers as HTTP requests
137
+
5.**Event Processing**: Consumers process the event and optionally produce response events
138
+
139
+
### Eventing Use Cases
140
+
141
+
-**Data Pipeline Processing**: Transform and route data through multiple processing stages
142
+
-**Integration Patterns**: Connect disparate systems using event-driven communication
143
+
-**Workflow Orchestration**: Coordinate complex business processes across multiple services
144
+
-**Real-time Analytics**: Process streaming data for monitoring and alerting
145
+
146
+
## Knative Functions
147
+
148
+
--8<-- "about-functions.md"
149
+
150
+
### Functions Development Model
151
+
152
+
Knative Functions provide a simplified programming model that abstracts away infrastructure concerns:
153
+
154
+
**Function Signature**: Functions follow a simple signature pattern leveraging standard libraries (such as HTTP and CloudEvents) to prevent lock-in.
155
+
156
+
**Built-in Templates**: Language-specific templates provide starting points for common function patterns and integrate with popular frameworks.
157
+
158
+
**Local Development**: Functions can be built, run, and tested locally before deployment to Kubernetes.
159
+
160
+
**Automatic Containerization**: The `func` CLI automatically builds container images from your function code without requiring Dockerfile expertise.
161
+
162
+
**Easy Deployment**: Function containers can be run anywhere you can run an HTTP application. `func` can also deploy your container to Knative Serving, where you can manage it with the `kn` CLI or standard Kubernetes YAML.
163
+
164
+
### Supported Languages and Runtimes
165
+
166
+
Functions support multiple programming languages through language packs:
167
+
168
+
-**Node.js**: Using popular frameworks like Express
169
+
-**Python**: With Flask and FastAPI support
170
+
-**Go**: Native Go HTTP handlers
171
+
-**Java**: Using Spring Boot and Quarkus
172
+
-**TypeScript**: Full TypeScript support with Node.js
173
+
174
+
You can also build your own language packs to customize the output container to your own specifications.
175
+
176
+
### Function Deployment and Lifecycle
177
+
178
+
<!-- TODO: use img: shapes for these icons -->
179
+
```mermaid
180
+
flowchart TD
181
+
init>"`<code>func init</code>
182
+
to create a function`"]
183
+
git@{ shape: lin-cyl, label: "fa:fa-git-alt local repo" }
184
+
laptop@{ shape: win-pane, label: "Local Development fa:fa-docker" }
1.**Development**: Write your function using language-specific templates
197
+
2.**Building**: The `func` CLI creates an optimized container image
198
+
3.**Deployment**: Functions are deployed as Knative Services with automatic scaling
199
+
4.**Invocation**: Functions can be triggered by HTTP requests or CloudEvents
200
+
5.**Management**: Update, delete, and monitor functions using familiar Kubernetes tools
201
+
202
+
## System Integration and Interoperability
203
+
204
+
### How Components Work Together
205
+
206
+
While each Knative component can be used independently, they're designed to work seamlessly together:
207
+
208
+
**Functions + Serving**: Functions are deployed as Knative Services, inheriting all serving capabilities like autoscaling and traffic management.
209
+
210
+
**Functions + Eventing**: Functions can be triggered by CloudEvents, enabling event-driven function execution and microservice orchestration.
211
+
212
+
**Serving + Eventing**: Services can act as event sources or sinks, participating in complex event-driven workflows.
213
+
214
+
### Integration with Kubernetes Ecosystem
215
+
216
+
Knative integrates with standard Kubernetes resources and third-party tools:
217
+
218
+
**Kubernetes-native resources**: Serving and Eventing are implemented as Kubernetes custom resources, meaning that you can use the same policy and IAM tools you use for Kubernetes.
219
+
220
+
**Builds on Kubernetes**: Serving creates Pods (so you can use GPUs, service accounts, and other Kubernetes features), and Eventing can easily deliver events to Kubernetes services as well as Serving functions.
221
+
222
+
**Networking**: Integrates with cert-manager for certificate management, and with Gateway API for ingress. Integrates with Istio, Envoy, and other service mesh technologies for advanced traffic management and security.
223
+
224
+
**Monitoring**: Using [OpenTelemetry](https://opentelemetry.io/), integrates with Prometheus, Grafana, Jaeger, and many other observability tools for metrics and monitoring.
225
+
226
+
**CI/CD**: Compatible with GitOps workflows, Tekton Pipelines, and other continuous deployment tools.
227
+
228
+
## Use Cases and When to Choose Knative
229
+
230
+
### Ideal Use Cases
231
+
232
+
**API Development**: Rapidly develop and deploy REST APIs with built-in scaling and traffic management.
233
+
234
+
**Event-Driven Applications**: Process events from various sources with reliable delivery and error handling.
235
+
236
+
**Inference Services**: Use Knative directly, or integrate with [KServe](https://kserve.github.io/website/latest/) to easily manage AI inference models.
237
+
238
+
**Microservices Architecture**: Build and deploy loosely coupled services with automatic scaling and service discovery.
239
+
240
+
**Integration Workflows**: Connect legacy systems and SaaS applications using event-driven patterns.
241
+
242
+
**Edge Computing**: Deploy lightweight functions and services closer to users or data sources.
243
+
244
+
**Development Environments**: Automatically scale down development environments when not in use; start them up again when requests arrive.
245
+
246
+
### Evaluation Criteria
247
+
248
+
Choose Knative when you need:
249
+
250
+
-**Kubernetes-native serverless** with no vendor lock-in
251
+
-**Automatic scaling** including scale-to-zero capabilities
252
+
-**Event-driven architecture** with standardized event processing
253
+
-**Developer productivity** improvements for cloud-native applications
254
+
-**Cost optimization** through efficient resource utilization
255
+
-**Flexibility** to use components independently based on your needs
256
+
257
+
Consider alternatives when:
258
+
259
+
- You need extremely low cold-start latency (sub-100ms)
260
+
- Your workloads require persistent state or long-running processes
261
+
262
+
## Next Steps
263
+
264
+
-**Installation**: Get started with [Knative installation](../install/README.md)
265
+
-**Quick Start**: Try the [Knative Quickstart](../getting-started/README.md) for hands-on experience
266
+
-**Serving Guide**: Learn more about [Knative Serving](../serving/README.md)
0 commit comments