Container licensing rules: how Kubernetes multiplies the count.
Containers change how software is packaged and scheduled, not how vendors count cores. Oracle, IBM, and Microsoft license the physical hosts a workload can run on — and on a mobile Kubernetes cluster that default means every node, turning a 4-node deployment into an 8-to-20-times overcharge unless sub-capacity terms and node isolation cap the exposure.
Running licensed software in containers does not change the count. Legacy per-core products license the largest set of cores a workload can occupy, not the cores it uses — so an unrestricted container on a 4-node, 32-core cluster is exposed to 128 cores even if it runs on 8. The two controls that cap that exposure are contracted sub-capacity terms and provable node isolation; together they routinely cut the licensable footprint by 70 percent or more.
01 Key findings
A small container footprint does not mean a small license footprint. Kubernetes schedules and reschedules pods across nodes, so the licensable set of cores is, by default, every node the scheduler can place the workload on — not the node it happens to occupy.
Soft, software-only limits do not reduce the count. Namespace quotas and pod resource caps are treated as soft partitioning by Oracle and others; only hard isolation onto dedicated nodes reliably shrinks the boundary.
Sub-capacity is conditional, not automatic. IBM requires the License Metric Tool and scheduled reporting; Microsoft SQL Server requires active Software Assurance. Miss the condition and the vendor reverts to full physical capacity.
Isolation only counts if you can prove it. Auditors assess every node a container could run on unless the customer produces point-in-time configuration evidence for the full audited period.
Managed Kubernetes does not transfer the obligation. Third-party software in a hyperscaler's managed cluster is still licensed under the vendor's standard terms, against the nodes it can run on.
02 The licensable boundary
The core rule fits in one line: license follows the largest set of cores the workload can occupy, not the cores it currently occupies. On a 4-node cluster of 32-core hosts, an unrestricted licensed container is exposed to all 128 cores even if it runs on 8. Restricting where the container can be scheduled — through node selectors, taints, and dedicated node pools — is what shrinks the licensable footprint back to reality. The broader contract framing is in the software contract negotiation guide.
Workload mobility you never deployed deliberately drives the most expensive findings. A licensed container marked schedulable across a 20-node cluster is, on paper, deployed on 20 nodes. The difference between full-cluster and isolated licensing on a single large cluster can run into seven figures a year for a heavily licensed product — an audit finding that exceeds the annual budget for that product several times over.
03 Vendor container rules
No major vendor gives containers a discount by default. Each applies its existing per-core metric to the underlying hosts, then offers a conditional path back to sub-capacity. The defaults and the escape routes differ sharply.
| Vendor | Default container rule | Sub-capacity path | Key condition |
|---|---|---|---|
| Oracle | License all hosts the container can run on; no contractual container metric | Hard isolation to dedicated nodes | Written agreement; soft partitioning not recognised |
| IBM | Per-core (PVU / VPC); full capacity by default | Sub-capacity via ILMT or container add-on | Metric tool current and reports filed on schedule |
| Microsoft (SQL Server) | Per-core, 4-core minimum per container; license cores allocated | Flexible container licensing | Active Software Assurance required |
| VMware (Broadcom) | Per-core subscription across cluster hosts (Tanzu / vSphere) | Cluster-scoped subscription; cores per host | Sized to host count at renewal |
04 Sub-capacity terms
Oracle has no container-specific metric, so the standard processor rules apply and the cluster is treated like any other environment where the software can run. Namespace limits and pod resource caps are software-only, so they do not shrink the count; the only reliable reduction is hard isolation onto dedicated nodes the Oracle workload alone can use, documented and ideally written into the agreement.
IBM licenses most middleware per Processor Value Unit or Virtual Processor Core at full capacity by default. Sub-capacity is available but conditional: the customer must run the IBM License Metric Tool or an approved container mechanism and report eligible consumption on schedule. Miss the reporting requirement and IBM can reassess at full capacity for the entire period.
Microsoft SQL Server is licensed per core with a four-core minimum per container, and you license the cores allocated rather than the whole host — provided the deployment meets Microsoft's container terms and active Software Assurance is in place. Without Software Assurance the count reverts to physical cores. The per-core mechanics and CAL interactions are detailed in SQL Server licensing. Under Broadcom, VMware Tanzu and vSphere container platforms moved to a per-core subscription counted across the cluster's hosts, so the same full-capacity principle now recurs as a subscription rather than a perpetual licence.
05 Audit exposure
Node isolation only reduces the count if you can prove it, which makes documentation as important as configuration. An auditor confronted with a cluster assesses every node a licensed container could run on by default; the burden is on the customer to demonstrate that scheduling was restricted. The evidence that holds up is the configuration itself — node selectors, taints and tolerations, dedicated node pools, and admission policies — captured as point-in-time exports and retained across the audited period. A verbal assurance does not survive an audit; an exported policy showing a workload could only ever run on four named nodes does. Running a vendor's product on an uncertified orchestration pattern adds a separate risk: a support refusal during an outage, at the worst possible moment.
If isolation cannot be proven for the full audited period, vendors reassess at full capacity for that entire period — not just the moment of the audit. A cluster correctly isolated for ten months but undocumented for two can be billed as fully exposed for all twelve. Continuous configuration capture, not a one-time snapshot, is what closes this gap.
06 Compliance framework
Container licensing belongs in the total cost model at design time, not after an audit. Four factors govern the exposure; work them before a workload moves.
Licensing metric
Identify the metric per product — PVU, VPC, per-core, or subscription — and whether the vendor recognises a container boundary at all. Oracle does not; IBM and Microsoft do, conditionally.
Isolation architecture
Map which nodes each licensed workload can be scheduled on. A defined, named node pool with selectors and taints is the boundary; an open cluster is full exposure.
Sub-capacity conditions
Confirm the exact requirement — ILMT and filed reports for IBM, active Software Assurance for SQL Server, a written agreement for Oracle — and prove it is met continuously.
Evidence and support
Retain point-in-time configuration exports for the audited period, and verify the vendor certifies your orchestration pattern before it becomes an incident-time liability.
07 Mitigation controls
The single most effective control is node affinity: pin licensed workloads to a small, named node pool with selectors and taints, prove the restriction in configuration, and the licensable footprint becomes the node pool rather than the cluster. This one move routinely cuts exposure by 70 percent or more. Maintain a container licensing inventory with four fields per workload — vendor and product, licensing metric, the set of nodes it can be scheduled on, and whether sub-capacity terms apply — and review it quarterly in step with how fast the cluster changes.
The inventory also surfaces consolidation opportunities: licensed workloads scattered across many nodes that could be concentrated onto a dedicated pool. The isolation method is covered in software TCO modeling, the contract language to secure sub-capacity rights in contract terms that matter, and pairing isolation with vendor consolidation compounds the saving. Secure these controls at new purchase or renewal, when you hold the advantage — vendors grant them far more readily then than mid-term.
08 Our recommendation
Pin every licensed workload to a defined, named node pool with selectors and taints. Treat container placement as a licensing decision at design time, not an infrastructure choice discovered in an audit.
Capture configuration exports on an ongoing basis, keep ILMT current, and confirm Software Assurance is live. Isolation you cannot evidence for the whole period is reassessed at full capacity.
Secure an explicit container or sub-capacity metric, recognition of node-pool isolation as a valid boundary, a defined audit measurement method, and support commitments for the platform you actually run.
Map your container estate before the auditor does
We assess container deployments against each vendor's rules and negotiate sub-capacity terms. Median exposure reduction is 70 percent.
The Licensing Edge
Weekly vendor intelligence from former Oracle, SAP, and Microsoft executives, delivered every Tuesday.