Red Hat OpenShift editions, node roles and core counting covers the practical question behind every self-managed OpenShift subscription count: which nodes in a Kubernetes cluster consume subscriptions, and which edition they must carry. Red Hat sells self-managed OpenShift as subscriptions measured either in Core-pairs (two physical cores or four vCPUs, aggregated across all compute nodes) or in Bare Metal Nodes (one physical server).[1] Only compute nodes that run end-user application pods are counted. Control plane nodes, and infrastructure nodes that run only cluster-supporting workloads, are included in the subscription. Product Appendix 1 Exhibit 1.B defines the Units and Supported Use Cases; the self-managed OpenShift subscription guide explains how to apply them and states that it is a guideline, not a guarantee.[2]
Editions
The OpenShift subscription guide names four self-managed editions.[1]
| Edition | Scope described by Red Hat | Core-pair | Bare Metal Node |
|---|---|---|---|
| OpenShift Kubernetes Engine | Enterprise Kubernetes runtime with core OpenShift functionality; third-party operators not supported | Yes | Yes |
| OpenShift Container Platform | Full application platform to build, deploy and run applications | Yes | Yes |
| OpenShift Platform Plus | Container Platform plus Advanced Cluster Management, Advanced Cluster Security, Quay and OpenShift Data Foundation Essentials; x86 clusters only | Yes | Yes |
| OpenShift Virtualization Engine | Bare metal virtualization on KVM for virtual machine workloads only | No | Only option |
Appendix 1 treats OpenShift Platform Plus as a Bundle: the fees assume combined use on a single Unit, and a component used independently of the Bundle is charged at Red Hat’s standard fees for additional Units of that component (rule).[2] Advanced Cluster Management and Advanced Cluster Security are also sold on their own, by Core Band (two cores or four vCPUs) or per Bare Metal Node (Socket-pair with up to 128 cores), as are Advanced Cluster Management for Virtualization for OpenShift Virtualization Engine and Red Hat Quay per Deployment (see ACM Core Band, ACM Bare Metal Node, ACM for Virtualization, ACS Core Band, ACS Bare Metal Node, Quay).
Every node in a cluster must carry the same edition. The guide states that product types cannot be mixed within a cluster, although core-pair and bare-metal node subscriptions may be combined in one cluster of the same edition (rule).[1] A bare-metal cluster cannot, for example, host some nodes on Virtualization Engine for VMs and others on Platform Plus for containers.
Metrics
The Units are defined in Red Hat Enterprise Linux and OpenShift subscription licensing: Core-pair, Bare Metal Node, Core, vCPU, AI Accelerator and IBM Z IFL. For metered On-Demand OpenShift, the subscriptions service measures Core hours.[3]
Counting / floors
Compute nodes
Compute nodes are the RHEL or RHEL CoreOS instances where application pods run, and they require OpenShift subscriptions.[1] For core-pair subscriptions, the customer counts the aggregate physical cores or vCPUs across all compute nodes in all clusters to be entitled. The guide’s step-by-step method divides total cores by two, or total vCPUs by four, rounding up. On VMs and hyperscaler instances the core-pair model is mandatory; on bare metal the customer may compare both models, because a bare-metal node subscription covers one server regardless of socket or core count. OpenShift subscriptions do not limit the number of application instances.
On hyperthreading, the guide states that virtualized nodes calculate usage from the cores or CPUs assigned to the node, with each subscription covering four vCPUs when logical threads are used, and that Red Hat’s subscription tools assume threads are enabled. Bare-metal subscriptions count physical cores only.
Control plane and infrastructure nodes
Control plane node entitlements are included in self-managed subscriptions and are not counted.[1] A default installation deploys three control plane nodes and at least two compute nodes. Infrastructure nodes, meaning nodes that run pods supporting the cluster rather than applications, are also included as long as no user application instances run on them (rule).
The guide lists the workloads that qualify for an infrastructure node:
- OpenShift registry, Ingress Router, Observability, and HAProxy-based cluster ingress;
- Red Hat Quay, OpenShift Data Foundation, Advanced Cluster Management, Advanced Cluster Security, OpenShift GitOps and OpenShift Pipelines;
- hosted control planes, and Ansible Automation Platform used only for cluster management;
- custom and third-party monitoring agents, CNI and CSI drivers, hardware or virtualization enablement components, and controller pods for operators and custom resource definitions, but not the third-party software suite those agents belong to.
Any other end-user application on the node disqualifies it. Red Hat invites customers to verify with it whether a service qualifies.
Exceptions that bring every core into the count
Two exceptions in the guide remove the control plane exclusion:[1]
- Applications on control plane nodes. A control plane node used to host any end-user application needs subscriptions for all of its cores (rule).
- Compact and single-node clusters. In a compact three-node cluster the applications run on the control plane nodes, so the cores of all three nodes are counted regardless of role. Single node OpenShift receives no special accommodation either: every core on the node is entitled (rule).
Hosted control planes
With hosted control planes, control planes for many clusters run on a central cluster. The control plane nodes still do not count, but each hosted cluster’s compute nodes are entitled according to the infrastructure they run on: virtual clusters on OpenShift Virtualization Engine need core-pair subscriptions, while bare-metal compute nodes need bare-metal node subscriptions.[1]
AI Accelerators
Discrete accelerators used for compute (GPUs, TPUs, NPUs, FPGAs, DPUs and similar add-on devices) need one Red Hat AI Accelerator subscription per physical device, in addition to the core-pair or node subscriptions for the host. A physical GPU presented to VMs as several vGPUs still needs one subscription, because counting is based on physical accelerators (rule). Accelerators used only to draw pixels or move network data are not counted, and integrated accelerators inside the CPU package are excluded. The accelerator subscription’s service level must match the host subscription.[1]
Virtualization & partitioning
OpenShift Virtualization Engine
OpenShift Virtualization Engine is licensed only by bare-metal node subscriptions (rule).[1] Appendix 1 describes it as a Physical Node, Socket-pair with up to 128 Cores, supported only when installed on the bare metal server and used to create and manage virtual instances.[2] It allows unlimited VMs on subscribed hosts but no application containers, other than infrastructure containers that follow the infrastructure node rules (storage drivers, backup agents, ACM and Ansible components, container-based software-defined storage). It includes neither RHEL for the nodes nor RHEL guest entitlements for the VMs: RHEL guests need RHEL for Virtual Datacenters or per-VM subscriptions (rule). OpenShift running inside the VMs needs separately purchased core-pair subscriptions. Customers moving to a broader edition can change entitlements without redeploying clusters.
OpenShift Virtualization in the other editions
The OKE, OCP and OPP editions include OpenShift Virtualization, supported only when OpenShift is installed on bare metal and not inside a VM.[2] When such a cluster is entitled with bare-metal node subscriptions, virtual OpenShift clusters of the same product type hosted on it inherit its subscriptions (rule).[1] Appendix 1 Exhibit 1.B Note 2 ties this to subscriptions bought after 1 January 2025 at the new MSRP, which include 128 Cores per Socket-pair and Virtual Nodes hosted on OpenShift Virtualization on the Physical Node. On third-party hypervisors such as VMware vSphere, Red Hat OpenStack Platform or Nutanix, OpenShift in VMs must use core-pair subscriptions.
Alternative architectures
On IBM Z and LinuxONE, only core-based subscriptions are available and one Integrated Facility for Linux (IFL) needs one OpenShift core subscription, IBM Z being the only architecture whose base is a single core (rule).[1] Subcapacity applies: only the cores used by OpenShift are entitled, however partitioning is done. Without partitioning, up to three IFLs per cluster used actively for control plane or infrastructure services need no entitlement; three-node compact clusters require all IFLs to be entitled. IBM Power uses the core-pair model with no vCPU concept, Arm clusters follow the x86 rules, and OpenShift Kubernetes Engine and Virtualization Engine are not supported on IBM Z or Power.
Windows Server nodes
Windows Server containers run only on Windows Server compute nodes, with the control and infrastructure planes on x86 RHEL or RHEL CoreOS. Windows container support is a separate add-on priced by core, sold as OpenShift Container Platform, Premium (for Windows) (rule); the Windows software itself is bought separately.[1][2]
Platform Plus components
The software added by OpenShift Platform Plus is limited to managing nodes entitled with Platform Plus (rule).[1] Customers may install as many Advanced Cluster Management and Advanced Cluster Security central instances as needed, and these cover all Platform Plus nodes including control plane and infrastructure nodes, but managing Container Platform, Kubernetes Engine, managed cloud or third-party Kubernetes clusters requires add-on subscriptions. The guide gives the example that 100 Platform Plus core-pair subscriptions cannot be used to run 200 cores of Container Platform and separately manage 200 cores of Azure Red Hat OpenShift. Quay may be installed without limit on Platform Plus clusters and can serve other Kubernetes environments. OpenShift Data Foundation Essentials is included up to 256 TB of storage per cluster (rule); additional capacity requires expansion packs.[2]
Special use cases
- Disaster recovery. Paid subscriptions are needed for hot DR only. Warm and cold DR subscriptions are transferred from the primary site when a disaster occurs. Hibernating clusters that are not expressly designed for warm or cold DR, such as cloud clusters paused during low demand, require subscriptions; waking a DR cluster briefly for maintenance or tests does not (rule).[1]
- Migrations and swing upgrades. For a one-way migration from OpenShift 3, or a swing upgrade between OpenShift 4 minor versions, the subscription covers both the original and destination infrastructure until the migration completes, even though Red Hat’s tools show the environment as out of compliance during that period (rule).
- Mirror registry. A minimal Quay registry for mirroring content to disconnected clusters is included, limited to the OpenShift release payload, OperatorHub content and similar images plus a small set of infrastructure agent images.
Cloud / BYOL
Core-pair subscriptions can be deployed on public clouds, where four vCPUs always equal one core-pair; bare-metal node subscriptions are usable on supported hyperscaler bare-metal instances.[1] Metered OpenShift Container Platform On-Demand subscriptions are tracked in core hours, counting only subscribed compute nodes; control plane and infrastructure nodes are excluded, consistent with the annual rules (rule).[3] See Red Hat Cloud Access and pay-as-you-go cloud subscriptions.
Out of scope
- Managed OpenShift cloud services (Red Hat OpenShift Service on AWS, Azure Red Hat OpenShift, OpenShift Dedicated, OpenShift on IBM Cloud), governed by Product Appendix 4 or the cloud provider.
- OpenShift AI and Red Hat AI Enterprise Units beyond the AI Accelerator counting rule.
- Application Services bundles on OpenShift (Application Foundations, Application Runtimes), which use Core Bands with two core pools.
- List prices, which Red Hat does not publish in the guide.