Kubernetes clusters and IBM software compliance.

The container default is the whole cluster.

IBM licensing treats container non-compliance more severely than any other deployment model. Where the sub-capacity conditions for a container deployment are not satisfied, the rule is that IBM charges for all cores in the cluster. A handful of pods consuming a few cores can therefore generate a finding sized to the entire node pool. On a large OpenShift estate that gap can be the difference between a modest entitlement and a seven figure claim.

Why Kubernetes is hard to report.

Pods are ephemeral. They schedule, scale, and reschedule across nodes continuously, so a point-in-time snapshot rarely captures what ran. IBM expects discovery by an approved tool, ILMT with container support or an equivalent such as a licensing service that watches the cluster, rather than an estimate. If the tool was not deployed within the 90 day window, did not run continuously, or did not see the namespaces where IBM software ran, the sub-capacity claim for that period is exposed to the cluster-wide default.

• An approved tool must discover the IBM software across the cluster, not sample it
• Deployment within 90 days of first eligible deployment, then continuous operation
• Quarterly reports retained for two years, mapped to the right namespaces
• Node labels and scheduling constraints documented to bound reachable capacity

Where the defense is built.

The buyer side work is to reconstruct what the cluster actually ran and what the approved tool actually recorded, quarter by quarter. Where the licensing service or ILMT container data shows the conditions were met, the contained VPC count stands and the cluster-wide charge falls away for that period. Where scheduling was constrained to a defined node pool, the reachable capacity is that pool, not the full cluster. The argument is always evidentiary: prove the scope, do not concede it.

What this means under audit.

A Kubernetes finding is the steepest version of the cluster capacity problem, which puts it squarely in the Contain and Reconcile steps of Contain, Reconcile, Challenge, Settle. Containing the data request matters first, because an unscoped export of cluster inventory hands IBM the all-cores argument. Reconciling the discovery records period by period is what brings the claim back to the workload that truly ran. Only then does the settlement conversation start from a defensible number.