1. Knative 概述：项目起源、核心组件与云原生无服务器架构的价值
1.1 项目起源：从 Kubernetes 原生扩展到无服务器
Knative 是由 Google 联合 Pivotal、IBM、Red Hat 等公司在 2018 年 7 月发起的开源项目，旨在为 Kubernetes 提供一套构建、部署和管理无服务器工作负载的通用平台。其核心目标并非重新发明容器编排，而是在 Kubernetes 之上抽象出面向开发者与平台运维者的无服务器原语，解决当时 Kubernetes 原生部署中“冷启动延迟高”、“自动扩缩响应慢”、“事件驱动集成复杂”等痛点。
| 时间节点 | 里程碑事件 | 关键影响 |
|---|---|---|
| 2018.07 | Knative 首次公开 | 提出 Serving、Eventing、Build（后演变为 Tekton）三大组件 |
| 2019.03 | v0.1 发布 | 支持基于请求的自动扩缩（KPA）与 Istio 集成 |
| 2020.02 | Build 组件独立为 Tekton | 专注 CI/CD 流水线标准化，成为 CD 基金会项目 |
| 2021.11 | Knative 成为 CNCF 孵化项目 | 社区治理成熟，企业级采用加速 |
| 2023+ | v1.x 稳定版本 | Gateway API 集成、Queue-Proxy 性能优化、多租户增强 |
关键认知：Knative 不是 Serverless 的“替代品”，而是 Kubernetes 的“Serverless 扩展层”。它让集群既能运行传统长时服务，也能按需启动无服务器工作负载，实现资源池的统一调度。
1.2 核心组件：Serving、Eventing、Tekton
Knative 体系由三个相互独立但可组合的组件构成，分别覆盖无服务器应用的部署运行、事件驱动和持续交付三大场景。
组件关系速览：Serving 负责“跑起来并自动扩缩”，Eventing 负责“事件进来并触发”，Tekton 负责“代码变成镜像并部署”。三者通过 Kubernetes CRD 和标准 API 深度集成。
1.2.1 Knative Serving
- 核心能力：基于请求的自动扩缩（缩容至零）、流量灰度（Revision 版本管理）、冷启动加速（Activator + Queue-Proxy 架构）。
- 关键资源：Service、Route、Configuration、Revision。Service 作为用户入口，自动管理 Configuration 和 Route 的生命周期。
- 自动扩缩策略：支持 KPA（Knative Pod Autoscaler）和 K8s HPA 两种模式，默认使用基于并发数（Concurrency）的 KPA，响应速度远快于 CPU/Memory 指标。
1.2.2 Knative Eventing
- 核心能力：事件源（Event Source）接入、事件通道（Channel）路由、触发器（Trigger）过滤、Broker 事件总线。
- 关键资源：Broker、Trigger、Channel、Subscription、EventSource（如 ApiServerSource、KafkaSource、PingSource）。
- 架构优势：事件生产者与消费者完全解耦，支持 CloudEvents 规范，可跨集群、跨云的事件路由。
1.2.3 Tekton（原 Knative Build）
- 核心能力：声明式 CI/CD 流水线，以 Task 和 Pipeline 为基本单元，支持并行、依赖、参数化执行。
- 关键资源：Task、TaskRun、Pipeline、PipelineRun、PipelineResource（已逐步被参数替代）。
- 与 Knative 集成：Tekton 可触发 Knative Service 的自动部署，实现“代码提交 → 构建 → 发布 → 自动扩缩”全链路自动化。
1.3 云原生无服务器架构的价值
Knative 所代表的云原生无服务器架构，在传统 Serverless（如 AWS Lambda）与 Kubernetes 容器编排之间找到了平衡点。其核心价值体现在以下四个维度：
| 价值维度 | 传统 K8s 部署 | Knative 无服务器模式 | 收益量化参考 |
|---|---|---|---|
| 资源利用率 | Pod 常驻运行，即使无请求也占用资源 | 缩容至零，请求到达时秒级启动 | 空闲时段资源节省 60%~90% |
| 运维复杂度 | 需手动配置 HPA、Ingress、灰度策略 | 声明式 API 自动管理扩缩、路由、版本 | 运维配置量减少约 70% |
| 事件驱动能力 | 需额外部署消息队列 + 自定义 Controller | 原生 Broker/Trigger 机制，CloudEvents 标准 | 集成开发周期缩短 50%+ |
| CI/CD 一体化 | Jenkins/GitLab CI 与 K8s 部署脚本分离 | Tekton 流水线直接触发 Knative Service 更新 | 发布流程从小时级降至分钟级 |
适用场景提醒：Knative 并非银弹。对于延迟敏感型（如实时交易）、长连接型（如 WebSocket 长轮询）、GPU 密集型工作负载，建议评估冷启动开销和 Queue-Proxy 代理延迟后再决定是否采用。
1.4 本章小结
- Knative 是 Kubernetes 原生的无服务器扩展层，由 Serving、Eventing、Tekton 三大组件构成。
- Serving 负责自动扩缩（含缩零）与流量管理；Eventing 负责事件驱动解耦；Tekton 负责声明式 CI/CD 流水线。
- 云原生无服务器架构的核心价值在于：资源按需使用、运维声明式简化、事件原生集成、CI/CD 全链路自动化。
- 后续章节将深入 Knative Serving 的自动扩缩原理、Tekton 流水线资源优化配置，以及两者在测试任务中的联合调优实践。