Kubernetes for enterprise Java services
Runtime, probes, release safety and platform habits from programmes that actually ship Spring Boot on GKE and hybrid estates. By Sanjeev Kumar, Application Architect.
Why this page exists
Kubernetes shows up across the portfolio and the financial transaction platform case study as the runtime for Java/Spring Boot services beside Kafka and hybrid cloud controls — not as a separate “platform product” story. Homepage and profile framing is the same: Docker and Kubernetes on GCP (GKE) with AWS as a strong second. These notes stay at that altitude: what architects decide so services stay operable under real traffic.
Broader networking and perimeter topics live on cloud architecture; the Kubernetes diagram shows the control/data path shape used below.
Containers are not the architecture
Packaging a Spring Boot JAR into an image is the easy part. Architecture work is deciding service boundaries, failure domains and release units — then expressing those as Deployments, Services and sensible topology. If two modules still share a database transaction and a release train, putting them in separate pods does not make them microservices; see microservices for the boundary conversation that should precede the YAML.
Probes that mean something for the JVM
Liveness that only checks “process is up” will restart healthy JVMs stuck on a slow dependency and leave unhealthy ones serving traffic. Prefer readiness that reflects “safe to take traffic” (warmed caches, migrated schema flags, dependent client health where appropriate) and liveness that detects true deadlock or heap exhaustion — with enough initial delay for Spring Boot startup under realistic heap and CPU limits.
Startup probes help heavy services; misuse of aggressive liveness during GC pauses creates restart storms. Tune against observed p95 startup and dependency latency, not copy-pasted defaults.
Requests, limits and JVM reality
Resource requests should match what the service actually needs under load, not aspirational minimums that pack nodes denser on paper. Set heap relative to the container memory limit so the JVM and native memory do not OOM-kill the pod. CPU limits that are too tight create latency cliffs that look like application bugs. Horizontal Pod Autoscaler targets only work if the metrics reflect the bottleneck you care about (RPS, lag consumers, custom SLIs) — CPU alone is often a poor proxy for Kafka consumer or I/O-bound workers.
Release safety on a strangler path
On the banking platform modernisation path, Kubernetes hosts extracted Spring services behind an API façade while traffic shifts slice by slice. That only works with rolling updates, pod disruption budgets that respect quorum, and the ability to roll back a Deployment without a change window. Pair runtime rollouts with the same dual-run verification and idempotent consumers described in the event-driven notes — a green pod is not a green business cut-over.
Platform controls that travel with the pod
Inject secrets at runtime (Vault or cloud secret managers), never bake credentials into images. Prefer workload identity over long-lived keys in CI. Network policy and mTLS belong on the trust boundary for regulated traffic — the financial case study calls out mTLS and RBAC alongside the Kafka backbone. Ingress should terminate TLS deliberately; internal service mesh is optional complexity until the estate justifies it.
On GCP, GKE sits inside the same VPC and perimeter story as the rest of the cloud estate (shared VPC, private clusters, controlled egress to model APIs when AI workloads share the platform). Observability — logs, metrics, traces with correlation IDs — is part of the architecture, not a bolt-on after go-live.