IBM Cloud File Storage for VPC verwalten

Wenn Sie persistenten Speicher in Ihrem Cluster einrichten, haben Sie drei Hauptkomponenten: den Kubernetes persistent volume claim (PVC), der Speicher anfordert, das Kubernetes persistent volume (PV), das in einen Pod eingehängt und im PVC beschrieben wird, und die Dateifreigabe. Je nachdem, wie Sie Ihren Speicher erstellt haben, müssen Sie möglicherweise alle drei Komponenten separat löschen.

Die folgenden Einschränkungen gelten für das Add-on.

Es wird empfohlen, dass Ihr Cluster und VPC Teil derselben Ressourcengruppe sind. Wenn sich Ihr Cluster und VPC in separaten Ressourcengruppen befinden, müssen Sie Ihre eigene Speicherklasse erstellen und Ihre VPC-Ressourcengruppen-ID angeben, bevor Sie Dateifreigaben bereitstellen können. Weitere Informationen finden Sie unter Erstellen einer eigenen Speicherklasse.
In Clusterversionen wurden neue Sicherheitsgruppenregeln eingeführt 4.11 und später. Diese Regeländerungen bedeuten, dass Sie Ihre Sicherheitsgruppen synchronisieren müssen, bevor SieFile Storage for VPC. Weitere Informationen finden Sie unter HinzufügenFile Storage for VPC zu Apps.
Mit der Version wurden neue Speicherklassen hinzugefügt2.0 des Add-Ons. Sie können keine neuen Dateifreigaben mehr bereitstellen, die die älteren Speicherklassen verwenden. Vorhandene Volumes, die die älteren Speicherklassen verwenden, funktionieren weiterhin. Sie können die Volumes, die mit den älteren Klassen erstellt wurden, jedoch nicht erweitern. Weitere Informationen finden Sie im Migrieren zu einer neuen Speicherklasse.

File Storage for VPC-Cluster-Add-on aktualisieren

Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

Rufen Sie Ihre Cluster-ID ab.
```
ibmcloud oc cluster ls
```
Überprüfen Sie die verfügbaren Add-on-Versionen.
```
ibmcloud oc cluster addon versions
```

Inaktivieren Sie das -Add-on.

ibmcloud oc cluster addon disable vpc-file-csi-driver --cluster CLUSTER

Aktivieren Sie die neuere Version des Add-ons.

ibmcloud oc cluster addon enable vpc-file-csi-driver --cluster CLUSTER --version VERSION

Überprüfen Sie, ob das Add-on aktiviert ist, indem Sie die folgenden Befehle ausführen.

oc get deploy -n kube-system | grep file

ibm-vpc-file-csi-controller   2/2     2            2           13m

oc get ds -n kube-system | grep file

ibm-vpc-file-csi-node    2         2         2       2            2           <none>          14m

oc get pods -n kube-system  | grep file

ibm-vpc-file-csi-controller-7899db784-kc29g   5/5     Running   0             14m
ibm-vpc-file-csi-controller-7899db784-mp5jt   5/5     Running   0             14m
ibm-vpc-file-csi-node-bfqdz                   4/4     Running   0             14m
ibm-vpc-file-csi-node-n7jbx                   4/4     Running   0             14m

Einstellung von Ressourcen- und Anforderungsgrenzen in der Configmap

Führen Sie den folgenden Befehl aus, um die Konfigurationszuordnung zu bearbeiten.

oc edit cm addon-vpc-file-csi-driver-configmap -n kube-system

Beispielhafte Ausgabe.

apiVersion: v1
data:
  CSIBlockDriverCPULimit: 300m
  CSIBlockDriverCPURequest: 75m
  CSIBlockDriverMemoryLimit: 600Mi
  CSIBlockDriverMemoryRequest: 150Mi
  CSIDriverRegistrarCPULimit: 40m
  CSIDriverRegistrarCPURequest: 10m
  CSIDriverRegistrarMemoryLimit: 80Mi
  CSIDriverRegistrarMemoryRequest: 20Mi
  CSILivenessProbeCPULimit: 20m
  CSILivenessProbeCPURequest: 5m
  CSILivenessProbeMemoryLimit: 40Mi
  CSILivenessProbeMemoryRequest: 10Mi
  CSINodeDriverCPULimit: 120m
  CSINodeDriverCPURequest: 30m
  CSINodeDriverMemoryLimit: 300Mi
  CSINodeDriverMemoryRequest: 75Mi
  CSIProvisionerCPULimit: 80m
  CSIProvisionerCPURequest: 20m
  CSIProvisionerMemoryLimit: 160Mi
  CSIProvisionerMemoryRequest: 40Mi
  CSIResizerCPULimit: 80m
  CSIResizerCPURequest: 20m
  CSIResizerMemoryLimit: 160Mi
  CSIResizerMemoryRequest: 40Mi
  EIT_ENABLED_WORKER_POOLS: ""
  ENABLE_EIT: "false"
  SET_DEFAULT_STORAGE_CLASS: ""
  SecretSidecarCPULimit: 60m
  SecretSidecarCPURequest: 15m
  SecretSidecarMemoryLimit: 80Mi
  SecretSidecarMemoryRequest: 20Mi
kind: ConfigMap
metadata:
  creationTimestamp: "2025-06-19T11:23:13Z"
  labels:
    app.kubernetes.io/name: ibm-vpc-file-csi-driver
  name: addon-vpc-file-csi-driver-configmap

Bearbeiten Sie die Parameter nach Bedarf und speichern Sie die Datei.

Add-on inaktivieren

Wenn Sie vpc-file-csi-driver inaktivieren, werden die Pakete zur Verschlüsselung während der Übertragung von Ihren Workerknoten entfernt.

Führen Sie den folgenden Befehl aus, um das Add-on zu deaktivieren.

ibmcloud oc cluster addon disable --addon vpc-file-csi-driver --cluster CLUSTER

Überprüfen Sie, ob die Pods entfernt wurden.
```
oc get pods -n kube-system  | grep file
```

Erläuterungen zu den Optionen beim Entfernen von Speicher

Tagging wurde in Version nicht unterstützt 1.2. Dies wirkt sich auf das Entfernen von Dateifreigaben aus, wenn ein Cluster mit der Option --force-delete-storage gelöscht wird. Stellen Sie sicher, dass Sie alle PVCs bereinigen, die mit der Version 1.2 des Add-ons erstellt wurden, bevor Sie Ihren Cluster löschen.

Wie persistenter Speicher aus Ihrem IBM Cloud-Konto entfernt wird, hängt davon ab, wie Sie den Speicher eingerichtet haben und welche Komponenten Sie bereits entfernt haben.

Wird mein persistenter Speicher gelöscht, wenn ich meinen Cluster lösche?: Während der Cluster gelöscht wird, haben Sie die Option, den persistenten Speicher zu entfernen. Abhängig davon, wie Ihr Speicher bereitgestellt wurde, werden beim Entfernen des Speichers aber möglicherweise nicht alles Speicherkomponenten gelöscht. Wenn Sie Speicher mit einer Speicherklasse dynamisch bereitgestellt haben, die reclaimPolicy: Delete festlegt, werden Ihre PVC, PV und die Speicherinstanz automatisch gelöscht, wenn Sie den Cluster löschen. Bei Speicher, der statisch bereitgestellt wurde, oder bei Speicher, den Sie mit einer Speicherklasse bereitgestellt haben, die reclaimPolicy: Retain festlegt, werden die PVC und die PV entfernt, wenn Sie den Cluster löschen, aber Ihre Speicherinstanz und Ihre Daten bleiben erhalten. Die Speicherinstanz wird Ihnen weiter berechnet. Wenn Sie den Cluster in einem nicht einwandfreien Zustand gelöscht haben, kann der Speicher auch dann noch vorhanden sein, wenn Sie ausgewählt haben, ihn zu entfernen.
Wie lösche ich den Speicher, wenn ich meinen Cluster behalten möchte?: Wenn Sie den Speicher dynamisch mit einer Speicherklasse bereitgestellt haben, die reclaimPolicy: Delete festlegt, können Sie den PVC entfernen, um den Löschprozess für den persistenten Speicher zu starten. Ihr PVC, der PV und die Speicherinstanz werden automatisch entfernt. Bei Speicher, der statisch bereitgestellt wurde, oder bei Speicher, den Sie mit einer Speicherklasse bereitgestellt haben, die reclaimPolicy: Retain festlegt, müssen Sie die PVC, PV und die Speicherinstanz manuell entfernen, um weitere Gebühren zu vermeiden.
Wie wird die Rechnungsstellung beendet, nachdem ich meinen Speicher gelöscht habe?: Abhängig davon, welche Speicherkomponenten Sie löschen und wann Sie dies tun, kann der Abrechnungszyklus möglicherweise nicht sofort gestoppt werden. Wenn Sie den PVC und den PV, nicht aber die Speicherinstanz in Ihrem IBM Cloud-Konto, dann ist diese Instanz weiterhin vorhanden und wird Ihnen berechnet.

Wenn Sie den PVC, den PV und die Speicherinstanz löschen, wird der Abrechnungszyklus abhängig von dem billingType gestoppt, den Sie bei der Bereitstellung Ihres Speichers ausgewählt haben, und abhängig davon, wie Sie den Speicher löschen möchten.

Wenn Sie die persistente Speicherinstanz manuell über die Konsole IBM Cloud oder die Befehlszeilenschnittstelle kündigen, wird die Abrechnung wie folgt beendet:
- Speicher mit stündlicher Abrechnung: Die Abrechnung wird sofort gestoppt. Nachdem der Speicher storniert wurde, wird die Speicherinstanz möglicherweise für bis zu 72 Stunden in der Konsole angezeigt.
- Speicher mit monatlicher Abrechnung: Sie können zwischen sofortiger Stornierung oder Stornierung zur Jährung des Vertragsbeginns wählen. In beiden Fällen werden Ihnen die Gebühren bis zum Ende des aktuellen Abrechnungszyklus berechnet und die Abrechnung wird für den nächsten Abrechnungszyklus gestoppt. Nachdem der Speicher storniert wurde, wird die Speicherinstanz möglicherweise für bis zu 72 Stunden in der Konsole oder der CLI angezeigt.
- Sofortige Stornierung: Wählen Sie diese Option aus, um den Speicher sofort zu entfernen. Weder Sie noch Ihre Benutzer können den Speicher weiter nutzen oder Daten wiederherstellen.
- Jährung des Vertragsbeginns: Wählen Sie diese Option aus, um den Speicher zur nächsten Jährung des Vertragsbeginns zu stornieren. Ihre Speicherinstanzen bleiben bis zur nächsten Jährung des Vertragsbeginns aktiv und Sie können sie bis zu diesem Datum weiterhin verwenden. So hat Ihr Team beispielsweise genug Zeit, Ihre Daten zu sichern.
Wenn Sie den Speicher dynamisch mit einer Speicherklasse bereitgestellt haben, die reclaimPolicy: Delete festlegt, und wenn Sie angeben, dass der PVC entfernt werden soll, werden der PV und die Speicherinstanz sofort entfernt. Bei Speicher mit stündlicher Abrechnung wird Abrechnung sofort gestoppt. Bei Speicher mit monatlicher Abrechnung wird Ihnen der Speicher noch für den Rest des Monats berechnet. Nachdem der Speicher entfernt und die Abrechnung gestoppt wurde, wird die Speicherinstanz möglicherweise für bis zu 72 Stunden in der Konsole oder der CLI angezeigt.

Was muss ich beachten, bevor ich persistenten Speicher lösche?: Wenn Sie den persistenten Speicher bereinigen, werden alle Daten gelöscht, die in ihm gespeichert sind. Wenn Sie eine Kopie der Daten benötigen, erstellen Sie eine Sicherungskopie.
Ich habe meine Speicherinstanz gelöscht. Warum kann ich meine Instanz noch sehen?: Nach der Entfernung von persistentem Speicher kann es bis zu 72 Stunden dauern, bis die Entfernung vollständig verarbeitet wurde und bis der Speicher in der IBM Cloud-Konsole oder in der Befehlszeilenschnittstelle nicht mehr angezeigt wird.

Persistenten Speicher bereinigen

Entfernen Sie den PVC, den PV und die Speicherinstanz aus Ihrem IBM Cloud-Konto, um weitere Gebühren für Ihren persistenten Speicher zu vermeiden.

Vorbereitende Schritte:

Stellen Sie sicher, dass Sie alle Daten gesichert haben, die beibehalten werden sollen.
Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

Gehen Sie wie folgt vor, um persistente Daten zu bereinigen:

Listen Sie die PVCs in Ihrem Cluster auf und notieren Sie sich folgende Einstellungen: NAME des Persistent Volume Claim, die Speicherklasse (STORAGECLASS) und den Namen des persistenten Datenträgers, der an den Persistent Volume Claim gebunden ist und als VOLUME angezeigt wird.

oc get pvc

Beispielausgabe

NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS            AGE
claim1   Bound     pvc-06886b77-102b-11e8-968a-f6612bb731fb   20Gi       RWO           class       78d
claim2     Bound     pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c   4Gi        RWX           class 105d
claim3      Bound     pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb   24Gi       RWX           class        83d

Überprüfen Sie für die Speicherklasse die Einstellungen für ReclaimPolicy und billingType.
```
oc describe storageclass <storageclass_name>
```
Wenn die Zurückforderungsrichtlinie Delete (Löschen) enthält, werden Ihr persistenter Datenträger und der physische Speicher entfernt, wenn Sie den Persistent Volume Claim entfernen. Wenn die Zurückforderungsrichtlinie Retain (Beibehalten) enthält oder Sie Ihren Speicher ohne Speicherklasse bereitgestellt haben, werden Ihr persistenter Datenträger und der physische Speicher nicht entfernt, wenn Sie den Persistent Volume Claim entfernen. Sie müssen den PVC, den persistenten Datenträger und den physischen Speicher separat voneinander entfernen.

Wenn Ihr Speicher monatlich berechnet wird, wird Ihnen der gesamte Monat auch dann in Rechnung gestellt, wenn Sie den Speicher vor Ende des Abrechnungszyklus entfernen.
Entfernen Sie alle Pods, die den Persistent Volume Claim anhängen. Listen Sie die Pods auf, die den PVC anhängen. Wenn in Ihrer CLI-Ausgabe kein Pod zurückgegeben wird, ist kein Pod vorhanden, der die PVC verwendet.
```
oc get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
```
Beispielausgabe
```
depl-12345-prz7b:    claim1
```
Entfernen Sie den Pod, der den PVC verwendet. Wenn der Pod Teil einer Bereitstellung ist, entfernen Sie die Bereitstellung.
```
oc delete pod <pod_name>
```
Überprüfen Sie, dass der Pod entfernt wurde.
```
oc get pods
```
Entfernen Sie die PVC.
```
oc delete pvc <pvc_name>
```
Überprüfen Sie den Status Ihres persistenten Datenträgers. Verwenden Sie den Namen des persistenten Datenträgers (PV), den Sie zuvor als VOLUME abgerufen haben. Wenn Sie den PVC entfernen, wird der an den PVC gebundene persistente Datenträger freigegeben. Abhängig davon, wie Sie Ihren Speicher bereitgestellt haben, wird Ihr persistenter Datenträger bei automatischem Löschen in den Status Deleting (Wird gelöscht) oder bei manuellem Löschen in den Status Released (Freigegeben) versetzt. Hinweis: Bei automatisch zu löschenden persistenten Datenträgern kann vor dem Löschen kurzzeitig der Status Released angezeigt werden. Führen Sie den Befehl nach einigen Minuten erneut aus, um zu prüfen, ob der persistente Datenträger entfernt wurde.
```
oc get pv <pv_name>
```
Wenn der persistente Datenträger nicht entfernt wurde, entfernen Sie ihn manuell.
```
oc delete pv <pv_name>
```
Überprüfen Sie, dass der persistente Datenträger entfernt wurde.
```
oc get pv
```
Listen Sie Ihre gemeinsam genutzten Ressourcen auf.
```
ibmcloud is shares
```
Listen Sie jede Dateifreigabe auf und suchen Sie die zugehörige Cluster-ID.
```
ibmcloud is share SHARE | grep CLUSTER-ID
```
Löschen Sie die gemeinsam genutzten Ressourcen.
```
ibmcloud is share-delete (SHARE1 SHARE2 ...)
```