Container licensing: the all cores in the cluster penalty.

Containers were supposed to make IBM software cheaper to license. A workload that needs a fraction of a node should cost a fraction of a node. That is true, but only when the deployment proves it. IBM treats a container cluster as fully chargeable by default and grants sub-capacity relief only when an approved reporting mechanism continuously demonstrates which cores the software actually consumed. Miss that requirement and the relief disappears, and the default is severe: all cores in the cluster, charged.

This is the same logic as virtual machine sub-capacity, scaled to a more elastic platform. With a static host, full capacity means the host. With a Kubernetes or OpenShift cluster, full capacity means every worker node in the cluster, because without trustworthy reporting IBM cannot tell where a pod was scheduled and assumes it could have run anywhere. A handful of small pods can therefore generate a finding sized to dozens of nodes.

Why the default is the whole cluster

A scheduler can place a pod on any eligible node, and over a quarter it often does. IBM's position is that if you cannot show, with continuous evidence, where the software ran and how much capacity it could reach, then the conservative count is the full set of nodes it could have reached. That set is the cluster. The penalty is not a punishment clause buried in the contract, it is the absence of the evidence that would have narrowed the count.

The container reporting requirement

For Cloud Pak and other containerized IBM software, sub-capacity depends on an approved metering and reporting path, typically the IBM License Service running in the cluster, with reports collected continuously and retained. The mechanics mirror the broader sub-capacity rules: the tooling must be deployed promptly, run continuously, and produce reports you keep. A gap in that record is a gap in your defense, and IBM reads gaps as full capacity for the affected period.

• The License Service must run in the cluster and capture peak consumption
• Reporting must be continuous, not a snapshot pulled the week the audit lands
• Reports must be retained so each historical period can be evidenced
• A reporting gap reverts the affected period to all cores in the cluster

How we defend it

The defense is reconstruction and scoping. We rebuild the consumption history from whatever License Service data, cluster logs, and deployment records exist, and we establish the true peak virtual core consumption per product. Where reporting genuinely lapsed, we narrow the exposure to the affected window rather than letting IBM apply a cluster-wide, full-period count. We also separate eligible from ineligible nodes, because an all cores finding frequently sweeps in nodes that never could have hosted the workload.