🛠️ Real-World Kubernetes — Hands-On

Real-World Kubernetes — Hands-On: This section walks you through a complete real-world scenario — deploying a Spring Boot REST API to Kubernetes from scratch — the same way a fli

This section walks you through a complete real-world scenario — deploying a Spring Boot REST API to Kubernetes from scratch — the same way a flight simulator walks a pilot through an actual cockpit instead of a slideshow about cockpits. Follow every command step by step; by the end you'll have a running, scaled, production-grade deployment, not just theory. So why insist on hands-on commands instead of just reading the YAML and trusting you understand it? Because Kubernetes errors are famously indirect — a typo in a Service's selector doesn't throw 'wrong selector', it just silently routes zero traffic to your pods, and you only catch that by actually running `kubectl get endpoints` and seeing an empty list. It's the same gap between reading about Java's `equals`/`hashCode` contract and actually breaking a `HashMap` lookup by forgetting to override `hashCode` — the theory is identical, but only running it reveals the silent failure mode. In a real QA role, this exact debugging path (deploy → service not reachable → check endpoints → check selector) is what you do during your first production incident, so practicing it now, deliberately, is the entire point.

Scenario: Deploy Spring Boot App to Kubernetes

Step 1-2: Create Spring Boot app and Dockerfile

Two FROM Lines: Why Multi-Stage Build Produces a Smaller Image

builder compiles with the JDK

The first `FROM eclipse-temurin:17-jdk-alpine AS builder` stage does the JAR compilation that needs the FULL JDK.

Dependencies are cached FIRST

`mvnw dependency:resolve` runs BEFORE `src` is copied — Docker never RE-downloads this layer unless pom.xml changes.

-DskipTests avoids REPEATING

Tests are not run AGAIN during image build — CI already ran them in an earlier stage.

runtime only copies the JAR

The second `FROM ... AS runtime` stage NEVER sees Maven — it only copies the finished `app.jar` into a slim JRE image.

ENTRYPOINT is what kubelet will run

`java -jar app.jar` is the ACTUAL command kubelet has the runtime execute when the container STARTS.