Red Hat OpenShift subscription licensing.

Red Hat OpenShift came into the IBM portfolio with the Red Hat acquisition, and with it came a licensing model that looks simpler than PVU but carries its own counting risk. OpenShift is sold as a subscription tied to the compute it runs on, measured in cores or in pairs of cores depending on the offering and the edition. You buy enough subscription to cover the worker nodes in the cluster, and the entitlement has to keep pace as the cluster grows. The audit exposure is rarely the control plane. It is the worker fleet that expanded faster than anyone updated the subscription count.

Because OpenShift frequently sits underneath IBM Cloud Paks, the licensing question is really two questions stacked on top of each other. There is the OpenShift subscription for the platform, and there is the Cloud Pak entitlement for the software running on it. An audit can find a shortfall in either layer, and the two are counted differently. Treating them as one line is how estates end up under counted on both.

How the subscription is counted

An OpenShift subscription attaches to the worker nodes that run application workloads. The unit is typically a defined number of cores, or a pair of cores, per subscription, with self managed and cloud service editions priced on their own terms. The count is driven by the physical or virtual cores in the worker nodes, not by the number of pods, and not by how busy the cluster is. A node that is provisioned and joinable counts whether or not it is carrying load on the day the auditor looks.

• Subscriptions cover worker node compute, sized in cores or core pairs
• The control plane and infrastructure nodes follow their own entitlement rules
• Bare metal and virtualized nodes are counted by the cores they expose
• Autoscaled and burst capacity has to be entitled at its peak, not its average

Where audits find the gap

The first place is autoscaling. A cluster sized for a steady state but configured to scale out under load will, at its peak, run more worker cores than the subscription covers. If that peak is real and recurring, IBM treats the peak as the count. The second place is the boundary with Cloud Pak. When OpenShift carries IBM software billed under a Cloud Pak, the container reporting rules apply on top of the subscription, and a reporting gap there reverts the Cloud Pak software to all cores in the cluster. The third is the quiet sprawl of additional clusters spun up for a project and never decommissioned, each one a fresh subscription obligation nobody is tracking.

How we defend it

We separate the two layers and count each on its own terms. For OpenShift itself we reconcile the worker node inventory against the subscription record, establishing the true core count and the genuine peak rather than accepting a snapshot taken on the auditor's chosen day. For the Cloud Pak software on top, we confirm the container reporting was in place so the software stays at sub-capacity rather than reverting to the whole cluster. Where there is a genuine shortfall, we scope it to the period and the nodes it actually applies to, and we fold any forward subscription change into the settlement rather than buying it twice.