1. 课程导论：集群升级背景、Operator 适配新 API 版本的必要性、课程目标与受众
1.1 集群升级背景：Kubernetes API 版本演进与兼容性挑战
Kubernetes 社区以每年 3 个大版本的节奏快速迭代，每个版本都可能引入 API 资源的增删改、字段废弃或行为变更。对于运行在集群之上的 Operator 而言，集群升级不仅仅是 kube-apiserver 版本的提升，更意味着其依赖的 API 版本可能被标记为 deprecated 并在后续版本中彻底移除。
| Kubernetes 版本 | 典型 API 变更 | 对 Operator 的影响 |
|---|---|---|
| v1.16 → v1.22 | extensions/v1beta1 资源全面移除 | Ingress、DaemonSet 等资源需迁移至 networking.k8s.io/v1、apps/v1 |
| v1.22 → v1.25 | batch/v1beta1 CronJob 移除 | CronJob 控制器必须使用 batch/v1 |
| v1.25 → v1.28 | policy/v1beta1 PodDisruptionBudget 移除 | PDB 管理需切换至 policy/v1 |
关键事实：Kubernetes 社区遵循 N-2 支持策略，即当前版本只保证与最近两个次版本（N-2）的 API 兼容。Operator 若未及时适配新 API 版本，在集群升级后将面临 CRD 无法注册、资源同步失败、控制器崩溃 等严重问题。
1.2 Operator 适配新 API 版本的必要性
Operator 作为 Kubernetes 的扩展控制器，通过监听和操作原生 API 资源来实现业务逻辑。当集群 API 版本发生变更时，Operator 必须同步适配，否则将导致以下后果：
- 功能失效：使用已移除 API 版本的资源创建/更新操作会返回 404 错误，控制器无法完成调谐循环。
- 安全风险：废弃 API 版本可能缺少最新的安全校验和准入控制，暴露攻击面。
- 运维中断：集群升级后 Operator 无法启动或持续报错，影响上层业务连续性。
- 生态兼容性下降：无法与新版集群的监控、日志、备份等工具链集成。
1.3 课程目标与受众
本课程旨在帮助 Operator 开发者和平台工程师系统掌握集群升级后 Operator 适配新 API 版本的方法论与测试实践。通过理论讲解、代码示例和测试案例，学员将具备独立完成 Operator API 版本迁移与功能验证的能力。
课程核心目标：
- 理解 Kubernetes API 版本废弃策略与 Operator 的依赖关系。
- 掌握使用
client-gen、conversion-gen等工具进行 API 版本迁移的工程方法。 - 学会设计针对多 API 版本的单元测试、集成测试与端到端测试。
- 能够制定 Operator 版本兼容性矩阵与升级回滚策略。
| 受众角色 | 前置知识要求 | 课程收益 |
|---|---|---|
| Operator 开发者 | 熟悉 Go 语言、Kubernetes 基础资源、controller-runtime 框架 | 掌握 API 版本迁移编码技巧与测试框架使用 |
| 平台/SRE 工程师 | 了解 Kubernetes 集群运维、Operator 部署与监控 | 能够制定升级前检查清单与回滚预案 |
| 测试工程师 | 具备 Kubernetes 资源操作经验 | 学会设计兼容性测试用例与自动化测试流水线 |
1.4 课程内容概览
本课程共分为 6 个模块，从 API 版本变更原理到实际适配与测试，层层递进：
- API 版本变更原理与检测：Kubernetes API 废弃策略、版本检测工具与集群升级影响评估。
- Operator 代码适配：CRD 版本迁移、客户端代码生成、转换函数编写与多版本存储。
- 单元测试与集成测试：使用 fake client、envtest 模拟多 API 版本环境进行测试。
- 端到端测试与混沌工程：在真实集群中验证 Operator 在升级前后的行为一致性。
- CI/CD 集成与自动化：将适配与测试流程嵌入持续集成流水线。
- 案例实战与最佳实践：基于开源 Operator 的完整适配案例与常见避坑指南。
重要提示：本课程所有代码示例均基于 Kubernetes v1.28+ 和 controller-runtime v0.16+。学员在实操前应确保本地开发环境已安装
kubebuilder、kind 或 minikube 等工具。