第 5 章 OpenShift badges 的功能认证
认证徽标将 Red Hat OpenShift 认证扩展到特定的功能区域或基础架构服务。徽标表示经过认证的产品提供由红帽验证的功能，如与 Kubernetes Container Storage Interface (CSI)或 Container Network Interface (CNI) API 保持一致。
如果您的产品提供了本节中描述的任何功能，红帽建议您进行其他测试。这有助于您在 红帽生态系统目录 上相应地识别您的产品。
5.1. Container Network Interface (CNI)
CNI 徽标是 Red Hat OpenShift 认证中的分类。它可用于使用 CNI 插件与 OpenShift 集成的网络产品。
5.1.1. 插件要求
插件必须符合 CNI 规格版本 0.3.1 或更高版本。
您必须通过满足本文档中描述的 Operator 认证要求的 Operator 管理 CNI 插件。要管理 CNI 插件的更新，Operator 必须具有 Seamless Upgrades 功能，并在 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. 生命周期管理要求
该插件必须确保对主版本或次版本的升级的影响最小。插件升级不需要完全节点重新引导（无论是主节点还是次要），且必须在集群升级过程中保留现有连接。
该插件必须在升级过程中允许新的连接。如果无法进行新的或现有连接保留，则必须记录详细的升级步骤。例如，如果需要完整集群排空或节点 cordoning/drain。
插件文档必须在次发行版本、错误修复或主要更新之间显示升级流程的区别。
认证特定于已测试的 OpenShift 次版本。合作伙伴需要在新的次版本中重新认证其产品。
5.1.4. CNI 测试合规性
该插件必须根据 Kubernetes End-to-End Tests 传递 OpenShift End-to-End Tests 的网络测试。这些测试会操作插件的基本功能，并显示符合 Kubernetes 网络预期。
该插件必须完成对应的虚拟化测试，以验证 CNI 插件和 OpenShift Virtualization 之间的互操作性。如果 CNI 插件和 Red Hat OpenShift Service Mesh 之间的互操作性被视为认证的一部分，则插件必须完成对应的服务网格测试。
其他资源
- 有关执行认证的更多信息，请参阅 工作流指南。
- 如需有关 Operator 功能级别的更多信息，使用 Seamless Upgrades，请参阅 Operator Framework 文档。
