第 1 章 了解 API 层
这个指南不包括层次的 OpenShift Container Platform 产品。
对于与硬件交互的任何功能外，裸机配置的 API 层也适用于虚拟化配置。与硬件直接相关的这些功能没有应用程序操作环境(AOE)兼容性级别，但由硬件供应商提供。例如，依赖图形处理单元(GPU)功能的应用程序会受到 GPU 供应商驱动程序提供的 AOE 兼容性。
适用于云特定集成点的云环境中的 API 层没有 API 或 AOE 兼容性级别，而不受托管云供应商提供的。例如，用于进行计算、入口或存储动态管理的 API 依赖于云平台提供的底层 API 功能。如果云供应商修改先决条件 API，红帽会提供合理的努力来维护对 API 的支持，同时具备云基础架构供应商所提供的功能。
红帽要求应用程序开发人员验证他们所依赖的所有行为是否在正式的 API 文档中明确定义，以防止引入特定实施特定行为或对 API 特定实施错误的依赖项。例如，如果应用程序使用未文档化的 API 或依赖于未定义行为，则入口路由器的新版本可能无法与旧的版本兼容。
1.1. API 层
所有商业支持的 API、组件和功能都与以下支持级别之一相关联：
API 层 1
API 和应用程序操作环境(AOE)在主发行版本中保持稳定。它们在主版本中可能被弃用，但在后续的主发行版本前不会删除它们。
API 层 2
API 和 AOEs 在主发行版本中至少为 9 个月或 3 个次版本的发布周期（以更长的时间为准）。
API 层 3
此级别适用于 OpenShift Container Platform 通过 Operator Hub 附带的语言、工具、应用程序和可选 Operator。每个组件都将指定一个生命周期，在其中支持 API 和 AOE。较新的语言运行时组件版本将尽量作为 API 和 AOE 兼容次版本。但是，无法保证次版本的兼容性。
通过 Operator Hub 接收持续更新的组件和开发人员工具（称为 Operator 和操作对象）应该被视为 API 层 3。开发人员应谨慎使用，并了解这些组件如何在每个次发行版本中改变。我们鼓励用户参考组件所记录的兼容性指南。
API 层 4
不提供兼容性。API 和 AOE 可在任何时候更改。这些功能不应由需要长期支持的应用程序使用。
Operator 在内部使用自定义资源定义 (CRD) 来完成任务是常见的。这些对象并应由 Operator 外部执行者使用，它旨在隐藏。如果任何 CRD 没有被 Operator 外部执行者使用，则 Operator ClusterServiceVersion (CSV)中的 operators.operatorframework.io/internal-objects 注解应指定给对应资源使用范围，并且 CRD 可能会明确标记为层 4。
