←
⌂
→
Start / Praxislabor / Lab 10
Lab 10

OpenShift Deployment

Von Demo-YAML zu produktionsnäherem Deployment mit Probes, Ressourcen und Config.

OpenShiftKubernetesProbesConfig
SchwierigkeitMittel+
Dauer75–105 Min
LernstufeStufe 6 – Praxislabor und Capstone
Arbeitsweise: Erst den Vorher-Code öffnen, dann Analyse lesen, anschließend die Nachher-Lösung und den Test vergleichen. Alle Abschnitte sind standardmäßig geschlossen.
⌂

Workshop-Slice

Dieses Lab zeigt einen konkreten Enterprise-Fehler mit Vorher/Nachher-Code. Die Beispiele sind bewusst fachlich benannt, damit du Architekturentscheidungen und nicht nur Syntax übst.

Lernziel

Du erkennst, welche Deployment-Informationen eine Enterprise-App für stabilen Betrieb braucht.

Ausgangslage

Das Deployment startet lokal, aber im Cluster fehlen Probes, Ressourcen, Konfiguration und klare Rollout-Signale.

Vorher: problematischer Code

Ein minimales Deployment ohne Ressourcen und Health Checks wirkt lauffähig, ist aber betrieblich riskant.

deployment-bad.yamlYAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: registry.local/order-service:latest
          env:
            - name: DB_PASSWORD
              value: secret123
Analyse: Was ist daran schlecht?
  • `:latest` macht Rollbacks und Reproduzierbarkeit schwer.
  • Secrets stehen im Klartext im Deployment.
  • Keine readiness/liveness/startup-Probes.
  • Keine CPU-/Memory-Grenzen.
  • Nur eine Replica trotz Enterprise-Verfügbarkeit.
Nachher: bessere Lösung

Die Zielversion trennt Config/Secret, setzt Ressourcen und nutzt Actuator-Probes.

deployment.yamlYAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app.kubernetes.io/name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: order-service
  template:
    metadata:
      labels:
        app.kubernetes.io/name: order-service
    spec:
      containers:
        - name: app
          image: registry.local/order-service:1.8.3
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: order-service-config
            - secretRef:
                name: order-service-secret
          startupProbe:
            httpGet: { path: /actuator/health/liveness, port: 8080 }
            failureThreshold: 30
            periodSeconds: 5
          readinessProbe:
            httpGet: { path: /actuator/health/readiness, port: 8080 }
            periodSeconds: 10
          livenessProbe:
            httpGet: { path: /actuator/health/liveness, port: 8080 }
            periodSeconds: 20
          resources:
            requests: { cpu: "250m", memory: "512Mi" }
            limits: { cpu: "1", memory: "1Gi" }
route.yamlYAML
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: order-service
spec:
  to:
    kind: Service
    name: order-service
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
Test / Prüfnachweis

Dieser Abschnitt zeigt, wie du die Verbesserung nachweist. Es ist bewusst kein reiner Happy-Path-Test, sondern prüft ein Risiko aus dem Vorher-Teil.

deployment-check.shBASH
#!/usr/bin/env bash
set -euo pipefail
oc rollout status deployment/order-service
oc get pods -l app.kubernetes.io/name=order-service
oc get route order-service -o jsonpath='{.spec.tls.termination}' | grep edge
Typische Fehler
  • Secrets im Klartext eintragen.
  • Health Checks auf fachliche Endpunkte legen.
  • Keine Requests/Limits setzen.
  • Image-Tags nicht versionieren.
Deep-Learning-Bezug

Die Links führen zum ausführlichen Inhalt; die Deep-Learning-Seite bleibt nur die Lernlandkarte und kopiert den Inhalt nicht doppelt.

→ Lehrbuch: Deployment und OpenShift→ Lab 08: Observability→ Deep Learning Stufe 5
Prüfcheckliste
  • □Readiness, liveness und startupProbe vorhanden.
  • □Keine Klartext-Secrets im Deployment.
  • □Ressourcen requests/limits vorhanden.
  • □Image-Tag ist versioniert.
⌂ Cockpit