Oracle Java in Kubernetes: a compliance guide.

Kubernetes was supposed to make infrastructure simpler. For Oracle Java licensing, it did the opposite. Containers turn the JDK from something a person installs into something that arrives invisibly, inside an image, and then multiplies across hundreds of pods. This guide explains exactly how Oracle Java licensing applies in Kubernetes — and how to stay compliant without overpaying.

The container licensing problem

In a traditional estate, a JDK is installed deliberately on a known server. Someone made a decision; the install is discoverable; the licence position is stable. Containers break all three assumptions. The JDK is baked into a base image by whoever wrote the Dockerfile, often years ago. It is then inherited by every image built FROM that base, and instantiated afresh every time a pod starts. A single careless base-image choice can seed an Oracle JDK across an entire platform without one person ever knowingly installing it.

The result is that many organisations running Kubernetes have Oracle JDK in production and do not know it. The compliance problem is not that containers are licensed differently — it is that they make the JDK far harder to see.

How the employee metric applies to Kubernetes

Here is the single most important fact, and it is reassuring once understood: the Oracle Java SE employee metric does not count containers, pods, nodes or instances at all. The Java SE Universal Subscription is priced on your total employee headcount. Whether an Oracle JDK runs in one pod or fifty thousand, the licence requirement is the same — license the organisation's employees.

This cuts two ways. The good news: you cannot "blow up" your Java bill by scaling pods, because scaling is irrelevant to the metric. The bad news: a single Oracle JDK in a single production container is enough to trigger the requirement to license every employee. There is no small Kubernetes Java footprint. Either you have eliminated Oracle JDK from your clusters, or you have an organisation-wide licence requirement. That binary outcome is what makes container hygiene so important.

Why instance count doesn't matter, but discovery does

Because the metric ignores instance count, the compliance task in Kubernetes is not counting Oracle JDK — it is detecting it. You need a yes/no answer to one question for every cluster: is there any Oracle JDK running in a production workload? Answering that reliably means scanning at three layers:

• Image registries — inspect every image for the JDK it contains, by reading the release file or running java -version in the image.
• Running pods — scan live workloads, because what is deployed can drift from what the registry suggests.
• Base images and Dockerfiles — trace the inheritance chain to find where an Oracle JDK was introduced upstream.

The base image trap

The most common way Oracle JDK enters a Kubernetes estate is through a base image. Some widely used Java base images on public registries are built on Oracle JDK; others are built on OpenJDK. The two can look almost identical in a Dockerfile, and a developer choosing a base image is rarely thinking about the licence inside it.

Once chosen, the base image propagates. Every application image built on it inherits the Oracle JDK. A platform team that standardised on the wrong base image three years ago may have hundreds of downstream images carrying an OTN-licensed Oracle JDK into production. Fixing it is straightforward — but only once you have traced the chain back to the source.

Safe base images: the free OpenJDK options

The clean path is to standardise every Java base image on a free OpenJDK distribution. All of the following ship production-grade, freely licensed OpenJDK builds suitable for container use:

• Eclipse Temurin — official images from the Adoptium project, the most widely adopted vendor-neutral choice.
• Amazon Corretto — free long-term-support builds with official container images.
• Microsoft Build of OpenJDK — free builds with container images and long-term support.
• Red Hat build of OpenJDK — free OpenJDK images, with the UBI base for Red Hat environments.
• Azul Zulu — free community builds across a wide version range.

Mandating one of these as the only approved Java base image, and enforcing it in your build pipeline, removes the Oracle JDK risk at its root. New images simply cannot inherit an Oracle JDK if the approved base does not contain one.

Multi-tenant clusters and shared platforms

Shared Kubernetes platforms raise a governance question. When many teams deploy onto one cluster, any one of them can introduce an Oracle JDK that creates an organisation-wide licence requirement for everyone. The exposure is collective even though the mistake is local.

The answer is platform-level control rather than per-team trust. Admission controls that reject images containing Oracle JDK, a curated internal registry of approved base images, and CI checks that fail a build on an Oracle JDK are all more reliable than asking every team to remember the rule. In a multi-tenant cluster, compliance has to be a property of the platform.

Managed Kubernetes: EKS, AKS and GKE

Running on a managed Kubernetes service does not change the licensing logic — the licence still follows the JDK inside your container images, which you control. What managed services do offer is a helpful default. The cloud providers' own Java tooling leans on free OpenJDK builds: Amazon Corretto in the AWS ecosystem and the Microsoft Build of OpenJDK in Azure. If you adopt the provider's recommended Java images rather than carrying your own Oracle-based ones, a managed cluster tends to be free of Oracle Java by default. The risk, as always, is the image you bring with you — a lift-and-shift container carries its Oracle JDK into EKS, AKS or GKE unchanged.

Best practices for Java compliance in Kubernetes

• Standardise on one approved OpenJDK base image and publish it through an internal registry.
• Enforce it in CI/CD — fail any build whose image contains Oracle JDK.
• Add admission control so non-compliant images cannot reach production clusters.
• Scan registries and running pods continuously, not once.
• Audit inherited base images when you adopt third-party or vendor images.
• Treat any Oracle JDK finding as organisation-wide — because under the employee metric, it is.

Java in serverless and ephemeral workloads

Beyond long-running pods, modern platforms run Java in increasingly short-lived forms: serverless functions, scale-to-zero services, batch jobs and Knative-style workloads that exist only for the duration of a request. It is tempting to assume that something running for two seconds cannot carry a licence obligation. Under Oracle's employee metric, that assumption is wrong.

The metric does not measure runtime, instance count or duration — it measures employees. A Java function that executes for a fraction of a second, in production, on an Oracle JDK, creates exactly the same organisation-wide licence requirement as a JDK running continuously on a physical server. Ephemerality changes the discovery problem, not the licence position.

This makes ephemeral workloads genuinely dangerous, because they are the hardest to inventory — they may not even exist at the moment you scan. The only dependable control is the same one that protects long-running containers: ensure the base images and function runtimes are free OpenJDK builds, enforced in the build pipeline, so an Oracle JDK can never reach production in the first place.

Frequently asked questions

Does running more pods increase my Java licence cost?

No. The Oracle Java SE employee metric is priced on employee headcount and ignores pods, nodes, containers and instances entirely. Scaling has no effect on the bill.

Is one Oracle JDK container really a problem?

Yes. A single Oracle JDK in a production container can trigger a requirement to license every employee in the organisation. There is no small footprint under the employee metric.

How does Oracle JDK end up in our clusters?

Almost always through a base image. Some popular Java base images on public registries are built on Oracle JDK, and every application image built on them inherits it.

Which base images are safe to use?

Free OpenJDK builds — Eclipse Temurin, Amazon Corretto, the Microsoft Build of OpenJDK, the Red Hat build of OpenJDK and Azul Zulu — all carry no Oracle licence obligation.

Does using EKS, AKS or GKE change anything?

No. The licence follows the JDK inside your images, which you control. Managed services help only because their default Java tooling tends to use free OpenJDK builds.

How do we enforce compliance across many teams?

Through the platform: CI checks that fail builds containing Oracle JDK, a curated internal registry of approved base images, and admission control that blocks non-compliant images from production.

Conclusion

Kubernetes does not make Oracle Java more expensive — the employee metric sees right past your pods and nodes — but it does make Oracle JDK far easier to run by accident and far harder to find. The discipline that keeps you compliant is image hygiene: pick a free OpenJDK base, enforce it in the pipeline, block everything else at the cluster door, and scan continuously so nothing drifts in. Get that right and your container estate becomes one of the easiest parts of your Java licensing position to defend — provably free, by design.