Persistenten Speicher nutzen

Bevor Sie starten

Sie haben einen bereitgestellten Pilotcluster, eine vertrauenswürdige kubeconfig, kubectl und Zugriff auf einen vereinbarten Namespace. Setzen Sie KUBECONFIG, CP_CONTEXT und CP_NAMESPACE über die Zugangsanleitung, bevor Sie Befehle ausführen. Die Beispiele verwenden eine POSIX-Shell und eine einzelne Zugangsdatei. Gruppierte Blöcke stoppen bei fehlenden Einstellungen, ohne Ihr Terminal zu schließen; sie stellen keine Infrastruktur bereit und vergeben keine Rechte. Mit dem Cluster verbinden →

Persistenter Speicher muss für den Pilot einschließlich Preis und Klasse bestätigt sein. Notieren Sie Zugriffsmodus, Backup-Bedarf und Löschverhalten vor der Volume-Zuweisung. Der Betrieb einer zustandsbehafteten Anwendung ist eine eigene Entscheidung neben der Bereitstellung von Speicherplatz.

Storage-Eigenschaften vereinbaren

PersistentVolumeClaim prüfen

Diese Beispielanforderung verlangt 10Gi und ist kein enthaltenes Speicherkontingent. Ersetzen Sie die Klasse durch den bereitgestellten Wert und bestätigen Sie ReadWriteOnce-Unterstützung. Speichern Sie als cloud-demo-pvc.yaml und validieren Sie im vereinbarten Namespace. Die Zuweisung kann Speicherkosten auslösen; prüfen Sie sie vor dem Anwenden.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloud-demo-data
spec:
  storageClassName: REPLACE_WITH_AGREED_CLASS
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" apply --dry-run=server -f cloud-demo-pvc.yaml
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" diff -f cloud-demo-pvc.yaml
)

Der Claim allein richtet keine Datenbank ein und bindet keine Daten an das zustandslose Beispiel. Verwenden Sie ein geprüftes Anwendungsmanifest mit passendem Mount und Controller für Ihren zustandsbehafteten Workload. Binden Sie produktive Daten nicht in ein ungeprüftes Test-Image ein.

Pending und Bound einordnen

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get pvc
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" describe pvc cloud-demo-data
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get events --sort-by=.metadata.creationTimestamp
)

Bound bedeutet, dass der Claim an ein Volume gebunden ist; ein Anwendungstest mit Daten ist damit nicht bestanden. Pending kann eine fehlende Klasse, einen ungeeigneten Zugriffsmodus, Quoten-/Kapazitätsprobleme oder bewusst verzögerte Bindung anzeigen. Bei WaitForFirstConsumer kann zuerst ein passend eingeplanter Pod nötig sein. Folgen Sie den Events und lassen Sie ClusterPilot die Storage-Schicht prüfen, wenn sie außerhalb Ihrer Rolle liegt.

Mit Datenplan ändern und löschen

Bei Wachstum fragen Sie Zielgröße und erwartete Kosten an. Bestätigen Sie Erweiterbarkeit von StorageClass, Treiber und Dateisystem sowie möglichen Unterbrechungsbedarf. Beim Ausstieg prüfen Sie einen nutzbaren Export am Ziel, bevor Sie Löschung freigeben.