1. 课程导论：Serverless 平台概述、集群升级的重要性、版本兼容性测试的目标与范围
1.1 Serverless 平台架构概述
Serverless 平台的核心价值在于将基础设施的复杂性从开发者侧剥离，让开发者只需聚焦业务代码。从 SRE 和架构视角看，一个生产级 Serverless 平台通常由以下关键组件构成：
| 组件层 | 核心模块 | 职责说明 |
|---|---|---|
| 接入层 | API Gateway / Ingress | 请求路由、认证鉴权、限流熔断、协议转换 |
| 控制面 | Function Controller / Scheduler | 函数生命周期管理、弹性伸缩决策、版本管理与灰度发布 |
| 数据面 | Pod / Sandbox / Runtime | 函数实际执行环境，支持多种运行时（Node.js、Python、Java 等） |
| 存储层 | etcd / 对象存储 / 镜像仓库 | 集群状态持久化、函数代码与依赖存储、容器镜像分发 |
| 可观测层 | Metrics / Logging / Tracing | 调用链追踪、性能指标采集、日志聚合与告警 |
架构视角： 控制面与数据面的解耦程度直接决定了集群升级的复杂度。控制面组件（如 K8s API Server、自定义控制器）的升级往往需要数据面（如 kubelet、容器运行时）的版本匹配，否则会导致调度失败或函数执行异常。
1.2 集群升级的重要性与挑战
Serverless 平台底层依赖 Kubernetes 集群及周边生态组件（如 Istio、Knative、Keda 等）。集群升级并非简单的版本号变更，而是一次涉及多组件协同、API 兼容性、数据面稳定性的高风险操作。升级失败可能导致：
- 控制面不可用： API Server 版本升级导致自定义资源（CRD）版本失效，函数无法创建或更新。
- 数据面异常： kubelet 版本与容器运行时不兼容，导致 Pod 启动失败或 Sandbox 创建超时。
- 网络策略失效： CNI 插件版本不匹配，导致函数间调用超时或服务网格 Sidecar 注入失败。
- 可观测性中断： Metrics Server 或日志采集 Agent 版本过旧，无法采集新版本集群的指标。
SRE 经验： 在 Serverless 场景下，集群升级的“回滚窗口”极短。由于函数实例生命周期短、调用频率波动大，一旦升级后出现兼容性问题，很难在不影响在线业务的情况下快速回退。因此，版本兼容性测试必须前置到升级流程中，作为卡点而非事后补救。
1.3 版本兼容性测试的目标与范围
本课程定义的版本兼容性测试，其核心目标是在集群升级前、中、后三个阶段，系统性地验证 Serverless 平台各组件在新旧版本间的行为一致性。具体目标与范围如下：
| 维度 | 目标 | 测试范围 |
|---|---|---|
| API 兼容性 | 确保新旧版本 API 的请求/响应结构、字段语义、错误码一致 | K8s API、CRD、自定义 API、gRPC 接口 |
| 数据面兼容性 | 验证函数执行环境（Pod/Sandbox）在升级后仍能正常启动、运行、销毁 | 容器运行时、Sandbox 镜像、Init 容器、健康检查 |
| 网络兼容性 | 确认服务发现、负载均衡、网络策略在升级后不退化 | Service、Ingress、NetworkPolicy、mTLS 配置 |
| 可观测性兼容性 | 保证监控、日志、链路追踪数据在新集群中仍能正确采集与上报 | Metrics 端点、日志格式、Trace Context 传播 |
| 存储兼容性 | 验证 etcd 数据迁移、PV/PVC 挂载、对象存储 SDK 版本兼容 | etcd 版本、CSI 驱动、对象存储客户端 |
1.4 兼容性测试的层次划分
为了在有限资源下最大化测试效率，我们将兼容性测试划分为三个层次，每个层次对应不同的测试深度与执行频率：
- 单元级兼容性测试： 针对单个组件（如 Function Controller、K8s API 客户端）的 API 版本适配性进行验证，通常在 CI 阶段执行。
- 集成级兼容性测试： 验证控制面与数据面、控制面与存储层之间的接口兼容性，在预发环境执行。
- 端到端兼容性测试： 模拟真实用户流量，验证完整的函数创建、调用、监控、销毁链路在升级前后的行为一致性，在生产灰度环境执行。