Senior Java · Fachbereich

Cloud, Container & Kubernetes

Entwicklerrelevante Container-, Kubernetes- und Cloud-Native-Praktiken ohne DevOps-Duplikation. Nutze die Seite, wenn ein Service gebaut oder ausgeliefert wird: Wähle den passenden Standardweg und prüfe Build, Security, Telemetrie, Rollout und Betriebsverantwortung.

Zur Übersicht

Arbeitsauftrag

Wann verwenden?

Wenn Laufzeitverhalten, Ressourcen, Deployment oder Isolation eines Services gestaltet werden.

Nicht dafür verwenden

Nicht um Anwendungsprobleme pauschal durch mehr Infrastruktur zu verdecken.

Definition of Done

Requests und Limits, Probes, Security Context, Skalierung, Störungsverhalten und Betriebsnachweis sind überprüft.

Anwendungen containerfreundlich bauen

Readiness, Liveness und Shutdown korrekt gestalten

Ressourcenlimits mit JVM-Verhalten abstimmen

Deploymentstrategie wählen

Strategie	Geeignet wenn	Kosten	Abbruchkriterium
Rolling	Versionen kurz kompatibel sind	gemischter Versionsstand	Readiness oder SLI verletzt
Canary	Risiko mit echtem Traffic messbar ist	Routing und Auswertung	Error Budget oder Guardrail
Blue/Green	schneller vollständiger Rückschwenk nötig ist	doppelte Kapazität	Smoke-Test oder Dateninkompatibilität

Alle Kapitel

Container Image

Multi-Stage-Builds trennen Build- und Laufzeitumgebung. Das Laufzeitimage enthält nur notwendige Artefakte, läuft ohne Root und besitzt nachvollziehbare Metadaten.

Der Container ist eine Lieferform; Konfiguration und Zustand bleiben extern.

DOCKER

FROM eclipse-temurin:21-jdk AS build
WORKDIR /workspace
COPY . .
RUN ./mvnw -q -DskipTests package

FROM eclipse-temurin:21-jre
RUN useradd --system --uid 10001 app
USER 10001
COPY --from=build /workspace/bootstrap/target/app.jar /app/app.jar
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

Probes

Liveness beantwortet, ob ein Neustart sinnvoll ist. Readiness beantwortet, ob Traffic angenommen werden soll. Externe Systeme gehören nicht blind in jede Liveness-Prüfung.

Graceful Shutdown muss aktive Requests und Consumer-Verarbeitung berücksichtigen.

YAML

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 10

Ressourcen

CPU- und Memory-Limits beeinflussen Heap, GC und Threading. Die JVM berücksichtigt Containergrenzen, dennoch müssen Headroom für Native Memory, Threads und Metaspace eingeplant werden.

Praxisartefakt · Deployment Guardrails

Readiness: Prüft lokale Arbeitsfähigkeit, nicht entfernte Downstreams.
Resources: Requests aus p95-Nutzung, Limits nach Last- und OOM-Test.
Security: Read-only Root, Non-root User und minimierte Capabilities.
Canary Gate: Fehlerrate, p95-Latenz und Saturation gegen Baseline.
Abbruch: Automatischer Rollback bei zwei verletzten Messfenstern.