2. Crossplane 核心概念回顾：Provider、Managed Resource、Composite Resource、Claim 的关系
在进入容量突增水位预测之前，必须重新梳理 Crossplane 的四个核心概念及其协作关系。这些概念构成了服务目录的底层骨架，也是后续水位预测策略所依赖的资源抽象层级。
2.1 四层抽象模型
Crossplane 将云资源的管理抽象为四个层次，从底层 API 直连到最终用户可见的声明式接口：
| 层级 | 名称 | 职责 | 示例 |
|---|---|---|---|
| L1 | Provider | 封装云服务商 API，提供资源类型定义（CRD）和控制器 | provider-aws、provider-gcp |
| L2 | Managed Resource (MR) | 单个云资源的直接表示，由 Provider 控制器管理 | RDSInstance、Bucket |
| L3 | Composite Resource (XR) | 由多个 MR 组合而成的逻辑资源单元，定义编排模板 | XPostgreSQL、XK8sCluster |
| L4 | Claim (XRC) | 面向应用团队的声明式请求，自动触发 XR 实例化 | PostgreSQLClaim、K8sClusterClaim |
关键理解： Provider 是“驱动”，MR 是“单点资源”，XR 是“组合模板”，Claim 是“用户订单”。水位预测主要作用于 MR 和 XR 层，但 Claim 的请求模式决定了突增的触发源。
2.2 资源创建与依赖链路
当用户提交一个 Claim 时，Crossplane 内部按以下顺序执行资源编排：
- Claim 提交 → 用户创建
PostgreSQLClaim对象。 - Composite 控制器匹配 → 根据 Claim 的
compositeResourceRef找到对应的 CompositeResource（XR）定义。 - XR 实例化 → 创建 XR 实例，并注入 Claim 中声明的参数（如存储大小、区域）。
- Composition 模板展开 → XR 控制器根据 Composition 定义，生成一组 Managed Resource（MR）。
- Provider 控制器执行 → 每个 MR 由对应的 Provider 控制器调用云 API 创建实际资源。
- 状态回填 → MR 状态 → XR 状态 → Claim 状态，最终用户看到 Ready 状态。
水位预测关注点： 步骤 4 和 5 是容量消耗的“放大环节”。一个 XR 可能展开为 3~10 个 MR，突增时 MR 数量会成倍增长，导致 Provider 的 API 调用并发和云资源配额同时承压。
2.3 四层关系 SVG 架构图
下图展示了从 Claim 到 Provider 的完整资源抽象链路，以及各层之间的引用关系：
2.4 关键差异对比
理解这四个概念之间的本质区别，有助于在容量预测时准确判断瓶颈所在：
| 对比维度 | Provider | Managed Resource | Composite Resource | Claim |
|---|---|---|---|---|
| 生命周期 | 集群级，常驻 | 随资源创建/删除 | 随组合实例创建/删除 | 随用户请求创建/删除 |
| 数量级 | 个位数 | 数百~数千 | 数十~数百 | 与 XR 1:1 对应 |
| 容量影响 | API 限速、配额 | 云资源配额、成本 | 组合展开的 MR 数量 | 突增请求速率 |
| 水位预测目标 | Provider 调用并发 | 资源使用率、配额 | 组合模板复杂度 | 请求到达率 |
2.5 实际场景中的协作示例
以一个典型的“创建 PostgreSQL 实例”流程为例，展示四层如何协作：
# 1. 用户提交 Claim
apiVersion: database.example.org/v1alpha1
kind: PostgreSQLClaim
metadata:
name: my-db-claim
spec:
storageGB: 100
region: us-east-1
# 2. Crossplane 自动创建 XR
apiVersion: database.example.org/v1alpha1
kind: XPostgreSQL
metadata:
name: my-db-claim-xr
spec:
storageGB: 100
region: us-east-1
# 3. Composition 展开为 3 个 MR
# MR1: RDSInstance
# MR2: SecurityGroup
# MR3: SubnetGroup
# 4. Provider 控制器分别处理每个 MR
# provider-aws 调用 RDS API 创建实例
# provider-aws 调用 EC2 API 创建安全组
# provider-aws 调用 VPC API 创建子网组
容量突增风险点： 当大量 Claim 同时提交时，步骤 3 的 Composition 展开会瞬间生成 3 倍于 Claim 数量的 MR。如果每个 XR 展开 5 个 MR，100 个并发 Claim 就会产生 500 个 MR 同时进入 Provider 控制器队列，极易触发云 API 限流和资源配额错误。
2.6 水位预测的抽象层级定位
基于上述关系，本课程的水位预测模型将聚焦于以下三个关键层级：
- Claim 层： 监控请求到达率、突增模式、历史周期特征，作为预测的输入信号。
- XR 层： 跟踪 Composition 展开系数（每个 XR 产生的 MR 数量），评估模板复杂度对容量的放大效应。
- MR 层： 统计实际资源消耗、配额使用率、创建/删除速率，作为预测的输出验证和告警阈值。
Provider 层作为底层约束条件，不直接参与预测模型，但会在容量规划时作为硬性上限（如 AWS API 每秒请求数限制）参与计算。