1. 课程导入与全景认知

在云原生技术栈中，Serverless 并不是“没有服务器”，而是把服务器与集群的运维责任从业务团队转移到平台侧，让开发者只关注事件、请求与业务逻辑。Knative 是 Kubernetes 之上最主流的 Serverless 编排层之一，它把“请求驱动的弹性伸缩”“事件驱动”“流量灰度与版本管理”这些能力标准化为 Kubernetes CRD，使 Serverless 从托管云服务变成可自建、可迁移、可治理的平台能力。

理解 Knative，需要先抓住它的三个核心组件：Serving 负责请求驱动的无服务器工作负载，提供缩容到零、按并发自动扩缩、版本与流量切分；Eventing 负责事件驱动，提供 Broker、Trigger、Channel、Subscription 等抽象，把事件源与消费者解耦；Functions 则提供从源码到镜像再到 Serving 服务的构建与部署路径。三者共同构成“请求—事件—函数”的完整 Serverless 运行时。

从生产视角看，Knative 的可靠性治理并不是“让 Pod 不挂”，而是围绕一条请求或事件的生命周期，保证它在冷启动、扩缩容、版本切换、事件投递、依赖故障等场景下仍然可预期。下图给出本节的全景认知：左侧是请求与事件两类入口，中间是 Knative 的核心控制面与数据面，右侧是生产可靠性治理的四个关键目标，底部是课程路线图的五个阶段。

生产实践中，Knative 的挑战往往集中在四个地方。第一是冷启动：当 Revision 缩容到零后，首个请求需要触发 Pod 创建、镜像拉取、应用启动，延迟可能从几十毫秒上升到数秒。第二是扩缩容抖动：KPA 依据并发或 RPS 决策，若指标采集窗口、目标并发、最小/最大副本设置不当，会出现频繁扩缩或扩容滞后。第三是事件投递可靠性：Broker 与 Trigger 的重试、死信、顺序与幂等需要显式设计，否则事件可能丢失或重复。第四是版本与流量治理：Route 的流量切分、灰度比例、回滚策略必须与发布流程绑定，否则故障版本会持续承接流量。

可靠性治理的目标可以归纳为四个可验证的指标：冷启动 P95 延迟、扩缩容响应时间、事件端到端投递成功率、版本回滚耗时。它们分别对应 Serving 的 KPA 与 Revision 配置、Eventing 的 Trigger 与死信策略、以及 Route 的流量管理能力。课程后续会围绕这些指标，给出可落地的参数、配置与验证方法。

本课程共 30 章，路线图分为五个阶段：认知阶段建立 Knative 与 Serverless 的完整心智模型；部署阶段完成 Serving 服务与 Eventing 事件流的搭建；优化阶段聚焦冷启动、并发与资源调优；可靠性阶段覆盖灰度发布、回滚、事件重试与死信；治理阶段则落到可观测性、容量规划与故障演练。每一章都会围绕一个可验证的生产问题展开，并给出对应的配置、命令或判断依据，帮助你把 Knative 从“能跑”推进到“可治理”。