平台成熟度与 IDP 的组成要素
一句话总结
内部开发者平台（IDP）不是一个 portal，而是**五个平面（plane）**的集合。成熟度的提升也不取决于工具数量，而取决于“谁以何种方式作出决定，又用什么来衡量”。
为什么需要了解这一点
一旦有人提出“引入 IDP”，通常会从挑选 portal 产品的会议开始。但 portal 只是 IDP 的表面。如果下面没有真正创建和运行事物的层，portal 就会变成链接集合。必须先画出需要哪些组成部分，才能看出缺少什么。
工作原理
IDP 的五个平面
把 CNCF 平台白皮书中的分类转换成实际工作用语后，如下所示。
| 平面 | 职责 | 常见实现 |
|---|---|---|
| Developer Control Plane | 开发人员接触的表面 | portal（Backstage）、CLI、repository template、manifest abstraction |
| Integration & Delivery | 构建并部署 | CI、image registry、GitOps agent、secret operator |
| Monitoring & Logging | 查看发生了什么 | metric、log、trace、dashboard、alert |
| Security | 身份与策略 | 认证与授权、policy engine、image signature 与 scan |
| Resource Plane | 实际资源 | cluster、node、network、storage、database |
还有两个维度横贯其中：API 与接口（如何调用各平面）以及能力提供（capabilities）。考试如果问“portal 本身就是 IDP 吗？”，答案是否定的；portal 只是 Developer Control Plane 的一种实现。
成熟度阶段
与数字相比，记住各阶段的症状更有利于解题。
- 临时（Provisional）——每个团队各用自己的脚本。启动一个新服务需要数天，知识只存在于人的脑中。
- 运营（Operational）——开始有公共脚本和文档。平台团队仍然接收 ticket 并代为操作，瓶颈在人。
- 可扩展（Scalable）——实现 self-service。开发人员无需 ticket 即可自行 provisioning。平台团队不再处理请求，而是开发功能。
- 优化（Optimizing）——依据使用数据和用户反馈改进平台本身，有计划地执行废弃与迁移。
区分阶段的真正标准是**“是否需要 ticket”**。第 2 阶段与第 3 阶段之间存在一道悬崖，大多数组织都停在这里。即使已经自动化，如果只有平台团队能按下执行按钮，就仍然是第 2 阶段。
Self-service 成立的条件
Self-service 不只是“授予权限”，还需要同时具备三项条件。
- 安全默认值——即使什么都不指定，也会应用资源限制、security context 和 observability。
- 边界——无法触碰他人的 namespace，也无法破坏整个 cluster。
- 快速反馈——写错后立即以人类可读的语言被拒绝。如果 30 分钟后才通过 900 行 pipeline log 告知，就不算 self-service。
第三点尤其重要。在 Kubernetes 中，这就是schema validation。如果在 CRD 的 OpenAPI schema 中加入 maximum: 10，API server 会立即拒绝。policy engine 的 webhook 也承担相同职责。
实际工作中的表现
作者正在 home lab 上构建的，正是迈向第 3 阶段的尝试——“学习者按下按钮，练习 Pod 随即启动，接受评分，结束后消失的系统”。这里直接体现了平台视角的要求：练习 Pod 不能看到他人的 Pod（边界），不能无限使用资源（guardrail），无需任何设置就应包含所需工具（安全默认值），结束后还应自行消失（生命周期）。
而底层 cluster 已经存在这些限制。虽然三台 control plane 已经形成 etcd quorum，但 controlPlaneEndpoint 固定为第一台 node 的物理 IP，该 node 一旦故障，API 访问便会中断。GPU 分别有 24GB、32GB 和两张 8GB，等级各不相同；如果只请求 nvidia.com/gpu: 1，可能会调度到不合适的卡上。因此，必须由人定义并添加 gpu.homelab/tier 这类基于含义的 label。
这正是平台 API 设计的起点。不直接暴露物理事实（GPU 型号），而是将其翻译成开发人员能够理解的词汇（tier=xlarge）——这就是 abstraction，也是下一模块的主题。
下个测验将检查什么
下一模块会通过 CRD 亲自创建名为 WebService 的平台 API。使用 schema 立即拒绝错误值，由服务器填充默认值，通过 namespace、ResourceQuota、LimitRange 划分 tenant 边界，再通过 RBAC 授予 self-service 权限，并在真实 cluster 中完成这一整套配置。