OpenShift core counting, line by line.

OpenShift core counting begins with a quiet fact: the subscription unit on self managed OpenShift is a pair of physical cores on each worker node where customer workloads run, and almost nothing else in the contract changes that.1 The list price moves in steps of two cores. The discount band moves with commit volume and term length. Every other variable on the renewal quote, the bundle composition, the term length, the support tier, lands on top of that single unit. If the count is wrong at the unit level, every figure derived from it is wrong by the same multiple.

Three mechanics move the count between the buyer's internal estimate and the figure the audit team produces. The first is hyperthreading: how logical threads are read against physical cores under the order form schedule actually in force. The second is the treatment of control plane and infrastructure nodes: which nodes carve out of the count, and whether the carve out still holds under the cluster's current taint configuration. The third is the OpenShift Plus bundle: how a single core figure becomes the entitlement floor for every component in the bundle. Each mechanic carries an audit surface in its own right. Together they produce most of the gap on a defended engagement.

The broader OpenShift licensing picture, including the differences between self managed, dedicated, and the hyperscaler integrated forms of OpenShift, is set out on the OpenShift practice hub and in the companion note on self managed, dedicated, and ROSA. The audit defense engagement that sits behind any formal inquiry on the count is set out on audit defense. The work that produces the buyer's own count in the first place is subscription assessment.

Most x86 servers ship with simultaneous multithreading enabled by default. Two logical threads on each physical core, presented to the operating system and to the cluster as two distinct schedulable units. OpenShift subscriptions are priced against physical cores, not logical threads, but the published metric reads physical cores in a particular way once virtualization sits between the bare metal and the cluster. The schedule on most current OpenShift order forms defines a subscription core as either one physical core on bare metal or two virtual CPUs in a virtualized environment, with carve outs that read cleanly in the order form and unevenly in deployment.2

The trap arrives at the point where telemetry is read. The audit team reads what the cluster actually reports, which on a virtualized worker node with hyperthreading enabled is a vCPU count that already reflects the thread to core mapping inside the hypervisor. An estate that ships with hyperthreading on and was modelled against physical cores will be read by the audit team against vCPUs and arrive at roughly twice the buyer's number. The fix is not to turn hyperthreading off. The fix is to read the schedule version on the actual order form, count against that schedule, and document the underlying topology so the carve out reads cleanly when challenged.

The schedule version matters because Red Hat has revised the OpenShift order form template across the years, and the carve out language has moved with it. An order form signed in 2019 does not read identically to an order form signed in 2024, and the audit team will read whichever version is in force on the date of the inquiry. The buyer side defense begins with retrieving the actual schedule version, in writing, before any number is offered.

A second consideration sits underneath: not every virtualized worker is the same. Workers on RHEL with KVM read differently from workers on VMware, and workers on a public cloud read differently again because the cloud reports vCPUs at the hypervisor layer rather than at the guest layer. The schedule does not always anticipate the variant. The figure on the renewal quote follows the reading that survives the order form, not the reading that follows from the topology diagram.

The second mechanic is the treatment of control plane nodes (the masters that run the Kubernetes API server, the scheduler, and etcd) and infrastructure nodes (the workers that carry platform services such as routers, the image registry, monitoring, and logging). The published order form for self managed OpenShift carves both out of the worker core count, on the condition that customer workloads do not run on those nodes. The carve out is conditional. The condition is enforced by node taints, and taints decay.

On a three node bare metal cluster running only platform services, the masters never schedule a customer pod and the carve out holds without effort. On a one hundred node cluster where workloads are deliberately spread across the fleet for utilisation, masters frequently end up running customer pods because the taint configuration drifted under cluster autoscaling, or because a platform team removed a taint to debug an incident and forgot to put it back, or because a node selector on a workload selected a node the platform team did not expect.3 Whether those nodes count at the audit window is a contractual question, not an architectural one, and the contractual answer reads against telemetry.

Infrastructure nodes carry the same shape of risk with a different surface. The order form typically carves infrastructure nodes out where they carry only platform components on the published list (the ingress router, the image registry, monitoring, logging, and a small number of additional operators in newer schedules). A node that started as an infrastructure node and acquired a customer operator over time becomes a counted node under the carve out language, regardless of how the buyer reads its role internally. Operators that look like platform components but are not on the carved out list, including some service mesh and observability tools added on the buyer's own initiative, do not carve out by default.

The defender's burden under audit is to show, against telemetry, that masters and named infrastructure nodes did not run customer workloads across the period in scope. That is a documentary exercise, not an architectural one. Telemetry showing zero customer pods on a master node across the inquiry period closes the question. Telemetry showing one customer pod on one master node for one hour opens it. The practice work, as set out under subscription assessment, builds that documentary record before the audit window opens.

The third mechanic is the OpenShift Plus bundle. Plus prices a bundle of OpenShift, OpenShift Data Foundation (ODF), Advanced Cluster Management, Advanced Cluster Security, and Red Hat Quay against a single core count.4 The bundle is attractive at signature: the unit price beats the sum of the itemised list, the discount band is more generous on a single line than across five, and the order form is simpler. The trap arrives later, at the audit window, when Red Hat reads the bundle entitlement against the bundle deployment.

Plus entitles every component in the bundle to every core counted on the order. That is the mechanical point on which most bundle disputes turn. An enterprise that signed Plus at five thousand cores has, under the bundle's reading, an entitlement floor of five thousand cores for OpenShift, five thousand cores for ODF, five thousand cores for Advanced Cluster Management, five thousand cores for Advanced Cluster Security, and five thousand cores for Quay. If the actual deployment of Quay is two hundred cores and ODF is five hundred cores, the bundle floor still reads at five thousand for every component. At the audit window, the question is not whether the buyer is over deployed against the bundle. The question is whether the bundle is over entitled against the buyer.

The bundle is not the failure. The deployment model is. Plus pays where the bundle is deployed evenly across the worker fleet, because every component is consumed near the floor. Plus does not pay where the deployment is skewed, because the floor is paid in full regardless. The buyer's discipline is to model the floor before signature, not to read the discount in isolation. The companion note on when the Plus bundle pays sets out the deployment shapes that line up with the floor and the deployment shapes that do not. The renewal posture, set out on renewal negotiation, structures the order so the bundle composition and the deployment match.

The three mechanics share a common defense, which is the deliberate, line by line reading of the order form schedule against the cluster telemetry. The reading produces three artefacts. First, a topology map of every worker node by hardware class, hypervisor, and hyperthreading state. Second, a node role record across the inquiry period showing which masters, infrastructure nodes, and workers carried which workloads, drawn from telemetry rather than from architecture documents. Third, a Plus bundle deployment record showing the deployed footprint of each bundled component, on the same node basis as the worker core count.

Those three artefacts close the gap between the buyer's number and the audit team's number in most cases the practice has seen. The work is procedural, not adversarial. Built before the audit notice arrives, the artefacts narrow the inquiry to the rounding error. Built after the notice arrives, the artefacts still produce a defended posture, but the leverage is smaller because the clock is running. The mechanics on the broader audit response are set out in the 14 day response window; the engagement that runs that response is audit defense.

The count is also the variable that drives the renewal quote, not only the audit settlement. An estate that grew by ten percent on the worker side and stayed flat on the platform side will see its OpenShift line grow by more than ten percent at the next renewal, because the volume crossed a tier and the Plus bundle floor moved with the largest deployed component. The practice work between renewals is the same documentary exercise that closes the audit gap. It is also the work that informs the negotiation posture: the buyer who arrives at renewal with a current, defended count walks in with a number Red Hat cannot productively dispute. To open a buyer side reading of the current OpenShift count, write the desk via the contact page.5

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.