File Storage for Classic einrichten

Dateispeichertypen

Wählen Sie den Typ des File Storage for Classics aus, den Sie bereitstellen möchten.

Bronze-, Silber- und Goldspeicherklassen

Diese Speicherklassen stellen Endurance-Speicher bereit. Mit dem Endurance-Speicher können Sie in vordefinierten Tiers für E/A-Operationen pro Sekunde die Größe des Speichers in Gigabyte auswählen.

Angepasste Speicherklasse

Diese Speicherklasse stellt Leistungsspeicher bereit. Mit dem Leistungsspeicher können Sie die Größe des Speichers und der E/A-Operationen pro Sekunde besser steuern.

IOPS

Wählen Sie für Ihren File Storage for Classic Werte für Größe und die Anzahl E/A-Operationen pro Sekunde aus. Die Größe und die Anzahl der E/A-Operationen pro Sekunde definieren die Gesamtzahl der E/A-Operationen pro Sekunde, die als Indikator für die Geschwindigkeit des Speichers dient. Je höher die Anzahl der E/A-Operationen pro Sekunde für Ihren Speicher ist, desto höher ist dessen Verarbeitungsgeschwindigkeit für Lese- und Schreiboperationen.

Bronze-, Silber- und Goldspeicherklassen

Diese Speicherklassen werden mit einer festen Anzahl von E/A-Operationen pro Sekunde pro Gigabyte geliefert und auf SSD-Festplatten bereitgestellt. Die Gesamtzahl der E/A-Operationen pro Sekunde hängt von der Größe des von Ihnen ausgewählten Speichers ab. Sie können innerhalb des zulässigen Größenbereichs eine beliebige ganze Zahl von Gigabyte auswählen, z. B. 20, 256 oder 11854 Gigabyte. Um die Gesamtzahl der E/A-Operationen pro Sekunde zu ermitteln, müssen Sie die E/A-Operationen pro Sekunde mit der ausgewählten Größe multiplizieren. Wenn Sie beispielsweise in der Speicherklasse "silver", die 4 E/A-Operationen pro Sekunde aufweist, als Größe für File Storage for Classic 1000 Gigabyte (1000Gi) auswählen, hat Ihr Speicher eine Gesamtzahl von 4000 E/A-Operationen pro Sekunde.

Angepasste Speicherklasse

Wenn Sie diese Speicherklasse auswählen, haben Sie mehr Kontrolle über die gewünschte Größe und die gewünschten E/A-Operationen pro Sekunde. Als Größe können Sie innerhalb des zulässigen Größenbereichs eine beliebige ganze Zahl von Gigabyte auswählen. Die von Ihnen gewählte Größe legt den Bereich der für Sie verfügbaren E/A-Operationen pro Sekunde fest. Sie können eine Anzahl von E/A-Operationen pro Sekunde auswählen, bei der es sich um eine Vielzahl von 100 handelt und die sich im angegebenen Bereich befindet. Der von Ihnen ausgewählte Wert für E/A-Operationen pro Sekunde ist statisch und wird nicht mit der Größe des Speichers skaliert. Wenn Sie beispielsweise 40 Gigabyte (40Gi) mit 100 E/A-Operationen pro Sekunde auswählen, bleibt die Gesamtzahl der E/A-Operationen pro Sekunde bei 100.

Das Verhältnis zwischen der Anzahl E/A-Operationen pro Sekunde und Gigabyte bestimmt auch den Typ der Festplatte, die für Sie bereitgestellt wird. Beispiel: Wenn Sie beispielsweise 500 Gigabyte (500Gi) bei 100 E/A-Operationen pro Sekunde haben, ist das Verhältnis E/A-Operationen pro Sekunde zu Gigabyte 0,2. Speicher mit einem Verhältnis von kleiner-gleich 0,3 wird auf SATA-Festplatten bereitgestellt. Wenn das Verhältnis größer als 0,3 ist, wird Ihr Speicher auf SSD-Festplatten bereitgestellt.

Rückforderungsrichtlinie

Wählen Sie aus, ob Ihre Daten nach dem Löschen des Clusters oder des Persistent Volume Claim (PVC) beibehalten werden sollen.

• Wenn Sie die Daten beibehalten möchten, wählen Sie eine Speicherklasse vom Typ retain aus. Beim Löschen des PVC wird nur der PVC gelöscht. Der persistente Datenträger, die physische Speichereinheit im Konto der IBM Cloud-Infrastruktur und Ihre Daten sind weiterhin vorhanden. Um den Speicher zurückzufordern und in Ihrem Cluster erneut zu verwenden, müssen Sie den persistenten Datenträger entfernen und die Schritte zum Verwenden von vorhandenem File Storage for Classic ausführen.
• Wenn Sie möchten, dass der persistente Datenträger, die Daten und Ihre physische File Storage for Classic-Einheit beim Löschen des Persistent Volume Claim gelöscht werden, müssen Sie eine Speicherklasse ohne retain auswählen.

Abrechnungstyp

Wählen Sie stündlich oder monatlich. Weitere Informationen finden Sie unter Preisstruktur.

Standardmäßig werden alle File Storage for Classic-Einheiten mit dem Abrechnungstyp "Stündlich" (hourly) bereitgestellt.

Wenn Sie als Abrechnungstyp "Monatlich" (monthly) wählen, zahlen Sie beim Entfernen des persistenten Speichers immer noch eine monatliche Gebühr für ihn, selbst dann, wenn Sie den Speicher nur für eine kurze Zeit genutzt haben.

Vorhandenen Speicher vorbereiten

Bevor Sie mit dem Anhängen Ihres vorhandenen Speichers an eine App beginnen können, müssen Sie alle erforderlichen Informationen für Ihren persistenten Datenträger abrufen und den Speicher vorbereiten, sodass in Ihrem Cluster auf den Speicher zugegriffen werden kann.

Für Speicher, der mit der Speicherklasse „ retain “ bereitgestellt wurde.

Wenn Sie Speicher mit einer retain-Speicherklasse bereitgestellt haben und Sie den Persistent Volume Claim entfernen, werden der persistente Datenträger und die physische Speichereinheit nicht automatisch entfernt. Zum Wiederverwenden des Speichers in Ihrem Cluster müssen Sie zuerst den beibehaltenen persistenten Datenträger entfernen.

Wenn Sie den in einem Cluster bereitgestellten Speicher auch in einem anderen Cluster verwenden möchten, führen Sie die Schritte für außerhalb des Clusters erstellten Speicher aus, um den Speicher dem Teilnetz Ihres Workerknotens hinzuzufügen.

1. Vorhandene PVs auflisten.

   kubectl get pv
   

   Suchen Sie den persistenten Datenträger, der zu Ihrem persistenten Speicher gehört. Der persistente Datenträger hat den Status "freigegeben" (released).

2. Rufen Sie die Details zum persistenten Datenträger ab.

   kubectl describe pv <pv_name>
   

3. Notieren Sie sich die Werte für CapacityGb, storageClass, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, server und path.

4. Entfernen Sie den persistenten Datenträger (Persistent Volume, PV)

   kubectl delete pv <pv_name>
   

5. Überprüfen Sie, dass der persistente Datenträger entfernt wurde.

   kubectl get pv
   

Für persistenten Speicher, der außerhalb des Clusters bereitgestellt wurde

Wenn Sie einen vorhandenen Speicher verwenden möchten, den Sie zuvor bereitgestellt, aber noch nie in Ihrem Cluster verwendet haben, müssen Sie den Speicher im selben Teilnetz wie Ihre Workerknoten verfügbar machen.

1. Klicken Sie im Infrastrukturportal „ IBM Cloud “ auf „ Speicher “.
2. Klicken Sie File Storage for Classic und wählen Sie im Menü „Aktionen“ die Option „Host autorisieren“ aus.
3. Wählen Sie Teilnetze aus.
4. Wählen Sie in der Dropdown-Liste das private VLAN-Teilnetz aus, mit dem der Workerknoten verbunden ist. Um das Teilnetz Ihres Workerknotens zu finden, führen Sie ibmcloud ks worker ls --cluster <cluster_name> aus und vergleichen Sie die Private IP Ihres Workerknotens mit dem Teilnetz, das Sie in der Dropdown-Liste gefunden haben.
5. Klicken Sie auf Übergeben.
6. Klicken Sie auf den Namen des File Storage for Classic.
7. Notieren Sie die Werte in den Feldern Mount Point, size und Location. Das Feld Mount Point wird als <nfs_server>:<file_storage_path> angezeigt.

Erstellen eines persistenten Volumes und eines persistenten Volume-Claims

1. Erstellen Sie eine Speicherkonfigurationsdatei für Ihr PV (Persistent Volume). Schließen Sie die Werte ein, die Sie zuvor abgerufen haben.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   Geben Sie den Namen des PV-Objekts ein, das erstellt werden soll.

   labels

   Geben Sie die Region und die Zone ein, die Sie zuvor abgerufen haben. Sie müssen mindestens einen Workerknoten in derselben Region und Zone haben.

   storage

   Geben Sie die Speichergröße der vorhandenen NFS-Dateifreigabe ein, die Sie zuvor abgerufen haben. Die Größe des Speichers muss in Gigabyte angegeben werden, z. B. 20Gi (20 GB) oder 1000Gi (1 TB), und sie muss mit der Größe der vorhandenen Dateifreigabe übereinstimmen.

   accessMode

   Geben Sie eine der folgenden Optionen an.

   • ReadWriteMany: Die PVC kann durch mehrere Pods angehängt werden. Alle Pods können von diesem Datenträger lesen und auf diesen Datenträger schreiben.
   • ReadOnlyMany: Die PVC kann durch mehrere Pods angehängt werden. Alle Pods verfügen über Lesezugriff.
   • ReadWriteOnce: Die PVC kann nur durch einen Pod angehängt werden. Dieser Pod kann von diesem Datenträger lesen und auf diesen Datenträger schreiben.

   server

   Geben Sie die Server-ID der NFS-Dateifreigabe ein, die Sie zuvor abgerufen haben.

   path

   Geben Sie den Pfad zur NFS-Dateifreigabe ein, den Sie zuvor abgerufen haben.

2. Erstellen Sie den persistenten Datenträger (PV) in Ihrem Cluster.

   kubectl apply -f mypv.yaml
   

3. Überprüfen Sie, dass das PV erstellt wurde.

   kubectl get pv
   

4. Erstellen Sie eine weitere Konfigurationsdatei, um Ihren Persistent Volume Claim (PVC) zu erstellen. Damit der Persistent Volume Claim (PVC) mit dem zuvor erstellten Persistent Volume übereinstimmt, müssen Sie denselben Wert für storage und accessMode auswählen. Das Feld storage-class muss eine leere Zeichenfolge enthalten. Wenn eines dieser Felder nicht mit dem PV übereinstimmt, werden dynamisch ein neues PV und eine neue physische Speicherinstanz bereitgestellt.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. Erstellen Sie Ihre PVC.

   kubectl apply -f mypvc.yaml
   

6. Überprüfen Sie, ob Ihr PVC erstellt und an den persistenten Datenträger (PV) gebunden wurde.

   kubectl describe pvc mypvc
   

   Beispielausgabe

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

Sie haben erfolgreich ein PV (Persistent Volume) erstellt und an einen PVC (Persistent Volume Claim) gebunden. Clusterbenutzer können jetzt den PVC (Persistent Volume Claim) an ihre Bereitstellungen anhängen und mit dem Lesen und Schreiben in dem PV-Objekt (Persistent Volume-Objekt) beginnen.

PVC beim Erstellen einer statusabhängige Gruppe mithilfe der dynamischen Bereitstellung erstellen

Verwenden Sie diese Option, wenn bei der Erstellung einer statusabhängigen Gruppe automatisch ein PVC erstellt werden soll.

Vorbereitende Schritte: Melden Sie sich bei Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

1. Stellen Sie sicher, dass alle vorhandenen statusabhängigen Gruppen vollständig bereitgestellt werden. Wenn das Bereitstellen einer statusabhängigen Gruppe noch nicht abgeschlossen ist, können Sie nicht mit dem Erstellern Ihrer statusabhängigen Gruppe beginnen. Sie müssen warten, bis alle statusabhängigen Gruppen im Cluster vollständig bereitgestellt wurden, um unerwartete Ergebnisse zu vermeiden. Listen Sie vorhandene statusabhängige Gruppen im Cluster auf.

   kubectl get statefulset --all-namespaces
   

   Beispielausgabe

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. Zeigen Sie den Podstatus jeder einzelnen statusabhängigen Gruppe an, um sicherzustellen, dass die Bereitstellung der statusabhängigen Gruppe abgeschlossen ist.

   kubectl describe statefulset <statefulset_name>
   

   Beispielausgabe

   Name:               nginx
   Namespace:          default
   CreationTimestamp:  Fri, 05 Oct 2022 13:22:41 -0400
   Selector:           app=nginx,billingType=hourly,region=us-south,zone=dal10
   Labels:             app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   Annotations:        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
   Replicas:           3 desired | 3 total
   Pods Status:        0 Running / 3 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
   Labels:  app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   

   Eine statusabhängige Gruppe wird vollständig bereitgestellt, wenn die Anzahl der Replikate, die im Abschnitt Replicas (Replikate) der CLI-Ausgabe enthalten sind, mit der Anzahl der aktiven Pods im Abschnitt Pods Status (Podstatus) übereinstimmt. Wenn eine statusabhängige Gruppe noch nicht vollständig bereitgestellt wird, müssen Sie warten, bis die Bereitstellung abgeschlossen ist, bevor Sie fortfahren können.

3. Erstellen Sie eine Konfigurationsdatei für die statusabhängige Gruppe und den Service, den Sie verwenden, um die statusabhängige Gruppe zugänglich zu machen.

   Beispiel für eine statusabhängige Gruppe, die eine Zone angibt. Im folgenden Beispiel wird veranschaulicht, wie NGINX als statusabhängige Gruppe mit drei Replikaten bereitgestellt wird. Für jedes Replikat wird eine File Storage for ClassicEinheit mit 20 Gi basierend auf den Spezifikationen in der Speicherklasse ibmc-file-retain-bronze bereitgestellt. Alle Speichereinheiten werden in der Zone dal10 bereitgestellt. Da kein Zugriff auf File Storage for Classic über andere Zonen möglich ist, werden alle Replikate der statusabhängigen Gruppe auch auf Workerknoten bereitgestellt, die sich in dal10 befinden.

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
    name: nginx
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: Parallel
     selector:
       matchLabels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol
             mountPath: /usr/share/nginx/html
       volumeClaimTemplates:
       - metadata:
          name: myvol
         spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 20Gi
              iops: "300" #required only for performance storage
          storageClassName: ibmc-file-retain-bronze
   

   Beispiel für eine statusabhängige Gruppe mit Anti-Affinitätsregel und verzögerter File Storage for Classic-Erstellung. Im folgenden Beispiel wird veranschaulicht, wie NGINX als statusabhängige Gruppe mit drei Replikaten bereitgestellt wird. Die statusabhängige Gruppe gibt die Region und Zone nicht an, in der der File Storage for Classic erstellt wird. Stattdessen verwendet die statusabhängige Gruppe eine Anti-Affinität-Regel, um sicherzustellen, dass die Pods auf Workerknoten und Zonen verteilt werden. Die Anti-Affinität für Workerknoten wird durch Definieren der Bezeichnung (Label) app: nginx erreicht. Diese Bezeichnung weist den Kubernetes-Scheduler an, keinen Pod auf einem Workerknoten zu planen, wenn ein Pod mit derselben Bezeichnung auf diesem Workerknoten ausgeführt wird. Die Bezeichnung topologykey: failure-domain.beta.kubernetes.io/zone schränkt diese Anti-Affinität-Regel noch weiter ein und verhindert, dass der Pod auf einem Workerknoten geplant wird, der sich in derselben Zone wie ein Workerknoten befindet, der bereits einen Pod mit der Bezeichnung app: nginx ausführt. Für jeden Pod einer statusabhängigen Gruppe werden zwei PVCs wie im Abschnitt volumeClaimTemplates definiert erstellt, jedoch wird die Erstellung der File Storage for Classic-Instanzen verzögert, bis ein Pod der statusabhängigen Gruppe geplant wird, der den Speicher verwendet. Diese Konfiguration wird als topologiebewusste Volume-Planung bezeichnet.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: web
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: "Parallel"
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: app
                     operator: In
                     values:
                     - nginx
                 topologyKey: failure-domain.beta.kubernetes.io/zone
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol1
             mountPath: /usr/share/nginx/html
           - name: myvol2
             mountPath: /tmp1
     volumeClaimTemplates:
     - metadata:
         name: myvol1
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

   Geben Sie uter 'metadata' einen Namen für die statusabhängige Gruppe ein. Der von Ihnen eingegebene Name wird verwendet, um den Namen für Ihren PVC im folgenden Format zu erstellen: <volume_name>-<statefulset_name>-<replica_number>.

   serviceName

   Geben Sie im Abschnitt 'spec' den Namen des Service ein, der verwendet werden soll, um die statusabhängige Gruppe zugänglich zu machen.

   replicas

   Geben Sie die Anzahl der Replikate für die statusabhängige Gruppe ein.

   podManagementPolicy

   Geben Sie die Richtlinie für die Podverwaltung ein, die Sie für die statusabhängige Gruppe verwenden möchten. Wählen Sie eine der folgenden Optionen aus.

   • OrderedReady: Bei Verwendung dieser Option werden die Replikate der statusabhängigen Gruppe nacheinander bereitgestellt. Beispiel: Wenn Sie drei Replikate angeben, wird von Kubernetes der PVC für das erste Replikat erstellt, bis zur Bindung des PVC gewartet, das Replikat der statusabhängigen Gruppe bereitgestellt und der PVC an das Replikat angehängt. Wenn die Bereitstellung abgeschlossen ist, wird das zweite Replikat bereitgestellt. Weitere Informationen zu dieser Option finden Sie unter „ OrderedReady-Pod-Verwaltung “.
   • Parallel: Mit dieser Option wird die Bereitstellung aller statusabhängigen Gruppen-Replikate gleichzeitig gestartet. Wenn von Ihrer App die parallele Bereitstellung von Replikaten unterstützt wird, können Sie mit dieser Option Bereitstellungszeit für die PVCs und Replikate der statusabhängigen Gruppe sparen.

   matchLabels

   Geben Sie im Abschnitt 'spec: selector' alle Bezeichnungen ein, die Sie in die statusabhängige Gruppe und in den PVC einschließen möchten. Bezeichnungen, die Sie im volumeClaimTemplates Ihrer statusabhängigen Gruppe angeben, werden von Kubernetes nicht berücksichtigt. Sehen Sie sich die folgenden Musterbezeichnungen an.

   • region und zone: Falls alle Replikate der statusabhängigen Gruppe und PVCs in einer bestimmten Zone erstellt werden sollen, fügen Sie beide Bezeichnungen hinzu. Sie können die Zone und Region auch in der Speicherklasse angeben, die Sie verwenden. Wenn Sie keine Zone und keine Region angeben und über einen Mehrzonencluster verfügen, wird die Zone, in der Ihr Speicher bereitgestellt wird, im Umlaufverfahren ausgewählt, um Datenträgeranforderungen gleichmäßig auf alle Zonen zu verteilen.
   • billingType: Geben Sie den Abrechnungstyp ein, den Sie für die PVCs verwenden möchten. Sie können zwischen "Stündlich" (hourly) und "Monatlich" (monthly) auswählen. Wenn Sie diese Bezeichnung nicht angeben, werden alle PVCs mit einem stündlichen Abrechnungstyp erstellt.

   labels

   Geben Sie im Abschnitt mit den Metadaten der Spezifikationsvorlage dieselben Bezeichnungen ein, die Sie im Abschnitt spec.selector.matchLabels hinzugefügt haben.

   affinity

   Geben Sie im Abschnitt 'spec: affinity' Ihre Anti-Affinität-Regel an, um sicherzustellen, dass Ihre Pods der statusabhängigen Gruppe auf Workerknoten und Zonen verteilt werden. Das Beispiel zeigt eine Anti-Affinität-Regel, bei der der Pod der statusabhängigen Gruppe es bevorzugt, nicht auf einem Workerknoten geplant zu werden, auf dem ein Pod ausgeführt wird, der die Bezeichnung app: nginx hat. Die Bezeichnung topologykey: failure-domain.beta.kubernetes.io/zone schränkt diese Anti-Affinitätsregel noch weiter ein und verhindert, dass der Pod auf einem Workerknoten geplant wird, wenn sich der Workerknoten in derselben Zone wie ein Pod befindet, der die Bezeichnung app: nginx hat. Durch die Verwendung dieser Anti-Affinitätsregel können Sie Anti-Affinität über Workerknoten und Zonen hinweg erreichen.

   name

   Geben Sie im Abschnitt 'spec: volumeClaimTemplates: metadata' einen Namen für Ihren Datenträger ein. Verwenden Sie den Namen, den Sie im Abschnitt spec.containers.volumeMount.name definiert haben. Der hier eingegebene Name wird verwendet, um den Namen für Ihren PVC im Format <volume_name>-<statefulset_name>-<replica_number> zu erstellen.

   storage

   Geben Sie im Abschnitt 'spec: volumeClaimTemplates: spec: resources: requests' die Größe von File Storage for Classic in Gigabyte (Gi) ein.

   iops

   Falls Sie Leistungsspeicher (Performance-Speicher) bereitstellen möchten, geben Sie im Abschnitt 'spec: volumeClaimTemplates: spec: resources: requests' die Anzahl der IOPS (E/A-Operationen pro Sekunde) ein. Wenn Sie eine Endurance-Speicherklasse verwenden und einen IOPS-Wert angeben, wird der IOPS-Wert ignoriert. Stattdessen wird der in der Speicherklasse angegebene IOPS-Wert verwendet.

   storageClassName

   Geben Sie im Abschnitt 'spec: volumeClaimTemplates: spec' den Namen der Speicherklasse ein, die Sie für die Bereitstellung von Blockspeicher verwenden möchten. Um vorhandene Speicherklassen aufzulisten, führen Sie den Befehl „ kubectl get sc | grep file “ aus. Wenn Sie keine Speicherklasse angeben, wird der PVC mit der Standardspeicherklasse erstellt, die in Ihrem Cluster festgelegt ist. Stellen Sie sicher, dass von der Standardspeicherklasse der Bereitsteller ibm.io/ibmc-file verwendet wird, damit die statusabhängige Gruppe mit File Storage for Classic bereitgestellt wird.

4. Erstellen Sie die statusabhängige Gruppe.

   kubectl apply -f statefulset.yaml
   

5. Warten Sie, bis die statusabhängige Gruppe bereitgestellt ist.

   kubectl describe statefulset <statefulset_name>
   

Wenn Sie den aktuellen Status der PVCs anzeigen möchten, führen Sie kubectl get pvc aus. Der Name Ihrer PVC ist als <volume_name>-<statefulset_name>-<replica_number> formatiert.

Statische Bereitstellung: Vorhandenen PVC mit einer statusabhängigen Gruppe verwenden

Sie können die PVCs vor der Erstellung der statusabhängigen Gruppe vorab bereitstellen oder die vorhandenen PVCs mit der statusabhängigen Gruppe verwenden.

Wenn Sie die PVCs dynamisch beim Erstellen der statusabhängigen Gruppe bereitstellen, wird der Name des PVC auf der Basis der Werte zugeordnet, die Sie in der YAML-Datei für die statusabhängige Gruppe verwendet haben. Wenn von der statusabhängigen Gruppe vorhandene PVCs verwendet werden sollen, muss der Name der PVCs mit dem Namen übereinstimmen, der automatisch bei Verwendung der dynamischen Bereitstellung verwendet werden würde.

Vorbereitende Schritte: Melden Sie sich bei Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

1. Wenn Sie den PVC vorab bereitstellen wollen, bevor Sie die statusabhängige Gruppe erstellen, führen Sie die Schritte 1 bis 3 unter File Storage for Classic zu Apps hinzufügen aus, um einen PVC für jedes Replikat der statusabhängigen Gruppe zu erstellen. Stellen Sie sicher, dass Sie Ihren PVC mit einem Namen im folgenden Format erstellen: <volume_name>-<statefulset_name>-<replica_number>.

<volume_name>

Verwenden Sie den Namen, den Sie im Abschnitt spec.volumeClaimTemplates.metadata.name Ihrer statusabhängigen Gruppe angeben möchten (z. B. nginxvol).

<statefulset_name>

Verwenden Sie den Namen, den Sie im Abschnitt metadata.name Ihrer statusabhängigen Gruppe angeben möchten (z. B. nginx_statefulset).

<replica_number>

Geben Sie die Nummer Ihres Replikats ein, beginnend mit '0'.

Wenn Sie zum Beispiel drei Replikate für eine statusabhängige Gruppe erstellen müssen, erstellen Sie 3 PVCs mit den folgenden Namen: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 und nginxvol-nginx_statefulset-2.

Wollen Sie einen PVC und einen PV für eine vorhandene File Storage for Classic-Instanz erstellen? Erstellen Sie Ihren PVC und Ihren PV mithilfe der statischen Bereitstellung.

1. Führen Sie die Schritte unter Dynamische Bereitstellung: PVC beim Erstellen einer statusabhängigen Gruppe erstellen aus, um Ihre statusabhängige Gruppe zu erstellen. Der Name Ihres PVC hat das Format <volume_name>-<statefulset_name>-<replica_number>. Stellen Sie sicher, dass Sie die folgenden Werte aus Ihrem PVC-Namen in der Spezifikation der statusabhängigen Gruppe verwenden.

spec.volumeClaimTemplates.metadata.name

Geben Sie die Komponente <volume_name> Ihres PVC-Namens ein.

metadata.name

Geben Sie die Komponente <statefulset_name> Ihres PVC-Namens ein.

spec.replicas

Geben Sie die Anzahl der Replikate ein, die Sie für Ihre statusabhängige Gruppe erstellen möchten. Die Anzahl der Replikate muss mit der Anzahl der PVCs identisch sein, die Sie zuvor erstellt haben.

Wenn sich Ihre PVCs in verschiedenen Zonen befinden, fügen Sie keine Regions- oder Zonenbezeichnung in Ihre statusabhängige Gruppe ein.

1. Überprüfen Sie, dass die PVCs in Ihrer statusabhängigen Gruppe Replikat-Pods verwendet werden, indem Sie die Pods in Ihrem Cluster auflisten und die Pods angeben, die zu Ihrer statusabhängigen Gruppe gehören.

   kubectl get pods
   

2. Stellen Sie sicher, dass der vorhandene PVC an das Replikat der statusabhängigen Gruppe angehängt ist. Überprüfen Sie den Wert für ClaimName im Abschnitt Volumes (Datenträger) der CLI-Ausgabe.

   kubectl describe pod <pod_name>
   

   Beispielausgabe

   Name:           nginx-0
   Namespace:      default
   Node:           10.xxx.xx.xxx/10.xxx.xx.xxx
   Start Time:     Fri, 05 Oct 2022 13:24:59 -0400
   ...
   Volumes:
   myvol:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  myvol-nginx-0
   ...
   

Erstellen einer benutzerdefinierten Speicherklasse mit einer bestimmten Version von „ NFS “

1. Erstellen Sie eine angepasste Speicherklasse (custom), die die NFS-Version aufweist, die Sie bereitstellen möchten.

2. Erstellen Sie die Speicherklasse in Ihrem Cluster.

   kubectl apply -f nfsversion_storageclass.yaml
   

3. Überprüfen Sie, dass die angepasste Speicherklasse erstellt wurde.

   kubectl get sc
   

4. Stellen Sie File Storage for Classic mit der angepassten Speicherklasse bereit.

Anpassung Ihrer bestehenden PV an eine andere Version von „ NFS “

1. Rufen Sie den persistenten File Storage for Classic-Datenträger ab, für den die NFS-Version geändert werden soll, und notieren Sie den Namen des persistenten Datenträgers.

   kubectl get pv
   

2. Fügen Sie dem persistenten Datenträger eine Annotation hinzu. Ersetzen Sie <version_number> durch die NFS-Version, die Sie verwenden wollen. Um beispielsweise eine Änderung in NFS Version 3.0 vorzunehmen, geben Sie 3 ein.

   kubectl patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. Löschen Sie den Pod, der den File Storage for Classic verwendet, und erstellen Sie den Pod erneut.

   1. Speichern Sie die YAML-Datei für den Pod auf der lokalen Maschine.

       kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
       ```
   2. Löschen Sie den Pod.
   
   ```sh {: pre}
       kubectl deleted pod <pod_name>
       ```
   3. Erstellen Sie den Pod erneut.
   
   ```sh {: pre}
       kubectl apply -f pod.yaml
       ```
   

4. Warten Sie, bis der Pod bereitgestellt wurde. Der Pod wird vollständig bereitgestellt, wenn der Status in Running geändert wird.

   kubectl get pods
   

5. Melden Sie sich bei Ihrem Pod an.

   kubectl exec -it <pod_name> sh
   

6. Stellen Sie sicher, dass der File Storage for Classic mit der von Ihnen zuvor angegebenen NFS-Version angehängt wurde.

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   Beispielausgabe

   nfs vers=3.0
   

Regelmäßige Snapshots einrichten

Sie können für Ihren File Storage for Classic das Erstellen regelmäßiger Snapshot konfigurieren. Dies ist ein schreibgeschütztes Image, das den Status der Instanz zu einem bestimmten Zeitpunkt erfasst. Um den Snapshot zu speichern, müssen Sie für den Snapshot Speicherplatz im File Storage for Classic anfordern. Snapshots werden in der in derselben Zone vorhandenen Speicherinstanz gespeichert. Sie können Daten von einem Snapshot wiederherstellen, wenn ein Benutzer versehentlich wichtige Daten von dem Datenträger entfernt hat.

Führen Sie die folgenden Schritte aus, um einen Snapshot für Ihren Datenträger zu erstellen.

1. Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

2. Melden Sie sich an der Befehlszeilenschnittstelle ibmcloud sl an.

   ibmcloud sl init
   

3. Listen Sie alle vorhandenen PVs in Ihrem Cluster auf.

   kubectl get pv
   

4. Rufen Sie die Details für das PV ab, für das Snapshotspeicherplatz angefordert werden soll, und notieren Sie sich die Datenträger-ID, die Größe und die E/A-Operationen pro Sekunde (IOPS). Die Datenträger-ID, die Größe und den Wert für die Anzahl E/A-Operationen pro Sekunde finden Sie im Abschnitt Labels der CLI-Ausgabe.

   kubectl describe pv <pv_name>
   

5. Erstellen Sie die Snapshotgröße für den vorhandenen Datenträger mit den Parametern, die Sie im vorherigen Schritt abgerufen haben.

   ibmcloud sl file snapshot-order <volume_ID> --size <size> --tier <iops>
   

6. Warten Sie, bis die Snapshotgröße erstellt wurde. Die Snapshotgröße wird erfolgreich bereitgestellt, wenn sich die Snapshotgröße (GB) in Ihrer CLI-Ausgabe von '0' in die bestellte Größe ändert.

   ibmcloud sl file volume-detail <volume_ID>
   

7. Erstellen Sie einen Snapshot für den Datenträger und notieren Sie die ID des von Sie erstellten Snapshots.

   ibmcloud sl file snapshot-create <volume_ID>
   

8. Überprüfen Sie, dass der Snapshot erfolgreich erstellt wurde.

   ibmcloud sl file snapshot-list <volume_ID>
   

9. Legen Sie den Snapshotplan fest. Weitere Informationen zu den Optionen, die für Ihren Snapshotzeitplan verfügbar sind, finden Sie in der CLI-Dokumentation.

   ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
   

10. Um Daten von einem Snapshot auf einem vorhandenen Datenträger wiederherzustellen, führen Sie den folgenden Befehl aus.

    ibmcloud sl file snapshot-restore <volume_ID> <snapshot_ID>
    

Replizieren von Snapshots in eine andere Zone

Um Daten vor einem Zonenausfall zu schützen, können Sie in einer Instanz von File Storage for Classic, die in einer anderen Zone konfiguriert ist, Snapshots replizieren.

Daten können nur aus dem primären Speicher an den Sicherungsspeicher repliziert werden. Sie können keine replizierte File Storage for Classic-Instanz an einen Cluster anhängen. Wenn Ihr primärer Speicher fehlschlägt, können Sie Ihren replizierten Sicherungsspeicher manuell als primären Speicher festlegen. Anschließend können Sie ihn an den Cluster anhängen. Nachdem Ihr primärer Speicher wiederhergestellt wurde, können Sie die Daten aus dem Sicherungsspeicher wiederherstellen.

Speicher duplizieren

Sie können Ihre Instanz von File Storage for Classic in derselben Zone duplizieren, in der sich auch die ursprüngliche Speicherinstanz befindet.

Ein Duplikat hat dieselben Daten wie die Originalspeicherinstanz zu dem Zeitpunkt, an dem das Duplikat erstellt wurde. Verwenden Sie das Duplikat - im Gegensatz zu den Replikaten - als unabhängige Speicherinstanz. Zur Vorbereitung einer Duplizierung müssen Sie zunächst Snapshots für den Datenträger erstellen.

Daten in IBM Cloud® Object Storage sichern

Sie können das ibm-backup-restore Helm-Diagramm verwenden, um einen Sicherungs- und Wiederherstellungspod in Ihrem Cluster zu erstellen.

Dieser Pod enthält ein Script zur Ausführung einer einmaligen oder regelmäßigen Sicherung für alle PVCs (Persistent Volume Claims) in Ihrem Cluster. Die Daten werden in Ihrer IBM Cloud® Object Storage-Instanz gespeichert, die Sie in einer Zone konfiguriert haben.

Damit Ihre Daten noch besser hoch verfügbar sind und um Ihre App vor einem Zonenausfall zu schützen, konfigurieren Sie eine zweite IBM Cloud® Object Storage-Instanz und replizieren Sie die Daten zonenübergreifend. Falls Sie Daten von Ihrer IBM Cloud® Object Storage-Instanz wiederherstellen müssen, verwenden Sie das Wiederherstellungsscript, das mit dem Helm-Chart bereitgestellt wird.

Kopieren von Daten in und aus Pods und Containern

Mit dem Befehl „ kubectl cp “ können Sie Dateien und Verzeichnisse in Pods oder bestimmte Container in Ihrem Cluster kopieren oder aus diesen heraus kopieren.

Vorbereitende Schritte: Melden Sie sich bei Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest. Wenn Sie keinen Container mit -c angeben, verwendet der Befehl den ersten verfügbaren Container im Pod.

Kopieren Sie Daten von Ihrem lokalen Rechner auf einen Pod in Ihrem Cluster.

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>

Kopieren Sie Daten von einem Pod in Ihrem Cluster auf Ihren lokalen Rechner.

kubectl cp <namespace>/<pod>:<pod_filepath>/<filename></var> <local_filepath>/<filename>

Kopieren Sie Daten von Ihrem lokalen Rechner in einen bestimmten Container, der in einem Pod Ihres Clusters läuft.

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath> -c CONTAINER

Topologieorientierten Speicher erstellen

Zur Verwendung von File Storage for Classic in einem Mehrzonencluster muss Ihr Pod in derselben Zone wie Ihre File Storage for Classic-Instanz geplant werden, damit Sie Schreib- und Leseoperationen auf dem Datenträger ausführen können. Bevor die topologieorientierte Datenträgerplanung von Kubernetes eingeführt wurde, wurde die File Storage for Classic-Instanz beim Erstellen eines PVC automatisch durch die dynamische Bereitstellung Ihres Speichers erstellt. Anschließend wurde vom Kubernetes-Scheduler nach dem Erstellen Ihres Pods versucht, den Pod auf einem Workerknoten in demselben Rechenzentrum wie Ihre File Storage for Classic-Instanz bereitzustellen.

Eine Erstellung der File Storage for Classic-Instanz ohne Kenntnis der Einschränkungen des Pods kann zu unerwünschten Ergebnissen führen. Zum Beispiel könnte Ihr Pod möglicherweise nicht auf demselben Workerknoten wie Ihr Speicher geplant werden, weil der Workerknoten über keine ausreichenden Ressourcen verfügt oder weil der Workerknoten einen Taint hat und das Planen des Pods nicht zulässt. Bei der topologieorientierten Datenträgerplanung wird die File Storage for Classic-Instanz verzögert, bis der erste Pod erstellt wird, der den Speicher verwendet.

Die folgenden Beispiele zeigen, wie Speicherklassen erstellt werden, die die Erstellung der File Storage for Classic-Instanz verzögern, bis der erste Pod, der diesen Speicher verwendet, zur Terminierung bereit ist. Zur Verzögerung der Erstellung müssen Sie die Option volumeBindingMode: WaitForFirstConsumer einschließen. Wenn Sie diese Option nicht angeben, wird volumeBindingMode automatisch auf Immediate festgelegt und die File Storage for Classic-Instanz wird erstellt, wenn Sie den PVC erstellen.

Beispiel für Endurance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-bronze-delayed
parameters:
  billingType: hourly
  classVersion: "2"
  iopsPerGB: "2"
  sizeRange: '[20-12000]Gi'
  type: Endurance
  provisioner: ibm.io/ibmc-file
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

Beispiel für Performance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
 billingType: "hourly"
 classVersion: "2"
 sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
 type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Zone für Mehrzonencluster angeben

Wenn Sie Ihren File Storage for Classic in einer bestimmten Zone erstellen wollen, können Sie die Zone und die Region in einer angepassten Speicherklasse angeben.

Verwenden Sie die angepasste Speicherklasse, wenn Sie File Storage for Classic statisch in einer bestimmten Zone bereitstellen wollen. In allen anderen Fällen geben Sie die Zone direkt im PVC an.

Wenn Sie die angepasste Speicherklasse erstellen, geben Sie dieselbe Region und Zone an, in der sich auch Ihr Cluster und Ihre Workerknoten befinden. Um die Region Ihres Clusters abzurufen, führen Sie ibmcloud ks cluster get --cluster <cluster_name_or_ID> aus und suchen Sie im Master-URL nach dem Regionspräfix, z. B. eu-de in https://c2.eu-de.containers.cloud.ibm.com:11111. Führen Sie ibmcloud ks worker ls --cluster <cluster_name_or_ID> aus, um die Zone Ihres Workerknotens abzurufen.

Beispiel für Endurance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-silver-mycustom-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
reclaimPolicy: Delete
volumeBindingMode: Immediate

Beispiel für Performance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  billingType: "hourly"
  classVersion: "2"
  sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
  type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: Immediate

NFS-Standardversion ändern

Mit der folgenden angepassten Speicherklasse können Sie die NFS-Version definieren, die Sie bereitstellen wollen. Um beispielsweise NFS Version 3.0 bereitzustellen, ersetzen Sie <nfs_version> durch 3.0.

Beispiel für Endurance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

Beispiel für Performance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  classVersion: "2"
  sizeIOPSRange: |-
    "[20-39]Gi:[100-1000]"
    "[40-79]Gi:[100-2000]"
    "[80-99]Gi:[100-4000]"
    "[100-499]Gi:[100-6000]"
    "[500-999]Gi:[100-10000]"
    "[1000-1999]Gi:[100-20000]"
    "[2000-2999]Gi:[200-40000]"
    "[3000-3999]Gi:[200-48000]"
    "[4000-7999]Gi:[300-48000]"
    "[8000-9999]Gi:[500-48000]"
    "[10000-12000]Gi:[1000-48000]"
  mountOptions: nfsvers=<nfs_version>

Erläuterungen zu den Optionen beim Entfernen von Speicher

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 dynamisch mit einer Speicherklasse bereitgestellt haben, für die „ reclaimPolicy: Delete “ festgelegt ist, werden Ihr PVC, Ihr PV und die Speicherinstanz automatisch gelöscht, sobald Sie den Cluster löschen. Bei statisch bereitgestelltem Speicher oder Speicher, den Sie mit einer Speicherklasse bereitgestellt haben, die „ reclaimPolicy: Retain “ festlegt, werden das PVC und das PV beim Löschen des Clusters entfernt, Ihre Speicherinstanz und Ihre Daten bleiben jedoch 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 statisch bereitgestelltem Speicher oder bei Speicher, den Sie mit einer Speicherklasse bereitgestellt haben, für die „ reclaimPolicy: Retain “ festgelegt ist, müssen Sie das PVC, das PV und die Speicherinstanz manuell entfernen, um weitere Kosten zu vermeiden.

Wie wird die Abrechnung beendet, nachdem ich meinen Speicherplatz 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 Persistent-Storage-Instanz manuell über die „ IBM Cloud “-Konsole oder die CLI stornieren, erfolgt die Abrechnung wie folgt:

  • 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 den 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 immer 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.
• Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

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

1. 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.

   kubectl 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
   

2. Überprüfen Sie für die Speicherklasse die Einstellungen für ReclaimPolicy und billingType.

   kubectl 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.

3. 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.

   kubectl 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
   

4. Entfernen Sie den Pod, der den PVC verwendet. Wenn der Pod Teil einer Bereitstellung ist, entfernen Sie die Bereitstellung.

   kubectl delete pod <pod_name>
   

5. Überprüfen Sie, dass der Pod entfernt wurde.

   kubectl get pods
   

6. Entfernen Sie die PVC.

   kubectl delete pvc <pvc_name>
   

7. Ü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.

   kubectl get pv <pv_name>
   

8. Wenn der persistente Datenträger nicht entfernt wurde, entfernen Sie ihn manuell.

   kubectl delete pv <pv_name>
   

9. Überprüfen Sie, dass der persistente Datenträger entfernt wurde.

   kubectl get pv
   

10. Listen Sie die physische Speicherinstanz auf, die von Ihrem persistenten Datenträger referenziert wurde, und notieren Sie die id der physischen Speicherinstanz.

    ibmcloud sl file volume-list --columns id  --columns notes | grep <pv_name>
    

    Beispielausgabe für File Storage for Classic.

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

    "plugin":"ibm-file-plugin-5b55b7b77b-55bb7"

    Das vom Cluster verwendete Speicher-Plug-in.

    "region":"us-south"

    Die Region, in der sich Ihr Cluster befindet.

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    Die Cluster-ID, die der Speicherinstanz zugeordnet ist.

    "type":"Endurance"

    Der Typ des Datei- oder Blockspeichers (Endurance oder Performance).

    "ns":"default"

    Der Namensbereich, in dem die Speicherinstanz bereitgestellt wird

    "pvc":"mypvc"

    Der Name der PVC, die der Speicherinstanz zugeordnet ist.

    "pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"

    Der PV, der der Speicherinstanz zugeordnet ist.

    "storageclass":"ibmc-file-gold"

    Der Typ der Speicherklasse: 'Bronze', 'Silber', 'Gold' oder 'Angepasst'.

11. Entfernen Sie die physische Speicherinstanz.

    ibmcloud sl file volume-cancel <classic_file_id>
    

12. Überprüfen Sie, dass die physische Speicherinstanz entfernt wurde.

    ibmcloud sl file volume-list
    

Der Löschvorgang kann bis zu 72 Stunden in Anspruch nehme.