1. 课程导论：集群升级背景、租户隔离概念、Resource Model 治理的重要性
1.1 集群升级背景：从单体运维到多租户协同
在云原生架构演进中，Kubernetes 集群升级已不再是简单的版本号变更。随着企业将生产环境划分为多个租户（部门、项目、环境），集群升级面临的核心矛盾从“如何升级”转变为“如何在升级过程中保障租户间的隔离性与稳定性”。
核心挑战： 一次集群升级可能影响数十个租户的工作负载，任何配置漂移或资源冲突都可能导致跨租户故障扩散。
典型的集群升级场景包含以下关键要素：
| 要素 | 说明 | 升级风险 |
|---|---|---|
| 控制面升级 | kube-apiserver、scheduler、controller-manager 版本更新 | API 兼容性断裂、准入控制策略失效 |
| 节点池升级 | 工作节点操作系统、kubelet、容器运行时替换 | Pod 驱逐导致租户服务中断 |
| CNI/CSI 升级 | 网络插件与存储插件版本同步 | 租户网络策略丢失、PV 挂载失败 |
| 资源配额迁移 | ResourceQuota、LimitRange 等资源对象重新生效 | 配额计算偏差、Pod 创建阻塞 |
1.2 租户隔离概念：逻辑边界与资源域
租户隔离是指在共享集群基础设施上，通过资源模型为每个租户划定独立的逻辑边界。在 Kubernetes 中，租户隔离通常通过 Namespace、RBAC、NetworkPolicy、ResourceQuota 等原生资源组合实现，但在大规模多租户场景下，需要更精细的 Resource Model 治理来定义隔离粒度。
关键认知： 租户隔离不是简单的 Namespace 划分，而是资源模型（Resource Model）在集群升级过程中保持一致性、可审计性和可恢复性的能力。
租户隔离的常见层次：
- 软隔离（Soft Multi-tenancy）： 共享集群控制面，通过 RBAC 和配额限制租户行为，适用于内部开发环境。
- 硬隔离（Hard Multi-tenancy）： 使用虚拟节点、安全容器或独立控制面，适用于金融、医疗等合规场景。
- 混合隔离： 在集群升级期间，部分租户采用硬隔离保护，部分租户采用软隔离快速迭代。
1.3 Resource Model 治理的重要性
Resource Model（资源模型）是 Kubernetes 中描述、分配、限制和审计集群资源的抽象框架。在集群升级场景中，Resource Model 治理的核心目标是确保升级前后租户的资源边界、配额策略、优先级调度行为不发生意外偏移。
常见陷阱： 升级后 ResourceQuota 的 spec.hard 字段被默认值覆盖，导致租户资源上限被重置；或 PriorityClass 被删除，导致关键业务 Pod 被低优先级任务抢占。
Resource Model 治理在集群升级中的三大价值：
- 一致性保障： 通过声明式资源模型（如 YAML 模板、GitOps 仓库）确保升级前后每个租户的资源定义完全一致。
- 可审计性： 记录每次升级对 ResourceQuota、LimitRange、PriorityClass、PodDisruptionBudget 等资源的变更，支持回滚与追溯。
- 隔离性验证： 在升级后自动验证租户间的网络策略、资源配额、RBAC 绑定是否仍符合预期隔离边界。
1.4 课程目标与学习路径
本课程将围绕“集群升级中租户隔离蓝图的 Resource Model 治理”这一主题，从资源模型定义、升级前基线采集、升级中策略适配、升级后验证与回滚四个阶段展开。学员将掌握以下核心能力：
- 使用 ResourceQuota、LimitRange、PriorityClass、PodDisruptionBudget 构建租户隔离蓝图。
- 在集群升级过程中通过 GitOps 和 策略引擎 自动化治理资源模型。
- 设计可审计、可回滚的升级流程，确保多租户环境零故障迁移。
学习建议： 建议学员提前熟悉 Kubernetes 原生资源对象（Namespace、RBAC、NetworkPolicy）的基本操作，并准备一个至少包含 3 个租户的测试集群用于实验。