# Persistenter Speicher fuer hochgeladene Bilder und Videos (Produkt-,
# Ernten- und Inhaltsfotos aus dem Admin-Bereich, siehe
# app/api/admin/upload/route.ts und app/uploads/[...path]/route.ts).
#
# WARUM EIGENES MANIFEST: 05-app-deployment.yaml hatte hier bisher nur einen
# "emptyDir"-Platzhalter. Der ist an die Lebensdauer des Pods gebunden —
# jeder Neustart, jeder Redeploy und jede Node-Verlagerung loescht saemtliche
# hochgeladenen Bilder. Die Datenbank behaelt dabei die Bildpfade, die
# Dateien dahinter sind aber weg: die Seite zeigt danach ueberall kaputte
# Bilder statt der Produktfotos, ohne dass irgendwo ein Fehler auftaucht.
#
# ANZUPASSEN VOR DEM ANWENDEN:
#   - storageClassName: auf eine im Cluster vorhandene StorageClass setzen
#     ("kubectl get storageclass" zeigt die verfuegbaren; die als
#     "(default)" markierte wird verwendet, wenn das Feld ganz entfernt
#     wird). Die Zeile ist bewusst auskommentiert, damit das Manifest ohne
#     Aenderung gegen die Default-StorageClass anwendbar bleibt.
#   - storage: Groesse nach erwartetem Bildbestand. 5Gi reichen fuer einige
#     tausend optimierte Produktfotos; das Hero-Video (bis 100 MB roh, siehe
#     MAX_UPLOAD_VIDEO_BYTES in lib/uploads.ts) faellt dabei kaum ins
#     Gewicht.
#
# ZUGRIFFSMODUS: ReadWriteOnce genuegt, weil das Deployment mit genau einer
# Replica und der Strategie "Recreate" laeuft (siehe 05-app-deployment.yaml)
# — es greift also nie mehr als ein Pod gleichzeitig darauf zu. Soll spaeter
# hochskaliert werden, braucht es hier ReadWriteMany (NFS/SMB/CephFS) UND
# einen gemeinsamen Rate-Limit-Store (siehe Kommentar zu replicas in
# 05-app-deployment.yaml).
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wabenhain-uploads
  namespace: wabenhain
spec:
  accessModes:
    - ReadWriteOnce
  # storageClassName: "dein-storage-class"
  resources:
    requests:
      storage: 5Gi