How Can a Core-Licensed Application Be Run Legally on Kubernetes?

Kubernetes does not normally schedule workloads to particular physical CPU cores. CPU requests and limits control scheduling and CPU time, but they do not necessarily prove that a licensed application used only a specific number of physical cores. If the vendor requires a fixed core count, you may need a dedicated node pool or dedicated hardware, with the workload constrained to those nodes.

Do not assume that setting a CPU limit in the deployment solves a core-based licensing requirement. A CPU limit generally controls scheduled CPU time rather than identifying dedicated physical cores. Ask the vendor or licensing reseller for explicit written guidance, especially for virtualized or shared infrastructure; otherwise you could face an audit or additional licensing fees.

There is no universal answer because every vendor defines and verifies core usage differently. Some require their own license server or monitoring agent, while others accept a usage report or reserve the right to perform an audit. Read the product license carefully and get written confirmation from the vendor about what evidence they accept.

Some licenses are based on the maximum environment where the application could run, including standby and disaster-recovery systems. Others use a license server that reports current usage or automatically stops the application when it exceeds the licensed amount. Because these models vary so much, an independent audit might provide evidence, but only the vendor can confirm what they will accept.

On a self-managed cluster, Kubernetes' static CPU manager policy can assign exclusive CPUs to certain containers. That may help technically enforce a fixed CPU allocation, but it is not available or configurable in the same way on every managed Kubernetes service. You would still need the vendor to confirm that exclusive CPU assignment satisfies the license.