第 1 章 了解 API 层
这个指南不包括 MicroShift 产品分层的红帽构建。
红帽要求应用程序开发人员验证他们所依赖的所有行为是否在正式的 API 文档中明确定义，以防止引入特定实施特定行为或对 API 特定实施错误的依赖项。例如，如果应用程序使用未文档化的 API 或依赖于未定义行为，则入口路由器的新版本可能无法与旧的版本兼容。
1.1. API 层
所有商业支持的 API、组件和功能都与以下支持级别之一相关联：
API 层 1
API 和应用程序操作环境(AOE)在主发行版本中保持稳定。它们在主版本中可能被弃用，但在后续的主发行版本前不会删除它们。
API 层 2
API 和 AOEs 在主发行版本中至少为 9 个月或 3 个次版本的发布周期（以更长的时间为准）。
API 层 3
此级别适用于红帽通过 Operator Hub 构建 MicroShift 中的语言、工具、应用程序和可选 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。
