BackendBench
Coffee

Unravel › Java concepts › Cloud and operations

I/O and data

Containers and Kubernetes in Java code

Production Java services run in containers on Kubernetes, and that shapes the code: configuration comes from environment variables, the app must start and stop quickly and gracefully, and sometimes the code talks to the cluster API itself.

🔎 Unravel this example

At a glance

Mental model

A shipping container: the app is packed with everything it needs in a standard box, and the port crane (Kubernetes) moves, copies and replaces boxes without caring what is inside, as long as the box follows the rules.

What happens, in order
  1. 1Twelve-factor configuration: read settings from environment variables (System.getenv("DB_URL") or Spring placeholders), never from files baked into the image, so the same image runs in every environment
  2. 2Kubernetes asks the app two questions through HTTP probes: liveness ("restart me?") and readiness ("send me traffic?")Spring Boot exposes them as /actuator/health/liveness and /readiness.
  3. 3On a rolling update Kubernetes sends SIGTERM, then waits terminationGracePeriodSeconds before killingThe app should stop accepting new work, finish in-flight work (server.shutdown=graceful) and close connections.
  4. 4Libraries such as the fabric8 or official Kubernetes client let code list pods, read ConfigMaps, or run leader election by calling the cluster API with the pod service account
Remember
Watch out
Configuration baked into the imageReadiness that returns up before the app can serveIgnoring SIGTERM so requests are cut offHeap sized to the whole container memory
Example (highlighted lines explain it)
String dbUrl = System.getenv("DB_URL");if (dbUrl == null) {    throw new IllegalStateException("DB_URL is not set");}String podName = System.getenv().getOrDefault("POD_NAME", "local");log.info("Starting on pod {}", podName);
  1. line 1 uses getenv, the core of Containers and Kubernetes in Java code
  2. line 5 uses getenv, the core of Containers and Kubernetes in Java code
Read the full explanation (about 2 min)

Production Java services run in containers on Kubernetes, and that shapes the code: configuration comes from environment variables, the app must start and stop quickly and gracefully, and sometimes the code talks to the cluster API itself.

A mental model

A shipping container: the app is packed with everything it needs in a standard box, and the port crane (Kubernetes) moves, copies and replaces boxes without caring what is inside, as long as the box follows the rules.

How it works

Twelve-factor configuration: read settings from environment variables (System.getenv("DB_URL") or Spring placeholders), never from files baked into the image, so the same image runs in every environment.

Kubernetes asks the app two questions through HTTP probes: liveness ("restart me?") and readiness ("send me traffic?"). Spring Boot exposes them as /actuator/health/liveness and /readiness.

On a rolling update Kubernetes sends SIGTERM, then waits terminationGracePeriodSeconds before killing. The app should stop accepting new work, finish in-flight work (server.shutdown=graceful) and close connections.

Libraries such as the fabric8 or official Kubernetes client let code list pods, read ConfigMaps, or run leader election by calling the cluster API with the pod service account.

Going deeper

The JVM must be aware of container limits. Modern JVMs read cgroup memory and CPU limits, but heap defaults (25% of memory) often need -XX:MaxRAMPercentage=75 or a tuned -Xmx; a heap equal to the container limit gets OOM-killed.

Logs go to standard output as one line per event (JSON is best) and the platform collects them. Writing log files inside the container is lost on restart.

Pods are interchangeable and short-lived: no local state, no in-memory sessions, no scheduled jobs that assume a single instance (see distributed locking).

Under the hood

Containers are Linux processes isolated with namespaces and limited with cgroups; the image is a stack of read-only layers plus a thin writable one. The kubelet runs the probes, and the service routes traffic only to pods whose readiness succeeds, which is why a slow-starting app must report not-ready until its caches and connections are up.

Common mistakes

  • Configuration baked into the image.
  • Readiness that returns up before the app can serve.
  • Ignoring SIGTERM so requests are cut off.
  • Heap sized to the whole container memory.

How Unravel recognises it

When you paste code, Unravel looks for these signs of containers and kubernetes in java code. Spotting them yourself is a good habit when you read unfamiliar code:

Part of a learning path

Related concepts

Spring Boot Actuator and health checksSpringSpring configuration propertiesSpring

Frequently asked questions

What is Containers and Kubernetes in Java code?

Production Java services run in containers on Kubernetes, and that shapes the code: configuration comes from environment variables, the app must start and stop quickly and gracefully, and sometimes the code talks to the cluster API itself.

What are the most common mistakes with Containers and Kubernetes in Java code?

Configuration baked into the image. Readiness that returns up before the app can serve. Ignoring SIGTERM so requests are cut off. Heap sized to the whole container memory.

How can I see Containers and Kubernetes in Java code in real code?

Paste your own Java into Unravel and it will point out where containers and kubernetes in java code appears, explain how it works at the detail level you choose, and draw the flow of the code around it.