کانتینر و Kubernetes برای اپ‌های جاواContainers & Kubernetes for Java Apps

Let me make one fact clear up front: writing a Java app that "works on my laptop" is one thing; getting that same app into production so it's stable, small, fast, and scalable is another thing entirely. Standing between the two are two technologies that are now effectively the industry standard: containers, which wrap your app and all its dependencies into one portable box, and Kubernetes, which runs and manages an army of those boxes across dozens of machines. But Java behaves oddly in this world: the JVM is a creature that thinks it owns the whole machine, while it actually lives inside a container with a strict quota. If you don't understand that tension, your app either gets OOMKilled, or starts slowly, or drops users' requests on shutdown. In this chapter you'll learn not just the commands, but the why behind each one.

Part 0 — a few words you must feel before we start

Before any code, a few terms recur throughout this chapter. Let me plant them now.

• image: a read-only, layered template containing everything needed to run the app: a minimal OS, a Java runtime, your jar, and configuration. Like a "frozen snapshot" of a ready-to-run system.
• container: a running instance of an image. If the image is the recipe, the container is the cooked dish on the table.
• layer: each instruction in a Dockerfile creates a new layer. Layers are cached and shared across images; this fact is later the key to small, fast builds.
• registry: the image warehouse (like Docker Hub or GitHub Container Registry) where you push and pull images.
• cgroups (control groups): the Linux kernel mechanism that caps a container's CPU and memory quota. The hidden hero of this chapter — the thing the JVM must "see."
• orchestrator: a system like Kubernetes that decides which container runs on which machine, keeps them alive, and scales them.

Docker from zero: why containers at all?

Before containers, environment differences were a nightmare: a different Java version, a missing env var, an absent system library. Docker killed those differences by packaging the app together with its entire runtime environment. Unlike a virtual machine (VM), which emulates a full OS and is heavy, a container shares the host OS kernel and isolates only the execution space; so it boots in a few hundred milliseconds and consumes negligible resources.

At the heart of it is a file called Dockerfile: the recipe for building an image. Let's start with a naive example that almost everyone writes first — and then see why it's wrong.

# Naive example — it works, but it's bad
FROM eclipse-temurin:25-jdk
WORKDIR /app
COPY . .
RUN ./mvnw package
CMD ["java", "-jar", "target/app.jar"]

This image works, but has three big problems we'll fix one by one:

1. It's huge. The jdk base contains the full compiler and dev tooling, when running only needs a runtime.
2. It destroys the cache. With COPY . ., any tiny code change invalidates every subsequent layer, including the Maven dependency download; every build becomes slow.
3. Build tooling stays in the production image. Maven, source code, and the .m2 cache needlessly live in the final image, inflating both size and attack surface.

Step one: the multi-stage build

The fix for "build tooling in the final image" is the multi-stage build: you use several FROM stages; in the first (builder) you build with the full JDK, and in the second you copy only the output into a slim JRE base. The build tooling never ends up in the final image.

# Stage 1: build with the full JDK
FROM eclipse-temurin:25-jdk AS builder
WORKDIR /app
# Copy only the dependency files first to preserve the layer cache
COPY .mvn/ .mvn/
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline -B
# Now copy the code; a code change only invalidates from here on
COPY src/ src/
RUN ./mvnw clean package -DskipTests -B

# Stage 2: run with a slim base (runtime only)
FROM eclipse-temurin:25-jre AS runtime
WORKDIR /app
# Create a non-root user; never run as root
RUN useradd --system --uid 1001 appuser
USER 1001
COPY --from=builder /app/target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Step two: proper jar layering in Spring Boot

Multi-stage solved the build-tooling problem, but a subtle cache problem remains. A regular Spring Boot jar is a "fat jar": your own code plus tens of megabytes of dependencies, all in one file. When you copy that in a single layer, any tiny change to your own code causes that entire layer — including all the unchanged dependencies — to be rebuilt and re-pushed.

Spring Boot has had a fix since version 2.3: the layered jar. The app jar is internally split into several logical layers ordered by "how often they change":

• dependencies — release dependencies (rarely change).
• spring-boot-loader — Boot's own launcher classes (almost never change).
• snapshot-dependencies — SNAPSHOT dependencies (occasionally change).
• application — your own code (changes constantly).

By copying each layer in a separate COPY, Docker can keep the dependency layers cached and rebuild only the thin application layer. In Spring Boot 3.3 onward, the modern tools jarmode does this (superseding the older layertools):

FROM eclipse-temurin:25-jdk AS builder
WORKDIR /app
COPY .mvn/ .mvn/
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline -B
COPY src/ src/
RUN ./mvnw clean package -DskipTests -B
# Extract the jar into logical layers
RUN java -Djarmode=tools -jar target/app.jar extract --layers --destination extracted

FROM eclipse-temurin:25-jre
WORKDIR /app
RUN useradd --system --uid 1001 appuser
USER 1001
# Each layer in a separate COPY; low-churn first, high-churn last
COPY --from=builder /app/extracted/dependencies/ ./
COPY --from=builder /app/extracted/spring-boot-loader/ ./
COPY --from=builder /app/extracted/snapshot-dependencies/ ./
COPY --from=builder /app/extracted/application/ ./
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Step three: shrinking the image with jlink and distroless

So far we've dropped to the jre base, which itself is ~180 MB and carries the entire Java standard library, even modules your app never uses. Two tools can shrink this dramatically.

jlink: a custom runtime with only what you need

Java has been modular since version 9. jlink is a tool that builds a custom runtime containing only the modules your app needs. The result typically lands at 40–60 MB — versus the ~180 MB of a full JRE.

FROM eclipse-temurin:25-jdk AS jre-builder
# Discover the modules the app needs (or list them manually)
RUN jlink \
    --add-modules java.base,java.logging,java.sql,java.naming,java.desktop,java.management \
    --strip-debug --no-man-pages --no-header-files \
    --compress zip-9 \
    --output /javaruntime

FROM debian:stable-slim
COPY --from=jre-builder /javaruntime /opt/java
ENV PATH="/opt/java/bin:${PATH}"
COPY --from=builder /app/target/app.jar /app/app.jar
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

distroless: an image with no extra OS

Regular bases (like debian or ubuntu) carry a shell, a package manager, and dozens of tools that a Java app needs none of — yet each is a potential vulnerability. Google's distroless images contain only what's needed to run the program: no shell, no apt, no bash. This cuts both size and attack surface.

# distroless base for Java — no shell, no package manager
FROM gcr.io/distroless/java21-debian12:nonroot
COPY --from=builder /app/extracted/dependencies/ /app/
COPY --from=builder /app/extracted/spring-boot-loader/ /app/
COPY --from=builder /app/extracted/snapshot-dependencies/ /app/
COPY --from=builder /app/extracted/application/ /app/
WORKDIR /app
# distroless:nonroot runs as a non-root user by default
ENTRYPOINT ["java", "-jar", "app.jar"]

Let's line up the base options:

JVM container awareness: Java's biggest container trap

Now we reach the most Java-specific part. The JVM was historically designed to run on a dedicated machine. When it boots, it asks the OS "how much RAM and how many CPUs do you have?" and sizes the heap, the number of GC threads, thread pool sizes, and much more based on that. The problem: inside a container, those old questions used to return the host machine's answer, not the container's quota. On a node with 64 GB of RAM, a JVM inside a 512 MB container thought it had 64 GB and grabbed a giant heap — and then got OOMKilled.

The good news: modern JVMs are container-aware. The flag -XX:+UseContainerSupport, which has been on by default since JDK 8u191 and in JDK 11 onward, makes the JVM read the quota from cgroups, not from the whole host. So on a modern JDK, memory is usually detected correctly. But you still need to set the heap size deliberately.

Tuning memory: why a fixed Xmx is bad and MaxRAMPercentage is good

The old way was to give the heap a fixed value: -Xmx512m. But when you change the container's memory limit in Kubernetes, that hardcoded number is no longer in sync. The correct container way is a percentage:

# The JVM takes at most 75% of the container's memory as heap
java -XX:MaxRAMPercentage=75.0 -jar app.jar

CPU: the story fewer people get right

Memory is half the story; the other half is CPU, and here the traps run deeper. The JVM makes many decisions based on Runtime.availableProcessors(): the number of GC threads, the size of ForkJoinPool.commonPool(), the default sizes of connection and thread pools in frameworks. If this number is wrong, either your app spins up a nonsensical number of threads, or conversely stays underutilized.

In Kubernetes you have two CPU concepts that map to two different cgroup mechanisms:

• request → maps to cpu.shares; that is, "my relative share when there's contention." It's a weight, not a cap.
• limit → maps to cpu.cfs_quota; a hard cap: in each time window, use at most this much CPU, or you get throttled.

# Pin the core count explicitly and predictably
java -XX:MaxRAMPercentage=75.0 -XX:ActiveProcessorCount=2 -jar app.jar

Let's line up the key memory and CPU flags:

Lifecycle: graceful shutdown

When Kubernetes wants to move or scale down a pod, it doesn't kill it — first it sends a SIGTERM signal, meaning "please clean up nicely." If your app ignores this signal, in-flight requests are cut off half-done and the user gets an error. Graceful shutdown means: stop accepting new requests, but let the in-flight ones finish, then exit.

Spring Boot supports this natively. You just give two settings:

# application.yml
server:
  shutdown: graceful          # the server enters drain mode
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s   # max wait for active requests to finish

But in Kubernetes there's a critical subtlety: between the moment the pod is deleted and the moment its IP is removed from the Service endpoint list, there's a race. SIGTERM may arrive while the load balancer still sends traffic for a few more milliseconds. The standard fix is a preStop hook with a short sleep to cover this synchronization delay:

# in the container section of the Deployment
lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]   # give k8s time to remove the IP from the Service
terminationGracePeriodSeconds: 45        # must be > (preStop sleep + drain timeout)

If you want to react to the signal more explicitly (e.g. close a queue or flush a cache), you can add a shutdown hook too:

@Component
class GracefulCleanup {
    private static final Logger log = LoggerFactory.getLogger(GracefulCleanup.class);

    @PreDestroy
    void onShutdown() {
        // this method runs when the context is closing
        log.info("Flushing buffers and closing connections...");
        // flush cache, close queue producer, and so on
    }
}

Configuration: env, ConfigMaps, and Secrets

One of the "Twelve-Factor App" principles is: separate config from code. Never hardcode a database password or a service URL in the code or inside the image; your image should be identical and change behavior via external config. In the container world, that config comes from environment variables.

Spring Boot automatically maps environment variables to properties (this is called "relaxed binding"): the variable SPRING_DATASOURCE_URL maps to spring.datasource.url.

@ConfigurationProperties(prefix = "app.payment")
public record PaymentProperties(String apiUrl, String apiKey, int timeoutMs) { }

# application.yml — values come from env, not hardcoded
app:
  payment:
    api-url: ${PAYMENT_API_URL}
    api-key: ${PAYMENT_API_KEY}
    timeout-ms: ${PAYMENT_TIMEOUT_MS:3000}   # with a default value

In Kubernetes, non-secret config goes in a ConfigMap and secret data goes in a Secret. Secrets are stored as base64 (note: base64 is not encryption, just encoding) and must be protected with real encryption-at-rest and RBAC access control.

apiVersion: v1
kind: ConfigMap
metadata:
  name: payment-config
data:
  PAYMENT_API_URL: "https://payments.internal/api"
  PAYMENT_TIMEOUT_MS: "3000"
---
apiVersion: v1
kind: Secret
metadata:
  name: payment-secret
type: Opaque
stringData:                       # stringData means you don't base64 it yourself
  PAYMENT_API_KEY: "sk_live_secret_value"

Then in the Deployment you inject these as env:

envFrom:
  - configMapRef:
      name: payment-config
  - secretRef:
      name: payment-secret

Kubernetes basics: Pod, Deployment, Service

Now that we have a good image, let's see how Kubernetes runs it. There are three foundational concepts you must distinguish.

• Pod: the smallest runnable unit. Usually one container (your app) but sometimes several that must sit together. Pods are ephemeral: they can die at any moment and be replaced with a new IP. So never rely on a Pod's IP directly.
• Deployment: you declare the desired state ("3 of this Pod with this image") and Kubernetes maintains it: it replaces dead Pods and, on updates, performs a rolling update (new Pods up, old ones down, no downtime).
• Service: a stable internal DNS name and IP that load-balances traffic across healthy Pods. Even as Pods change, the Service stays the same.

A complete Deployment for a Java app looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 3                    # always 3 replicas
  selector:
    matchLabels: { app: orders }
  template:
    metadata:
      labels: { app: orders }
    spec:
      containers:
        - name: orders
          image: registry.example.com/orders:1.4.2
          ports:
            - containerPort: 8080
          resources:
            requests:            # guaranteed minimum
              memory: "512Mi"
              cpu: "500m"
            limits:              # hard cap
              memory: "512Mi"
              cpu: "1000m"
          env:
            - name: JAVA_TOOL_OPTIONS
              value: "-XX:MaxRAMPercentage=75.0 -XX:ActiveProcessorCount=1"
---
apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector: { app: orders }
  ports:
    - port: 80
      targetPort: 8080

Resource limits: request vs limit

This distinction is the heart of scheduling and stability:

• request is what the scheduler guarantees to fit the Pod on a node. If the node doesn't have request worth of room, the Pod won't go there.
• limit is a cap that, if exceeded, causes throttling (slowdown) for CPU and OOMKilled (killed container) for memory.

Health: liveness, readiness, and startup probes

How does Kubernetes know your Pod is healthy? Via probes — periodic checks. There are three kinds, and confusing them is one of the most common production mistakes.

• liveness probe: is the process alive and healthy? If it fails, Kubernetes restarts the container. Keep this narrow: only check that the app itself hasn't deadlocked; don't tie it to external dependencies (database, another service).
• readiness probe: is the app ready to take traffic? If it fails, the Pod is removed from the Service (but not restarted). Here you may check critical dependencies.
• startup probe: active only during boot; it gives the app time to fully come up and holds liveness/readiness suspended until then. Critical for Java apps that need a few seconds of warm-up.

Spring Boot Actuator provides these out of the box. You just enable the probes (auto-detected in Kubernetes) so two endpoints appear:

# application.yml
management:
  endpoint:
    health:
      probes:
        enabled: true
      group:
        liveness:
          include: livenessState              # just the app itself
        readiness:
          include: readinessState,db          # app + critical dependencies
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus

This creates two paths: /actuator/health/liveness and /actuator/health/readiness. Now you point to them in the Deployment:

startupProbe:                    # up to 5 minutes to boot
  httpGet: { path: /actuator/health/readiness, port: 8080 }
  failureThreshold: 30
  periodSeconds: 10
livenessProbe:
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /actuator/health/readiness, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3

Startup time and GraalVM native images

Java apps have a historical weakness in the container world: startup time. The JVM must boot, load classes, and JIT-compile the hot code to reach peak speed. A Spring Boot app may take a few seconds to be ready and tens of seconds to reach peak performance. For an always-on server this doesn't matter, but for serverless/FaaS and fast scaling (scale-to-zero, sudden traffic) this cold start is expensive.

GraalVM native image is a fundamentally different approach: instead of compiling code at runtime (JIT), it compiles everything ahead of time (AOT) into a standalone native executable. The result: boot drops from seconds to tens of milliseconds and memory usage drops dramatically (often several-fold), because the entire JIT infrastructure and much of the metadata are removed. Spring Boot 3 onward has first-class support for this via Spring AOT.

# Build a native image with the Spring Boot plugin
./mvnw -Pnative native:compile
# Or build a native container image directly
./mvnw -Pnative spring-boot:build-image

But this miracle isn't free. AOT works via a static analysis (points-to analysis) that decides at build time which code is reachable and discards the rest. Anything dynamic — reflection, dynamic proxies, dynamic class loading, runtime classpath scanning — must be declared to it explicitly, or it breaks at runtime. Spring AOT automates much of this, but third-party libraries may need manual configuration.

Let's make the trade-off clear:

Best practices

• Always use a multi-stage build so build tooling doesn't end up in the final image; and copy dependencies before the code to preserve the cache.
• In Spring Boot, use jar layering (-Djarmode=tools ... extract --layers) and put each layer in a separate COPY.
• Run as a non-root user; for extra security, evaluate a distroless base.
• Tune memory with -XX:MaxRAMPercentage=75, not a fixed Xmx; and remember off-heap eats memory too.
• Set a CPU limit or pin -XX:ActiveProcessorCount so the JVM doesn't confuse the host's cores with the container's.
• For memory, set request = limit so the Pod lands in the Guaranteed class.
• Enable graceful shutdown with server.shutdown=graceful and set terminationGracePeriodSeconds larger than the sum of preStop and the drain timeout.
• Keep liveness narrow (just livenessState) and check dependencies in readiness; add a startupProbe for slow apps.
• Get config from env/ConfigMap/Secret, not hardcoding; and know that a raw k8s Secret is only encoded, not encrypted.
• Before reaching for a native image, ask: "is cold start and memory really my main problem, or am I just chasing shiny?" If it's an always-on service, the classic JVM (perhaps with CDS) is often enough.

Interview questions