Statische Bereitstellung

Statische Bereitstellung ist eine Methode, bei der PersistentVolumes (PVs) und VolumeSnapshotContents (VSCs) manuell erstellt werden, um auf vorhandene Volumes oder Snapshots auf dem vom CSI-Treiber verwalteten Speichersystem zu verweisen. Wenn ein Benutzer eine PersistentVolumeClaim (PVC) oder VolumeSnapshot (VS) erstellt, die den Spezifikationen einer zuvor erstellten PV oder VSC entspricht, bindet Kubernetes den Anspruch an diese Ressource. Dieser Ansatz ist nützlich, wenn Sie vorhandene Speicherressourcen mit Kubernetes Workloads verbinden müssen.

Statische Provisionierung für Volumes

Bei der statischen Volumenbereitstellung müssen sowohl das PV als auch das PVC manuell erstellt werden. Stellen Sie sicher, dass die in beiden Ressourcen angegebene Speichergröße mit der tatsächlichen Größe des zugrunde liegenden Volumes übereinstimmt.

  • Erstellen Sie eine PersistentVolume (PV), indem Sie eine Datei namens pv.yaml mit folgendem Inhalt.
    apiVersion: v1
    kind: PersistentVolume
    metadata:
    name: pv-static
    spec:
        capacity:
            storage: 2G
    accessModes:
        - ReadWriteOnce
    volumeMode: Filesystem
    persistentVolumeReclaimPolicy: Delete
    storageClassName: cephaascsi-sc
    csi:
        controllerExpandSecretRef:
            name: cephaascsi-secret
            namespace: default
        controllerPublishSecretRef:
            name: cephaascsi-secret
            namespace: default
        driver: csi.cephaas.io
        fsType: ext4
        volumeHandle: <Volume_ID>

Ersetzen Sie den Wert VolumeHandle durch die tatsächliche Volume-ID des vorbereiteten Volumes.

  • Erstellen Sie eine PersistentVolumeClaim (PVC), indem Sie eine Datei namens pvc.yaml mit folgendem Inhalt.
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
        name: pvc-static
    spec:
        accessModes:
            - ReadWriteOnce
        resources:
            requests:
                storage: 2G
        storageClassName: cephaascsi-sc
        volumeName: pv-static

In der Datei pvc.yaml können Sie das Feld volumeName verwenden, um den PVC explizit an einen bestimmten PersistentVolume (PV) zu binden. Ersetzen Sie den Platzhalter durch den tatsächlichen PV-Namen, wenn Sie diese Bindung implementieren möchten. Dieser Schritt ist optional.

Eine Speicherklasse ist erforderlich, damit Lösch- und Erweiterungsvorgänge korrekt funktionieren.

Die Namen von PersistentVolumes (PV) und PersistentVolumeClaims (PVC) sind editierbar und können angepasst werden.

Sobald PV und PVC erstellt sind, können Sie sie in Pod-Konfigurationen genau wie dynamisch bereitgestellte Volumes verwenden.

Statisches Provisioning für Snapshots

Die statische Snapshot-Bereitstellung ermöglicht es Ihnen, vorhandene Snapshot-Ressourcen manuell an Kubernetes Workloads zu binden. Bei dieser Methode müssen sowohl die VolumeSnapshot (VS) als auch die VolumeSnapshotContent (VSC) manuell erstellt werden und aufeinander verweisen.

Wichtige Überlegungen:

  • Sowohl VS als auch VSC müssen manuell erstellt werden.
  • Die Adresse VolumeSnapshotContent muss auf den zugrunde liegenden Snapshot-Handle verweisen.
  • Die VolumeSnapshot muss auf die entsprechende VolumeSnapshotContent verweisen.
  • Nach der Einrichtung funktionieren Snapshot-basierte Wiederherstellungsvorgänge genauso wie beim dynamischen Provisioning.

Erstellen Sie eine Datei mit dem Namen volumesnapshot.yaml mit dem folgenden Inhalt.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: volumesnapshot-static
  namespace: default
spec:
source:
volumeSnapshotContentName: volume-snapshot-content-static

Diese Ressource definiert den Snapshot und verlinkt ihn mit der entsprechenden VolumeSnapshotContent.

Erstellen Sie eine Datei mit dem Namen volumesnapshotcontent.yaml mit dem folgenden Inhalt.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: volume-snapshot-content-static
  annotations:
   	snapshot.storage.kubernetes.io/deletion-secret-name: cephaascsi-secret
  	snapshot.storage.kubernetes.io/deletion-secret-namespace: default
spec:
  deletionPolicy: Delete
  driver: csi.cephaas.io
  source:
  snapshotHandle: r134-bbcfe9bc-b863-4495-8b11-86382c27f2eb
  volumeSnapshotRef:
  name: volumesnapshot-static
  namespace: default

In der Datei volumesnapshotcontent.yaml sollte der Wert des Feldes snapshotHandle auf die Snapshot-ID eines vorhandenen Snapshots gesetzt werden.

Sobald beide Ressourcen erstellt und verknüpft sind, können Sie den Snapshot mit dem Standard-Wiederherstellungsverfahren in eine PVC wiederherstellen. Die Pod-Erstellung und das Einhängen von Volumes funktionieren genauso wie bei dynamisch bereitgestellten Snapshots.

Bekannte Einschränkung

  • Die Volume-Größe in statisch bereitgestellten Persistent Volumes (PVs) kann von der tatsächlichen Volume-Größe auf dem Speicher oder der Bereitstellung abweichen

Bei der statischen Bereitstellung stellt der Administrator manuell Speicher bereit und erstellt ein PV-Manifest, das auf dieses Speichervolumen verweist. OpenShift verwendet das Feld spec.capacity.storage im PV-Manifest als Metadaten zur Darstellung der Volume-Größe. Da die statische Bereitstellung den Aufruf CreateVolume gRPC des CSI-Treibers umgeht, der bei der dynamischen Bereitstellung verwendet wird, um das Volume zu erstellen und sicherzustellen, dass spec.capacity.storage mit der tatsächlichen Größe auf RSOS übereinstimmt, gibt es keine integrierte Validierung, die bestätigt, dass die angegebene Kapazität mit der tatsächlichen Größe des Backend-Volumes übereinstimmt. Wenn die im Manifest angegebene PV-Größe von der tatsächlichen Volume-Größe auf der Bereitstellung abweicht, können Pods nur die tatsächliche Volume-Größe verwenden und sehen, nicht die im Manifest angegebene Größe.

  • Anregung: Um Diskrepanzen zwischen den Metadaten von OpenShift’s und dem tatsächlichen Speicherverhalten zu vermeiden, empfehlen wir, die spec.capacity.storage des PV so einzustellen, dass sie der tatsächlichen Größe des zugrunde liegenden Speichers entspricht. Dies gewährleistet Konsistenz und eine genaue Planung und verhindert, dass OpenShift zu wenig oder zu viel Kapazität im Vergleich zu dem, was Pods tatsächlich verbrauchen können, meldet.