Zum Inhalt

Runbook Storage

Runbook: Storage

Diagnose und Behebung von Speicherproblemen: Host-Disk, PVCs und Upload-Zwischenspeicher.

Host-Disk voll

Symptom: Pods schlagen fehl, Schreibfehler in Logs, df -h zeigt >95% Auslastung.

Diagnose:

df -h
du -sh /var/lib/rancher/k3s/storage/* | sort -rh | head -10

Lösung:

  1. Container-Image-Cache bereinigen: 
    sudo k3s crictl rmi --prune
  2. Alte K3s-Logs bereinigen: 
    sudo journalctl --vacuum-size=500M
  3. Temporäre Dateien entfernen: 
    sudo rm -rf /tmp/platform.*
  4. Langfristig: Disk über den VM-Provider erweitern.

Verifikation:

df -h

→ Auslastung unter 80%.

PVC voll

Symptom: Service loggt no space left on device.

Diagnose:

kubectl get pvc -n inovetra-platform

# Nutzung innerhalb des Pods prüfen
kubectl exec deployment/<name> -n inovetra-platform -- df -h

Lösung:

  • Daten bereinigen (z. B. alte Backups)
  • PVC erweitern (nur bei StorageClass mit allowVolumeExpansion — local-path unterstützt das nicht)
  • Workaround bei local-path:
  • Backup erstellen
  • PVC löschen und mit größerem Volumen neu erstellen
  • Daten aus Backup wiederherstellen

Datenverlust vermeiden

Vor PVC-Löschung immer sicherstellen, dass ein vollständiges Backup vorhanden ist! Siehe Backup und Restore.

Verifikation:

kubectl exec deployment/<name> -n inovetra-platform -- df -h

→ Ausreichend freier Speicherplatz.

Upload-Zwischenspeicher nicht verfügbar

Symptom: Dokument-Upload schlägt mit HTTP 503 fehl und der Hinweis nennt den Upload-Speicher. Die Suche und der Chat funktionieren weiter — ein defektes Upload-Volume legt nur den Upload-Pfad still, nicht die gesamte RAG API.

Hochgeladene Dateien liegen zwischen Upload und Verarbeitung auf der PVC inovetra-rag-upload-storage, die die RAG API unter /tmp/uploads einbindet. Nach der Verarbeitung werden sie gelöscht; dauerhaft liegen die Inhalte in Qdrant.

Diagnose:

# Meldet die RAG API den Zwischenspeicher als nutzbar?
kubectl exec deployment/inovetra-rag-api -n inovetra-platform -- \
  curl -sk https://localhost:8443/health

# Ist die PVC gebunden und der Pod gesund?
kubectl get pvc inovetra-rag-upload-storage -n inovetra-platform
kubectl get pods -n inovetra-platform -l app.kubernetes.io/component=rag-api

Im Health-Ergebnis zeigt das Feld staging entweder ok oder unavailable.

Lösung:

# Platz auf dem Volume prüfen
kubectl exec deployment/inovetra-rag-api -n inovetra-platform -- df -h /tmp/uploads

# Nach behobener Ursache (Platz, Rechte) neu starten
kubectl rollout restart deployment/inovetra-rag-api -n inovetra-platform

Verwaiste Dateien räumt die Plattform selbst ab

Ein stündlicher Aufräumlauf entfernt Staging-Dateien, die älter als 24 Stunden sind. Ein volllaufendes Upload-Volume deutet daher auf sehr viele gleichzeitige Uploads hin — oder auf eine Verarbeitung, die nicht durchläuft.

Verifikation:

kubectl exec deployment/inovetra-rag-api -n inovetra-platform -- \
  curl -sk https://localhost:8443/health

→ Feld staging steht auf ok, ein Test-Upload im Customer Portal gelingt.

Weiterführende Seiten