容器许可主要针对使用 Kubernetes 编排运行的容器内的软件进行许可。容器是一组与系统其余部分隔离的一个或多个进程，运行这些进程所需的所有文件都来自一个独立的映像。

子容量许可是指在采用虚拟化技术（例如虚拟机）的环境中，许可容量小于服务器的全部容量。

如果您的部署使用了带有 Kubernetes 编排的容器，那么容器许可将允许您仅为容器化产品的可用容量购买许可，而无需为可能运行容器的整个集群购买许可。

此外，容器许可提供了计算整个簇中分数核心的能力，而不是强制每个节点或 Pod 计数到下一个全整数。

IBM License Service 还能自动收集许可证使用数据，帮助客户识别整个集群中其软件的资源使用情况；使其可以调整许可权限并保持合规性。

是的。

目前，客户只能通过容器许可交易附录，以交易方式选择加入容器许可条款。

随着下一版本 IPAA 的发布，容器许可条款将包含在本协议中。

客户可以在任何基于 Kubernetes 的解决方案上进行部署。

备注：

• IBM Cloud Paks 仅限于 Red Hat OpenShift。
• 如果未采用 Kubernetes 编排，则无法利用此许可模型。

目前仅支持基于 Linux 的容器。

此信息可在产品文档中找到。

容器许可基于 Cloud Paks 的 vCPU 要求。客户应根据其 Cloud Paks 所需的 vCPU 数量以及任何额外开销，向 OpenShift 授予许可。

IBM 为私有云部署（或本地部署）提供三种许可类型：

1. 全容量 – 许可软件所在服务器的全部物理容量。
2. 子容量 – 许可软件所在的 VM 环境中的虚拟化容量
3. 容器 – 许可软件所在的容器化环境中的虚拟化容量

因 Kubernetes 在集群中部署容器的方式所致，无法搭配 IBM License Metric Tool 使用子容量。因此，如果您希望将容器与 Kubernetes 编排结合使用，则必须使用容器许可或为服务器上的每个集群的全部容量授予许可。

不可以，如果您不按容器许可条款进行许可，则必须对容器所部署位置的全部物理容量进行许可。

如何许可软件取决于软件的部署方式。

• 利用 Kubernetes 编排的容器部署会使用容器许可。
• 容器部署（无编排）在虚拟机层使用子容量许可；软件部署（在虚拟机内）使用子容量许可

所有的部署也可能许可部署（或可能部署）软件的节点的全部容量。因此，如果您决定通过容器许可进行编排，将软件部署在容器中，然后决定将整个环境或部分环境迁移回虚拟机，则现在位于虚拟机上的部分可以按子容量许可进行许可。

客户必须维护 IBM License Service，而不是 IBM License Metric Tool（注意：IBM License Metric Tool 仍必须用于子容量部署）。除此之外，审计和合规性与《International Passport Advantage 协议》中规定的子容量许可规则并无不同。

IBM License Service 能够自动跟踪容器化软件的许可证使用情况。客户可以利用 IBM License Service 输出的使用报告；该报告为客户提供其许可程序（以及 Cloud Paks 中的解决方案）的每日峰值可用容量。这样一来，客户就可以核实自己的使用情况是否在授权范围内，并主动进行调整。

每个程序自带的预设 resources.limits.cpu 设置用于所有质量保证、性能测试等。虽然 IBM 不建议修改这些设置，但如果您选择修改，请先查阅产品文档，了解您的程序可接受的文档范围。

目前支持的核心指标包括：处理器价值单位 (PVU)、虚拟处理器核心 (VPC)。当支持任何其他指标时，这些网页将会更新。

未转换为容器化映像因而不支持在容器化环境中运行的产品不符合条件。此外，任何未启用 IBM License Service 运行和跟踪的产品将不符合容器许可的条件。

产品和/或部件号说明将说明许可指标。以下链接指向 Passport Advantage 定价/许可的来源：

• IBM 许可信息文档数据库
• IBM Passport Advantage 许可

正如 IBM 容器许可证页面所述，所需的授权将根据程序的总 vCPU 容量进行许可。即，根据计数方法定义的 Pod 可用的 vCPU 总量。

请注意：任何包含未设置 CPU 限制的容器的 Pod 都被视为具有与工作节点容量相等的 vCPU 容量。

• Pod 的 vCPU 容量是该 Pod 内所有容器的 CPU 限制之和。vCPU 容量少于一个核心的 pod 将计入分数。
• 在工作节点内，当 IBM 程序的所有 Pod 的总 vCPU 容量超过工作节点容量时，vCPU 容量等于工作节点容量。IBM 程序的 vCPU 容量将在集群层面汇总，并将小数向上舍入至最接近的整数。

对于典型的许可安排（包括子容量），按 PVU 指标进行许可的客户需要根据处理器价值单位许可网页上的图表确定其 PVU 与核心价值的比值。这不是对容器的要求，所有 PVU 部署的额定值都是 70 PVU 比 1 个核心。

通常，1 个 VPC = 1 个物理核心或 1 个虚拟核心。

这意味着程序的任何一组 Pod 将它们的核心数量加在一起，然后在整个集群的服务器上加在一起。例如：

• 工作节点 1 -> 3 个 Pod @ 0.1 个核心 = 0.3 个核心
• 工作节点 2 -> 8 个 Pod @ 0.2 个核心 = 1.6 个核心

总计 -> 1.9 个核心 -> 按 2.0 个核心收费 -> 2 个 VPC 或 140 个 PVU

对于 Cloud Paks，集群舍入是在捆绑解决方案级别（而不是 Cloud Pak）。

IBM 根据容器的潜在容量而不是实际使用量来发放许可。如果容器没有限制，则该容器的潜在容量就是整个节点容量。因此，容器将按此收费。

在任何情况下，如果程序的总 Pod 容量超过工作节点的容量，则使用工作节点的容量。例如：

节点容量 = 8 个核心

• Pod 1 - > 3 个核心
• Pod 2 -> 3 个核心
• Pod 3 -> 3 个核心

总计 = 3+3+3 = 9 个核心 -> 由于上限限制，需要授权 8 个核心。

对于 Cloud Pak 部署，上限设在捆绑解决方案级别（而非 Cloud Pak）。

                                               子容量                                                                                  容器                    

IBM 传统上根据整个许可期内的峰值容量对软件进行收费。例如：如果使用全年许可证，某个程序通常使用 8 个核心，但在 11 月份他们使用了 12 个核心，则当年的许可费用为 12 个核心。

这一点对于容器化许可而言并不会改变。IBM License Service 会跟踪许可证使用情况，并频繁轮询为应用程序部署的 Pod（和核心）数量。因此，将最高点作为许可期内的许可需求。

需要注意的是，Cloud Pak（Cloud Pak for Data 除外）会考虑 Cloud Pak 比率。因此，如果在某一时刻程序 A 采用 3:1 的比率并使用 9 个核心，而程序 B 采用 1:1 的比例并使用 4 个核心，则 Cloud Pak 的高水位线是 7 个核心 (9/3 -> 3 + 4/1 -> 4 = 7)

是的，最低许可要求是一个核心。

不，对于不足一个核心的小数，将通过将集群中每个程序的 pod 内的所有核心数相加，然后向上取整到最接近的整数来计算。

您可以根据记录的程序手动汇总 VPC。

您可以使用 License Service Reporter。

是的，但您必须使用 License Service 版本 1.18。如果使用的 License Service 版本较低，则滚动升级在某些情况下可能会导致过多计数。如出现此类情况，请保留并归档系统日志，并附加您的许可证使用报告。

您可以使用 License Service Reporter。

客户必须按照容器许可条款的规定创建季度报告。他们必须保留此文档，作为对 IBM 中间件可用权限进行持续许可合规管理的证据。根据产品条款，客户必须根据 IBM 或独立审计员的要求提供这些报告（请参阅 IBM Passport Advantage 协议）。

是的，容器化许可需使用 IBM License Service。

是的，容器化许可需使用 IBM License Service。

与 IBM License Metric Tool 一样，IBM License Service 也是免费的。

是的，您可以利用我们的自带软件许可 (BYOSL) 计划。可用服务提供者详列于 BYOSL 页面。

不遵守使用 IBM License Service 要求的客户将被收取整个集群中所有核心的费用。这是因为利用 Kubernetes 时，容器可以在整个集群的任何节点上启动。因此，有可能单个程序会拥有利用集群全部容量的容器。

新的容器许可客户必须在首次部署合格容器产品后 90 天内实施 IBM License Service。

现有容器客户应在根据容器许可条款提供新版本、发行版或修改版后及时升级。

由于 Kubernetes 环境的复杂性和快速变化的部署情况，手动报告被认为是不可行的。因此，不允许有任何例外情况；通过 Kubernetes 编排部署容器时，必须使用 IBM License Service。

是的，IBM License Service 是强制性的。

IBM License Service 在 Kubernetes 调度程序确定的集群中工作节点内的 Pod 中运行。

如果是多个集群，License Service 安装在部署容器化软件的每个集群中（客户应验证安装并保持 License Service 正常运行）。

License Service 将输出可实现此整合的数据；但此操作必须手动完成。客户也可以使用 License Service Reporter 来自动执行这一功能。

IBM License Service Reporter 从多个集群和 IBM License Metric Tool 收集并汇总 IBM License Service 的数据。欲了解更多细节，请参阅 IBM License Service 文档。

在安装任何利用容器许可的符合条件的程序 90 天内，i) 确认 IBM License Service 是否已安装、正确配置（请参阅程序文档）、运行和维护，或者 ii) 如果 IBM License Service 未安装和正确配置，则按照用户指南获取、安装、配置和维护 IBM License Service。

在整个报告期（即从日历季度第一个月的第一天开始，或者为了安装该工具时的初始报告，到日历季度最后一个月的最后一天为止），每季度为每个符合条件的容器生成 IBM 使用报告并保存两年。当季度内进行的任何产品部署都将从部署之日开始报告。

产品许可文档定义了每种产品的要求。

IBM License Service 可能会在通过每个 IBM Cloud Pak 的服务在 IBM 认证容器中部署容器化软件时预安装。请在首次容器部署时验证安装。如果未安装 IBM License Service，请联系产品支持或发送电子邮件至 talk2sam@us.ibm.com

IBM License Service 没有部件号。

没有。IBM License Service 不附带免费的 OCP 权利。License Service 包含在 IBM Cloud Pak 服务中，因此可利用 Cloud Pak 的可用 OCP 授权或客户从 Red Hat 获得的直接授权。

当 License Service 在 Cloud Paks 之外被使用时，客户需承担 License Service 可能需要的所有额外费用。

License Service 是一款轻量级工具，仅消耗极少的资源。请参阅知识中心文档了解更多信息。

如果仅运行容器化环境，则无需 IBM License Metric Tool。但是，对于子容量（虚拟机）环境，IBM License Metric Tool 仍然是必需的。如果是混合环境，则必须同时安装这两种工具。

客户必须维护 IBM License Service，而不是 IBM License Metric Tool（注意：IBM License Metric Tool 仍必须用于子容量部署）。除此之外，审计和合规性与《International Passport Advantage 协议》中规定的子容量许可规则并无不同。

IBM License Service 能够自动跟踪容器化软件的许可证使用情况。客户可以利用 IBM License Service 输出的使用报告；该报告为客户提供其许可程序（以及 Cloud Paks 中的解决方案）的每日峰值可用容量。这样一来，客户就可以核实自己的使用情况是否在授权范围内，并主动进行调整。