fix: hochgeladene Bilder ueberleben einen Redeploy

Das uploads-Volume im App-Deployment war ein emptyDir-Platzhalter. Der ist
an die Lebensdauer des Pods gebunden: bei jedem Neustart, jedem Redeploy
und jeder Node-Verlagerung waren saemtliche hochgeladenen Produkt-,
Ernten- und Inhaltsfotos weg. Die Datenbank behaelt dabei ihre Bildpfade —
die Seite haette danach ueberall kaputte Bilder gezeigt, ohne dass
irgendwo ein Fehler aufgetaucht waere.

Neu: k8s/04-uploads-pvc.yaml (die Nummer war in der Reihenfolge noch frei)
mit einem PersistentVolumeClaim, den das Deployment jetzt bindet.
storageClassName ist bewusst auskommentiert, damit das Manifest ohne
Aenderung gegen die Default-StorageClass des Clusters anwendbar bleibt.

Damit einher geht zwingend "strategy: Recreate": Kubernetes' Standard
"RollingUpdate" startet den neuen Pod, BEVOR der alte beendet ist. Ein
ReadWriteOnce-Claim kann aber nur an einen Pod gebunden sein — der neue
Pod bliebe mit "Multi-Attach error for volume" in ContainerCreating
haengen, und das im k8s/README.md dokumentierte
"kubectl rollout restart" liefe schlicht in den Timeout. Recreate kostet
wenige Sekunden Ausfall pro Redeploy und sorgt nebenbei dafuer, dass nie
zwei Pods gleichzeitig laufen, die sich sonst die im Prozessspeicher
gehaltenen Rate-Limits teilen wuerden.

Alle Manifeste gegen einen YAML-Parser geprueft, zusaetzlich strukturell:
claimName trifft den PVC-Namen, PVC liegt im selben Namespace, und der
mountPath stimmt mit UPLOAD_DIR aus 01-configmap.yaml ueberein.

preflight: NEXT_PUBLIC_SITE_URL wird jetzt auch gegen "example.com"
geprueft. Die ausgelieferte Vorgabe ist "shop.example.com" — blieb sie
stehen, zeigten Sitemap, Canonicals und jeder Link in jeder
Bestellbestaetigung auf eine fremde Domain, ohne dass die bisherigen
HTTPS-/localhost-Pruefungen angeschlagen haetten.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

k8s/05-app-deployment.yaml

@@ -19,6 +19,23 @@ spec:
   # ohne dass das im Frontend sichtbar waere. Fuer replicas > 1 zuerst
   # lib/rate-limit.ts auf einen gemeinsamen Store (z.B. Redis) umstellen.
   replicas: 1
+  # PFLICHT in Verbindung mit dem uploads-Volume (siehe 04-uploads-pvc.yaml):
+  # die Standardstrategie "RollingUpdate" startet den NEUEN Pod, bevor der
+  # alte beendet ist. Ein ReadWriteOnce-Volume kann aber immer nur an einen
+  # Pod gebunden sein — der neue Pod bliebe in ContainerCreating mit
+  # "Multi-Attach error for volume" haengen, und ein
+  # "kubectl rollout restart" (der im k8s/README.md dokumentierte Weg fuer
+  # ein neues Image) liefe schlicht in den Timeout.
+  #
+  # "Recreate" beendet den alten Pod zuerst. Das kostet waehrend des
+  # Redeploys ein paar Sekunden Ausfall — bei einer Replica ist der
+  # Unterschied ohnehin gering, und der Container migriert beim Start erst
+  # die Datenbank, bevor er Verkehr annimmt. Der Nebeneffekt ist erwuenscht:
+  # es laufen nie zwei Pods gleichzeitig, die sich sonst die im
+  # Prozessspeicher gehaltenen Rate-Limits teilen wuerden (siehe Kommentar
+  # zu replicas oben).
+  strategy:
+    type: Recreate
   selector:
     matchLabels:
       app: wabenhain-app
@@ -116,19 +133,18 @@ spec:
             limits:
               memory: 1Gi
       volumes:
-        # Platzhalter — die Betreiberin ergaenzt hier ihre eigene
-        # Volume-Quelle fuer den Namen "uploads" (z.B. ein PVC, das gegen
-        # ein SMB-/NFS-Backend oder einen hostPath gebunden ist), etwa:
-        #   - name: uploads
-        #     persistentVolumeClaim:
-        #       claimName: wabenhain-uploads-pvc
+        # Bindet den PersistentVolumeClaim aus 04-uploads-pvc.yaml — dieses
+        # Manifest MUSS vor dem Deployment angewendet werden, sonst bleibt
+        # der Pod in "Pending" (unaufloesbare Volume-Referenz).
+        #
+        # Vorher stand hier ein emptyDir-Platzhalter. Das ist kein
+        # persistenter Speicher: bei jedem Pod-Neustart, jedem Redeploy und
+        # jeder Node-Verlagerung waren saemtliche hochgeladenen Produkt- und
+        # Erntenfotos weg, waehrend die Datenbank ihre Pfade behielt — die
+        # Seite zeigte danach ueberall kaputte Bilder, ohne Fehlermeldung.
         - name: uploads
-          # CHANGE-ME: obige emptyDir-Zeile durch die echte Volume-Quelle
-          # ersetzen. emptyDir ist NICHT persistent (Inhalt geht bei jedem
-          # Pod-Neustart verloren) und dient hier nur als Platzhalter, damit
-          # dieses Manifest ohne weitere Aenderung "kubectl apply"-faehig
-          # bleibt.
-          emptyDir: {}
+          persistentVolumeClaim:
+            claimName: wabenhain-uploads
 ---
 apiVersion: v1
 kind: Service