1.1 Knative 概述：发展历史、核心组件与典型应用场景
Knative 是 Google 联合 Pivotal、IBM、Red Hat 等公司在 2018 年 7 月开源的基于 Kubernetes 的 Serverless 编排框架。它旨在将 Serverless 工作负载的部署、扩缩容、事件驱动等能力标准化，让开发者无需关心底层基础设施，即可构建可弹性伸缩的云原生应用。
1.1.1 发展历史与演进路线
| 时间 | 里程碑 | 关键变化 |
|---|---|---|
| 2018.07 | Knative v0.1 发布 | 提出 Serving 与 Eventing 两大核心模块，基于 Istio 实现网络与流量管理 |
| 2019.11 | 进入 CNCF Incubating | 社区治理成熟，API 版本稳定为 v1，开始支持 Kourier 等轻量级网络层 |
| 2021.03 | Knative 1.0 正式发布 | 生产就绪声明，Serving API 达到 v1 稳定，Eventing 进入 v1beta1 |
| 2022-至今 | CNCF Graduated + 生态扩展 | 成为 CNCF 毕业项目，支持 Cilium 作为网络层，引入多租户、函数级扩缩容等高级特性 |
关键认知： Knative 并非一个独立平台，而是构建在 Kubernetes 之上的抽象层。它通过 CRD（Custom Resource Definition）和控制器模式，将 Serverless 能力以声明式 API 的形式暴露给用户。
1.1.2 核心组件：Serving 与 Eventing
Knative 由两个核心子项目组成，分别解决“如何运行无状态服务”和“如何连接事件源与消费者”的问题。
Serving：自动扩缩容与流量管理
- Service（ksvc）： 用户面向的顶层资源，自动管理 Configuration 和 Route 的生命周期。
- Configuration（config）： 维护服务的期望状态（镜像、环境变量、资源限制等），每次更新生成一个新的 Revision。
- Revision（rev）： 服务的不可变快照，包含代码和配置的特定版本。
- Route： 流量路由规则，支持按百分比分配流量到不同 Revision，实现灰度发布和回滚。
Eventing：事件驱动架构
- Broker： 事件网格的中央枢纽，负责接收和转发事件。
- Trigger： 定义事件过滤规则，将 Broker 中的事件路由到特定的消费者（Sink）。
- Source： 事件源，如 ApiServerSource、KafkaSource、SinkBinding 等，负责将外部事件引入 Knative 集群。
- Channel & Subscription： 提供更灵活的事件传递模型，支持点对点、发布/订阅等模式。
1.1.3 典型应用场景
| 场景 | 描述 | Knative 优势 |
|---|---|---|
| 事件驱动数据处理 | 从 Kafka、CloudEvents 等源接收事件，触发数据处理函数（如日志清洗、图片转码） | 自动扩缩容到零，事件驱动无需常驻 Pod，降低资源成本 |
| CI/CD 流水线任务 | 代码提交后自动触发构建、测试、部署流水线 | 基于 Eventing 的事件链编排，Serving 提供蓝绿部署和流量切换 |
| 微服务 API 网关 | 将 Knative Service 作为无状态 API 后端，结合自定义域名和 TLS 证书 | 内置 Revision 管理，支持按请求并发数自动扩缩容，避免资源浪费 |
| AI/ML 推理服务 | 部署模型推理端点，根据请求量动态调整 GPU/CPU 资源 | 支持 GPU 资源隔离，冷启动优化（预留 Pod），与 KFServing 集成 |
| Webhook 与回调处理 | 接收外部系统（GitHub、Stripe）的 Webhook 事件，执行业务逻辑 | 事件源丰富，Trigger 过滤规则灵活，无需维护常驻服务 |
课程重点： 在后续章节中，我们将深入探讨 Knative Serving 的容量参数配置（如 concurrency-target、container-concurrency、scale-to-zero 参数）以及 Cilium 作为网络层时可能出现的性能瓶颈诊断方法。理解本节的基础架构是后续调优的前提。