03 Deployment, Service und Route

Fachliche Erklärung

Pods sind austauschbar. Niemand sollte direkt auf einen Pod zeigen. Ein Service ist die stabile interne Adresse, eine Route ist der externe Eingang.

Ein Rollout ersetzt alte Pods durch neue Pods. Readiness entscheidet, ob ein Pod Traffic bekommen darf; Liveness entscheidet, ob ein Pod neu gestartet werden soll.

Deployment vs DeploymentConfig

Für neue Anwendungen ist das Kubernetes Deployment meistens die Standardwahl.

DeploymentConfig ist OpenShift-spezifisch und historisch wichtig, vor allem in älteren OpenShift-Setups mit ImageChange-Triggern und besonderen Lifecycle-Hooks.

In Modernisierungsprojekten tauchen beide Formen auf; deshalb muss man beide lesen können.

TLS bei Routes

edge: TLS endet am Router, zum Service geht es unverschlüsselt weiter.

reencrypt: TLS endet am Router und wird zum Backend neu verschlüsselt.

passthrough: Router reicht TLS durch, Backend terminiert selbst.

Ausführliches Enterprise-Beispiel

Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.

Konfigurations- und Codebeispiele

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  labels:
    app: order-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      serviceAccountName: order-api-sa
      containers:
        - name: order-api
          image: image-registry.openshift-image-registry.svc:5000/shop/order-api:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: 1000m
              memory: 1024Mi
          readinessProbe:
            httpGet:
              path: /q/health/ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /q/health/live
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 20

YAML

apiVersion: v1
kind: Service
metadata:
  name: order-api
spec:
  selector:
    app: order-api
  ports:
    - name: http
      port: 8080
      targetPort: 8080
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: order-api
spec:
  host: order-api.apps.example.com
  to:
    kind: Service
    name: order-api
  port:
    targetPort: http
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

BASH

oc -n shop rollout status deploy/order-api
oc -n shop get pods -l app=order-api -o wide
oc -n shop get svc,route
oc -n shop describe route order-api

Typische Fehlerbilder und Diagnose

Praxisaufgabe

Baue eine Route mit edge TLS und erkläre, welche Zertifikate wo liegen und wer sie erneuert.

Merksätze

• Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
• Security und Betrieb gehören von Anfang an zum Deployment.
• Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
• Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.