红帽全球峰会Red Hat OpenShift 软件认证政策指南
用于 Red Hat OpenShift
摘要
使开源包含更多
红帽承诺替换我们的代码和文档中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于这一努力的精力，这些更改将在即将发布的版本中逐渐实施。有关让我们的语言更加包含的更多详情，请参阅我们的CTO Chris Wright 信息。
第 1 章 Red Hat OpenShift 认证策略简介
Red Hat Openshift 认证政策指南涵盖了在 Red Hat OpenShift 上获取和维护红帽软件产品的技术和操作认证要求。
要了解实现此认证的测试要求和程序，请参阅红帽 软件认证工作流指南。
1.1. 受众
Red Hat OpenShift 认证为提供以 Red Hat OpenShift 作为部署平台为目标的云原生软件产品的商业软件厂商提供。
1.2. 为客户创造价值
认证流程允许合作伙伴不断验证其产品是否满足红帽在 Red Hat OpenShift 上部署时的互操作性、安全性和生命周期管理标准。
我们的客户从受信任的应用程序和基础架构堆栈中受益，由红帽和合作伙伴共同测试并共同支持。
1.3. 认证和合作伙伴验证
红帽为您提供以合作伙伴验证或红帽认证的方式推广您的产品的能力。
合作伙伴验证是根据您自己的测试标准和支持政策确认您的决定支持红帽平台的第一个步骤。但是，根据定义，经过验证的工作负载不包括红帽认证的完整彻底性。我们鼓励您继续通过认证来继续使用红帽的建议和最佳实践。
红帽认证的产品经过全面测试，与您的合作支持。这些产品符合您的标准和红帽标准，包括功能、互操作性、生命周期管理、安全性和支持要求。
CNI 和 CSI 基础架构软件不提供验证选项。
合作伙伴了解合作伙伴验证和红帽认证之间的区别至关重要。在 Validation 和 Certification 程序之间找到明确的区别：
| 功能 | 合作伙伴验证 | Red Hat Certification |
| 测试标准 | 由合作伙伴决定 | 由红帽和合作伙伴决定 |
| 测试工具 | 由合作伙伴提供 | 由红帽和合作伙伴提供 |
| Red Hat Review | 合作伙伴声明、支持文档和测试结果 | 测试结果、合作伙伴声明和文档 |
| 影响范围 | 更快的市场条目，红帽生态系统目录初始存在 | 全面遵守红帽平台要求，最佳实践，如互操作性、安全性和支持 |
1.4. 支持职责
使用来自我们强大的认证企业硬件、软件和云合作伙伴的组件时，红帽客户可以获得最佳的支持体验。https://catalog.redhat.com/
红帽根据 Red Hat 服务等级协议(SLA)提供对红帽认证的产品和红帽软件的支持。如果客户涉及经过认证的第三方组件，红帽就与您合作，根据第三方支持政策 进行解决。https://access.redhat.com/articles/6022331
红帽不会解释客户支持政策。但是，我们需要您的支持来协助客户诊断和解决与软件的功能、互操作性、生命周期管理和安全性相关的问题。
在 Red Hat Ecosystem Catalog 中被列为认证，代表您在支持您的产品，并为我们共同的客户提供可靠的解决方案，遵循您的红帽产品。
1.5. 用于认证的目标产品
认证适用于以 Red Hat OpenShift 作为其部署平台为目标的工作负载产品。红帽建议您使用 Kubernetes 技术（如 Operator 或 Helm chart）来管理产品的生命周期，因为它们提供与 Red Hat OpenShift 紧密集成的用户体验。对于这两个选项，认证涵盖了与 Red Hat OpenShift 工具的打包格式和兼容性。如果您的产品使用不同的技术来安装和升级，则认证将限制为容器镜像。
专门认证适用于电信市场的云原生网络功能。
1.6. 先决条件
- 加入 Red Hat Partner Connect 计划。
- 接受标准合作伙伴协议以及特定于容器化软件的条款和条件。
- 输入有关您的公司和您要通过 Red Hat Partner Connect 门户认证的产品的基本信息。
- 测试您的产品，以验证其行为是否与 OpenShift 中的行为相同。
- 支持 OpenShift 作为认证产品的平台，并与红帽建立支持关系。您可以通过 TSANet 的多供应商支持网络或通过自定义支持协议来实现此目的。
1.7. 支持的 Red Hat OpenShift 版本
Red Hat OpenShift 软件认证适用于处于完全支持阶段、维护或延长更新支持(EUS)生命周期阶段的 Red Hat OpenShift v4.x 版本。
1.8. 支持的构架
认证适用于所有 Red Hat OpenShift Container Platform v4.x 版本支持的架构。目前，这包括 x86_64、s390x、ppc64 和 aarch64。
认证适用于单个架构。如果您的产品支持多个架构，则申请多个认证。
1.9. 生命周期
Red Hat 认证和验证在 12 个月内有效，或直到相应的 Red Hat OpenShift Container Platform (RHOCP) v.4.x 版本退出了 Extended Update Support Term 2 of the RHOCP 生命周期，以延长的时间较短。要保持认证或合作伙伴验证状态，您必须在较新版本的软件或 Red Hat OpenStack Platform (RHOSP)上认证或重新验证。认证、验证和相关产品在不再有效或红帽产品从目录中停用前仍然有效。
OpenShift 现在包括 延长更新支持(EUS) 和 扩展更新支持条款 2 (EUS-T2) 选项，需要更改产品构建和发行实践以及 ISV 认证。
认证或验证的窗口会根据 even 和 odd 计划在次版本的 GA 发行版本中打开。
- 偶数的次发行版本 ：该窗口将在延长更新支持或延长更新支持条款 2 结束时关闭，以较晚者为准。
- 奇数的次发行版本：该窗口与前一个偶数 的发行版本同时关闭（例如，4.15 将在延长更新支持 Term 2 的末尾与 4.14 接近）。这是因为偶数的发行版本有较长的支持生命周期。虽然一个奇数的发行版本会马上结束其生命周期，但它会在扩展更新支持阶段偶数的版本之间更新期间相关，以作为中间步骤。为这些生命期生命版本认证软件可确保提供关键错误修复和安全更新，从而防止客户更新期间出现回归问题。
ISV 认证工具和产品构建或发行版本工程将支持奇数次版本，超过生命周期页面所示的次版本。
支持 EUS 到 EUS 更新对于无缝的客户体验至关重要。例如，如果您在 RHOCP 4.14 上认证了 ISV 软件版本 1，且版本 3 为 RHOCP 4.16，则 4.14 上的双认证可能很有用。如果软件支持从版本 1 直接升级到 3 版本，且版本 3 与 RHOCP 4.14 兼容，这一点尤其重要。在这种情况下，在 RHOCP 4.14 上认证版本 3 可让客户在 RHOCP 4.14 上升级其软件，然后再过渡到 4.16，确保更平稳的流程并最大程度减少中断。
如需了解更多详细信息，请参阅 Red Hat OpenShift Container Platform 生命周期政策。
红帽建议您在为 OpenShift 版本提供"维护支持终止终止"的偶数更新计划。但是，此扩展产品支持为任何必要的更新路径提供灵活性，例如从 OpenShift 4.14 升级到 4.15，以确保对我们共同的客户的支持不间断。
1.9.1. 重新认证
Red Hat OpenShift Container Platform 以快速的速度进行创新，如 Red Hat OpenShift Container Platform 生命周期政策中所反映。将 OpenShift 和认证测试作为持续流程处理非常重要，以确保为客户提供持续的互操作性和支持。
您必须在以下情况下重新认证您的产品：
- 认证产品的另一个版本
- 通过红帽 in-product 软件目录(index/registry/repo/etc.)提供产品的另一个版本。
- 支持 Red Hat OpenShift Container Platform (RHOCP)的另一个版本或架构
- 对产品的构建、安装、升级过程或添加新功能进行材料更改
- 我们的产品包含一个关键通用漏洞和公开(CVE)，它比 3 个月旧的
- 我们的产品包含一个重要的 CVE，它比 12 个月旧的
- 您的产品已认证于 12 个月前
材料的变化是指改变认证测试结果的任何更改，影响您对 OpenShift 的客户体验，影响客户对 OpenShift 的经验，或影响客户利用其红帽订阅的任何部分的能力。
红帽提供了多种监控已认证容器以了解关键漏洞(CVE) 的机制。这可让您持续监控并识别关键漏洞。这些机制将帮助您确定何时重建并重新认证。
1.9.2. 其他验证
Red Hat OpenShift Container Platform 以快速的速度进行创新，如 Red Hat OpenShift Container Platform 生命周期政策中所反映。将 OpenShift 和认证测试作为持续流程处理非常重要，以确保为客户提供持续的互操作性和支持。
在以下情况下，您需要对产品进行额外的验证：
- 验证产品的另一个版本
- 支持 Red Hat OpenShift Container Platform 的另一个版本或架构
- 对您的产品进行材料更改
- 在 12 个月前，您的产品已验证了超过 12 个月
材料的变化是指改变认证测试结果的任何更改，影响您对 OpenShift 的客户体验，影响客户对 OpenShift 的经验，或影响客户利用其红帽订阅的任何部分的能力。
1.10. 产品命名和品牌
选择符合 红帽商标准则 的独特产品名称和品牌。这有助于我们共同的客户明确识别使用 Red Hat Marks 及其源的产品。此策略涵盖了所有目录列表和单个产品组件。
1.11. 软件依赖项
红帽认证的主要优点是支持。确保检查您是否与红帽协调，支持客户在 RHOCP 上部署和使用您的软件所需的所有软件。
1.12. 功能验证
您必须确保您的产品与您提交过的相同软件包和组件与 RHOCP 支持的配置一起工作。
请确保您的产品不会对 RHOCP 堆栈进行任何修改，包括主机操作系统，但产品文档中介绍的配置更改除外。未授权的更改可能会影响红帽支持。
红帽建议您检查您的产品是否在 OpenShift 集群的任意节点上运行，无论 Red Hat OpenShift 部署类型（裸机、虚拟环境或云服务）、安装过程(IPI 或 UPI)或集群大小。如果由于硬件组件、公共云服务或任何其他集群配置要求而存在任何限制，则应该在产品文档中提及这些限制，它们应与您的产品 目录列表 相关联。
1.13. 安全上下文
要降低安全风险，请确保您的产品在最严格的安全上下文约束(SCC)中运行。例如，Red Hat OpenShift 4.12 的 restricted-v2。如果产品需要额外的特权，红帽建议使用提供正确功能的最严格的 SCC。此配置信息应当包含在产品文档中，并且必须使用为最终用户推荐的相同安全设置进行认证测试。
1.14. 发布
1.14.1. 红帽生态系统目录
完成 Red Hat Enterprise Linux (RHEL)认证工作流后，红帽会在 红帽生态系统目录 中发布一个条目。这包括过程中收集的产品条目和相关信息。
具有认证的产品包括容器、Helm chart 和操作器的相关组件数据。没有任何认证的产品不包括组件信息。
1.14.2. Red Hat in-product 目录
红帽产品包括在产品目录中供客户直接使用。用户可通过红帽产品中的相应界面安装、运行和管理红帽认证的软件。例如，ISV 容器注册表、图表存储库和运算符索引。
另外，由 Operator 或 Helm chart 管理的产品也包含在相应的 Red Hat Certified Operator Index 或 OpenShift Helm Charts 仓库 中，以默认协助安装和升级。这两个用户都会通过 OpenShift 控制台向 Red Hat OpenShift 用户显示。
如果认证 Operator Index 或 Helm Charts 仓库与软件分发模型不兼容，您可以选择不使用 Red Hat Certified Operator Index 或 Helm Charts 仓库发布。您负责测试必须包含在产品文档中的备用发行版和更新流程。
同样，如果红帽与软件分发模型不兼容，您可以选择不使用在红帽中的产品目录中发布。您负责测试必须包含在产品文档中的备用发行版和更新流程。
第 2 章 容器镜像的要求
认证的容器镜像必须满足以下要求，以确保：
- 操作系统库作为最终用户 Red Hat OpenShift 支持订阅的一部分进行介绍。
- 镜像被扫描以避免在客户环境中引入已知的安全漏洞。
2.1. 镜像内容要求
| 要求 | 原因 |
|---|---|
| 容器镜像必须声明非 root 用户，除非其功能需要特权访问权限。 要认证需要 root 访问权限的容器镜像，您必须：
测试名称：Run AsNonRoot | 确保容器不以 root 用户身份运行，除非需要。以 root 用户身份运行的镜像可能会带来安全风险。 |
| 容器镜像必须使用红帽提供的 通用基础镜像(UBI)。 除了内核软件包外，您可以在 UBI 镜像中添加额外的 RHEL 软件包。 测试名称： BasedOnUbi | 确保应用程序运行时依赖项（如操作系统组件和库）包含在客户的订阅下。 |
| 容器镜像不能更改红帽软件包或层提供的内容，但您或客户都可以更改的文件，如配置文件。 测试名称： HasModifiedFiles | 确保红帽不会根据红帽组件未经授权更改拒绝支持。 |
|
容器镜像必须具有 测试名称： HasLicense | 确保客户了解适用于镜像中包含的软件的条款和条件。 |
| 未压缩的容器镜像必须小于 40 个层。 测试名称： LayerCountAcceptable | 确保镜像在容器上正确运行。过多的层可能会降低性能。 |
| 容器镜像不得包含 RHEL 内核软件包。 测试名称： HasNoProhibitedPackages | 确保符合 RHEL 为合作伙伴发布规则。 |
| 容器镜像不得包含带有确定 重要或关键漏洞的红帽 组件。 测试名称： N/A.红帽认证服务进行此扫描。 | 确保客户不会暴露于已知的漏洞。 |
| 容器镜像名称不得以任何红帽商标开头。 测试名称： HasProhibitedContainerName | 确保遵守 红帽商标准则。 |
2.2. 镜像元数据要求
| 要求 | 原因 |
|---|---|
| 容器镜像必须包括以下标签：
测试名称： HasRequiredLabel |
确保客户能够以一致的方式获取有关镜像供应商和镜像内容的信息。 |
| 容器镜像标签内容不得以任何 Red Hat Marks 开头：
测试名称： HasNoProhibitedLabels | 镜像名称必须遵循 红帽商标准则。 |
| 容器镜像必须包含认证镜像描述性的唯一标签。 红帽建议将镜像版本及其构建日期附加到唯一标签中。 除了描述性标签外，除了描述性标签外，还可以将浮动标签（如 latest ）添加到镜像中。 测试名称： HasUniqueTag | 确保镜像可以被唯一标识。 |
2.3. 镜像维护要求
合作伙伴负责监控其认证容器的健康状况。当镜像因为新功能或安全更新需要重建时，请提交更新的容器镜像以进行重新认证和发布。
合作伙伴必须保持应用程序组件最新状态，并定期重建其容器镜像。
第 3 章 由 Operator 管理的产品
Operator 必须能够使用目标 Red Hat OpenShift 版本中的 Operator Lifecycle Manager (OLM)在 Red Hat OpenShift 上部署您的软件产品。
如果有任何特定的硬件要求是运行认证 Operator 所必需的，红帽建议通过列出产品系统要求页面中的所有要求，并将其链接到红帽生态系统目录 上的产品页面，以告知您的客户。
3.1. Operator 要求
版本范围可以包括将来的 Red Hat OpenShift Container Platform 版本(RHOCP)。因此，只有不需要重新认证的 Operator 才会被列为认证，并在后续的 RHOCP 版本可用时包含在 Red Hat Certified Operator Index 中。
| 要求 | 原因 |
|---|---|
| Operator 捆绑包必须成功通过 Operator SDK 捆绑包验证。 红帽建议使用 SDK 来创建 Operator，以确保格式正确。 | 确保格式正确，并与 Operator Lifecycle Manager (OLM)兼容。 |
| Operator 必须更新每个自定义资源(CR)的 status 字段。 | 为确保用户可以确定 CR 的运行状态，并确定潜在的故障。 |
|
Operator 捆绑包中的集群服务版本(CSV)必须包含 Required CSV 字段中指示的所有字段，以及
也可以定义其他可选注解，如以下 Kubernetes 插件：
如需有关 CSV 中所需注解、可选注解和示例用法的更多信息，请参阅 Operator 元数据注解。 | 提供有关此 Operator 向用户和支持组织管理的产品的详细信息。 |
|
Operator 捆绑包必须通过设置 注解语法： a）Restrict to a single RHOCP version: "=v4.17" b）Restrict to a version range: "v4.16-v4.17" c）开放式版本范围："v4.16" 如果列出的开放版本范围已弃用，Operator 捆绑包将只出现在完全支持和维护的版本中。 版本范围必须包括一个或多个当前 RHOCP 版本，它们处于 完全 Suport、维护支持、EUS 或 EUS Term2 生命周期阶段。 范围可以直接或隐式包括一个或多个 RHOCP 版本。在新的 RHOCP 次版本发布后，带有范围（包括新的次版本）的 Operator 将自动认证并发布新的 RHOCP 次要版本。 | 红帽期望，要求您在新的 Red Hat OpenShift 次要发行本中测试和验证您的产品。 |
| Operator 不能使用包括在这个范围内的所有 Red Hat OpenShift 版本中存在的 API。 | 确保使用的任何 API 在目标版本中都可用。 |
| Operator 捆绑包中的 CSV 必须指明 Operator 拥有的所有 CRD。 | 确保正确跟踪和管理 CRD 生命周期。 |
|
Operator 捆绑包中的 CSV 必须使用 | 正确识别所有依赖项。 |
| Operator 名称必须与社区、认证和红帽目录中已发布的任何其他 Operator 名称不同。Operator 名称不能以 Red Hat Mark 开头。 | 为避免名称冲突，客户混淆并遵循 红帽商标准则。 |
3.2. 操作对象要求
由 Operator (Operands)管理的每个容器都必须通过红帽认证，且必须满足 容器镜像要求 部分中列出的要求。
第 4 章 由 Helm chart 管理的产品
Helm Chart 必须能够使用平台提供的 Helm 实用程序在 Red Hat OpenShift 上部署您的产品。有关在 Red Hat OpenShift 上使用 Helm chart 的更多信息，请参阅使用 Helm chart。
要被认证，Helm Chart 必须满足以下要求。
| 要求 | 原因 |
|---|---|
| Helm Chart 使用的所有容器都必须是红帽认证的容器。 | 认证容器镜像中的操作系统库由 Red Hat OpenShift 支持涵盖，并持续监控安全漏洞。如需有关容器认证要求的更多信息，请参阅 容器镜像的要求。有关认证容器的步骤的更多信息，请参阅使用容器。 |
| chart 的 apiVersion 字段必须是 v2.0。 | Chart 必须与 Helm 3 （如 apiVersion v2）兼容，OpenShift 支持的 Helm 版本。 |
| Chart 必须包含 README.md 文件。 | 以人类可读的格式提供有关 Chart 的基本信息。 |
| Chart 必须设置 kubeVersion 字段，以指示支持的最低 Kubernetes 版本。 | 要确定与特定版本的 OpenShift 的 Chart 兼容性。如需有关 OpenShift 中使用的 Kubernetes 版本的信息，请参阅 每个 OpenShift 4.x 发行版本中包含哪些 Kubernetes API 版本？ |
| Chart 必须包含位于 templates 目录中的一个或多个 测试。 | 验证 chart 安装是否成功。 |
|
Chart 必须包含 | 识别 Chart 输入并提供正确的验证。 |
| Chart 不得包含任何自定义资源定义(CRD)。 | 需要正确管理自定义资源定义(CRD)的生命周期。红帽建议使用一个 Operator 来执行此任务。如需有关 Operator 的更多信息，请参阅使用 Operator。 |
| Chart 必须通过 helm lint 命令。 | 确保正确 chart 格式。 |
|
Chart 必须包含带有人类可读名称的 | 提供在 OpenShift 控制台中显示 chart 时可以使用的名称。此名称必须遵循 红帽商标准则和政策。 |
第 5 章 OpenShift badge 的功能认证
认证徽标将 Red Hat OpenShift 认证扩展到特定的功能区域或基础架构服务。一个徽标表示经过认证的产品提供由红帽验证的功能，如符合 Kubernetes Container Storage Interface (CSI)或 Container Network Interface (CNI) API。
如果您的产品提供本节中描述的任何功能，红帽建议您进行其他测试。这有助于您在 红帽生态系统目录 上相应地识别您的产品。
5.1. Container Network Interface (CNI)
CNI badge 是 Red Hat OpenShift 认证中的分类。它可用于使用 CNI 插件与 OpenShift 集成的网络产品。
5.1.1. 插件要求
插件必须符合 CNI 规格版本 0.3.1 或更高版本。
您必须通过满足本文档中描述的 Operator 认证要求的 Operator 管理 CNI 插件。要管理 CNI 插件的更新，Operator 必须具有 Seam 无升级功能，并在 CSV 中反映这一点。
5.1.2. OpenShift 互操作性要求
除了 功能验证 的默认要求外，您用来验证 CNI 功能的 OpenShift 集群还必须在所有测试过程中启用 Multus CNI 插件。在主机上安装的所有组件都必须在 Red Hat Enterprise Linux 和 Red Hat Enterprise Linux CoreOS 版本上经过测试和支持。
CNI 插件必须支持 OpenShift Virtualization。组合使用插件或 OpenShift Virtualization 的任何不支持或降级功能都必须在产品文档中指示。
作为 CNI 认证徽标的一部分，可以验证 CNI 插件以便与 Red Hat OpenShift Service Mesh 兼容。
5.1.3. CNI 生命周期管理要求
该插件必须确保对主版本或次插件发行版本的升级的影响最小。插件升级应该不需要完全重新引导节点（无论是主节点还是次要），且必须在集群安装过程中保留现有连接。
该插件必须在升级过程中允许新的连接。如果无法提供新的或现有连接保留，则必须记录它以及详细的升级步骤，例如，如果集群排空或节点 cordoning/drain 是必需的。
插件文档必须显示次版本、错误修复或主要更新之间的升级流程的差别。
认证是针对 OpenShift 次版本的测试。合作伙伴需要在新的次版本中更新其产品。
5.1.4. CNI 测试合规性
该插件必须传递 OpenShift End-to-End Tests 的网络测试，它基于 Kubernetes 端到端测试。这些测试会练习插件的基本功能，并符合 Kubernetes 网络预期。
必须完成对应的虚拟化测试，以验证 CNI 插件和 Red Hat OpenShift Virtualization 之间的互操作性。
如果要检查 CNI 插件和 Red Hat OpenShift Service Mesh 之间的互操作性，请完成对应的服务网格测试作为认证的一部分。运行服务网格测试是可选的。
5.2. 容器存储接口(CSI)
CSI badge 是 Red Hat OpenShift 认证中的分类。它可用于使用 CSI 驱动程序与 OpenShift 集成的存储产品。
5.2.1. 驱动程序要求
CSI 驱动程序必须实现 CSI 规范的 版本 1.0 或更高版本。CSI 驱动程序必须实现创建和删除卷功能。所有其他功能都是可选的，但如果实现和支持，则必须通过清单文件查看(示例清单文件)进行声明，以便可以测试它们。
5.2.2. Operator 和 sidecar 要求
必须通过满足本文档中介绍的 Operator 认证要求的 Operator 部署和管理 CSI 驱动程序。使用认证操作对象（容器）的要求也适用于驱动程序的 sidecar 镜像。您应该构建和维护其 sidecar 镜像，以便它们可以满足此条件。您可以选择由红帽发布和维护的 sidecar 镜像，作为 OpenShift 的一部分提供。如果您这样做，请验证 CSI 驱动程序与 sidecar 的互操作性，并在可用时测试并纳入 sidecar 更新。
5.2.3. OpenShift 互操作性要求
在主机上安装的所有组件都必须在 Red Hat Enterprise Linux 和 Red Hat CoreOS 版本上经过测试和支持，供 OpenShift 发行版本用于认证。
CSI 驱动程序应该支持 OpenShift Virtualization 存储功能列表中列出 的存储功能，因此用户可以充分利用虚拟机的平台服务。CSI 产品文档必须指明驱动程序是否不支持这些功能。
5.2.4. CSI 生命周期管理要求
在升级过程中，Container Storage Interface (CSI)驱动程序必须在没有数据丢失的情况下管理卷，继续以幂等方式处理请求，保持正确的放置，并报告状态以确保可靠的存储。
驱动程序必须确保对主版本或次版本的升级的影响最小。驱动程序升级应该不需要完全重启节点，无论是主还是次，且必须在集群安装过程中保留现有卷挂载。
驱动程序必须在升级过程中允许卷操作。如果无法执行新卷操作或现有卷挂载保留，则必须记录此信息以及详细的升级步骤，例如，如果需要完整集群排空或节点 cordoning/drain。
驱动程序文档必须显示次版本、错误修复或主要更新之间的升级过程差异。
认证是针对 OpenShift 次版本的测试。合作伙伴需要在新的次版本中更新其产品。
5.2.5. CSI 测试合规性
该插件必须根据 Kubernetes 结束测试完成 OpenShift 端到端测试的 CSI 测试。
对支持的每个存储协议（如 iSCSI、NFS、FC）执行测试，且必须与声明的功能匹配。
第 6 章 合作伙伴文档要求
合作伙伴为客户提供的产品文档必须：
- 包含有关如何使用认证的 Operator 或 Helm Chart 在 OpenShift 中安装和更新您的产品的说明。
- 将 OpenShift 列为支持的平台。
在产品列表信息（在认证过程中提供）中为您的产品文档添加链接。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}