OpenShift, counted correctly.

OpenShift is sold as a subscription against cores, not against nodes and not against pods. The unit of measure is a pair of physical cores on each worker node where customer workloads run.1 The list price moves in steps of two cores; the discount band moves with commit volume, term length, and bundle composition. Everything else in the contract follows from how those cores are counted.

Control plane nodes (the master nodes that run the Kubernetes API server, the scheduler, and etcd) are not directly priced in the self managed listing. In mixed and virtualized deployments, however, master roles frequently sit on hosts that also run customer pods. That collapse of roles is where most audit findings begin. The dedicated and managed offerings restructure the bill: Red Hat OpenShift on AWS (ROSA), OpenShift on IBM Cloud, and Azure Red Hat OpenShift charge a per cluster or per node fee on top of underlying cloud compute. The accounting surface is smaller. The negotiation surface is not.

Three things determine the number on the renewal quote: how many worker cores ran across the year, whether hyperthreading was enabled and how the contract counts threads against cores, and whether the OpenShift Plus bundle was purchased in place of itemising OpenShift Data Foundation, Advanced Cluster Management, Advanced Cluster Security, and Quay. Buyers who model only the first surface routinely arrive at a number Red Hat does not recognise.

Three places where the buyer side reading and the Red Hat reading diverge in nearly every defended engagement.

Trap one: the hyperthreading line. Most x86 servers ship with hyperthreading enabled by default. Two logical threads per physical core. OpenShift subscriptions are priced against physical cores, but Red Hat's published metric defines a core as either two vCPUs in a virtualized environment or one physical core on bare metal, with carve outs that read cleanly in the order form and unevenly in deployment.2 The audit team reads telemetry. If telemetry reports vCPUs and the assumption that two threads equal one core was not negotiated explicitly into the order form, the resulting count is roughly twice what the buyer modelled.

Trap two: the control plane drift. On a three node bare metal cluster running only platform services, masters are not workload nodes and are not counted. On a one hundred node cluster where workloads are intentionally scheduled across most of the fleet for utilisation, masters frequently end up running pods because the taint configuration drifted under cluster autoscaling. Whether those nodes count is a contractual question, not an architectural one. In the trailing twelve months, every signed OpenShift defense in the practice involved at least one node that was counted by Red Hat and not by the buyer.

Trap three: the OpenShift Plus bundle overhang. OpenShift Plus prices a bundle of OpenShift, OpenShift Data Foundation, Advanced Cluster Management, Advanced Cluster Security, and Quay against a single core count.3 Buyers adopt it because the bundle price beats the sum of itemised list. The trap arrives at the audit window: the bundle entitles every component to every core counted, which means an enterprise that deployed Quay on two hundred cores and OpenShift on five thousand will see the audit team treat the larger figure as the entitlement floor for the entire bundle. The bundle is not the failure. The deployment model is.

Every OpenShift engagement maps to one of the six surfaces of the practice. Audit defense leads because it is the highest stakes engagement and the one with a fixed clock. The remaining five build the posture that reduces the size of the next audit, or removes the audit entirely. See also the RHEL practice, Storage and Virtualization practice, and the Ansible Automation Platform practice.

Deeper notes on the questions the audit team will ask. Each entry is a standalone reference.