IBM Cloud Block Storage-Plug-in aktualisieren

Sie können ein Upgrade des vorhandenen IBM Cloud Block Storage-Plug-ins auf die aktuelle Version durchführen.

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. Aktualisieren Sie das Helm-Repository, um die aktuelle Version aller Helm-Charts in diesem Repository abzurufen.

   helm repo update
   

2. Optional: Laden Sie das aktuellste Helm-Chart auf Ihre lokale Maschine herunter. Extrahieren Sie anschließend das Paket und überprüfen Sie die Datei release.md auf die neuesten Releaseinformationen.

   helm pull iks-charts/ibmcloud-block-storage-plugin --untar
   

3. Suchen Sie den Releasenamen und den Namensbereich des Blockspeicher-Helm-Charts, das Sie in Ihrem Cluster installiert haben.

   helm ls -A
   

   Beispielausgabe

   NAME            NAMESPACE   REVISION    UPDATED                             STATUS      CHART                                   APP VERSION
   block-plugin    default     1           2022-01-21 09:02:46.11622 -0500 EST deployed        bmcloud-block-storage-plugin-v2.1.5
   

4. Führen Sie ein Upgrade des IBM Cloud Block Storage-Plug-ins auf die aktuelle Version durch. Geben Sie den Releasenamen und den Namensbereich an, die Sie zuvor abgerufen haben.

   helm upgrade RELEASE-NAME iks-charts/ibmcloud-block-storage-plugin -n NAMESPACE
   

5. Optional: Wenn Sie das Plug-in aktualisieren, wird die Festlegung auf die Speicherklasse default aufgehoben. Wenn Sie statt der Speicherklasse 'standard' eine Speicherklasse Ihrer Wahl festlegen möchten, führen Sie den folgenden Befehl aus.

   kubectl patch storageclass STORAGECLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

IBM Cloud Block Storage-Plug-in entfernen

Wenn Sie IBM Cloud Block Storage in Ihrem Cluster nicht bereitstellen und verwenden wollen, können Sie das Diagramm Helm deinstallieren.

Durch das Entfernen des Plug-ins werden keine vorhandenen PVCs, PVs oder Daten entfernt. Wenn Sie das Plug-in entfernen, werden alle zugehörigen Pods und Dämongruppen aus Ihrem Cluster entfernt. Sie können keinen neuen Blockspeicher für Ihren Cluster bereitstellen oder vorhandene PVCs und PVs für Blockspeicher verwenden, nachdem Sie das Plug-in entfernt haben.

Vorbereitende Schritte:

• Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
• Stellen Sie sicher, dass Ihr Cluster keine PVCs oder PVs enthält, die Blockspeicher verwenden.

Gehen Sie wie folgt vor, um das Plug-in zu entfernen:

1. Suchen Sie den Releasenamen und den Namensbereich des Blockspeicher-Helm-Charts, das Sie in Ihrem Cluster installiert haben.

   helm ls -A
   

   Beispielausgabe

   NAME            NAMESPACE   REVISION    UPDATED                             STATUS   CHART                                  APP VERSION
   block-plugin    default     1           2022-01-21 09:02:46.11622 -0500 EST deployed    ibmcloud-block-storage-plugin-v2.1.5
   

2. Löschen Sie das IBM Cloud Block Storage-Plug-in.

   helm uninstall NAME -n kube-system
   

3. Überprüfen Sie, dass die Blockspeicher-Pods entfernt wurden.

   kubectl get pods -n kube-system | grep block
   

   Das Entfernen der Pods war erfolgreich, wenn in Ihrer CLI-Ausgabe keine Pods angezeigt werden.

4. Überprüfen Sie, dass die Blockspeicherklassen entfernt wurden. Das Entfernen der Speicherklassen war erfolgreich, wenn in Ihrer CLI-Ausgabe keine Speicherklassen angezeigt werden.

   kubectl get sc | grep block
   

Verschlüsseln von Volume-Daten mithilfe einer eigenen Speicherklasse

Sie können Apps bereitstellen, die verschlüsselte Volumes verwenden, indem Sie zunächst eine eigene Speicherklasse erstellen.

Anhand der folgenden Schritte wird erläutert, wie eine angepasste, verschlüsselte Speicherklasse erstellt wird, die Sie verwenden können, um mehrere verschlüsselte Blockspeicherinstanzen mit derselben Konfiguration zu erstellen. Wenn Sie einen verschlüsselten PVC mithilfe einer von IBM bereitgestellten Speicherklasse erstellen wollen, können Sie zu diesem Zweck direkt in Ihrem PVC auf die Key Protect-Berechtigungsnachweise verweisen.

1. Entscheiden Sie sich für eine Speicherkonfiguration.

2. Erstellen Sie Ihre eigene Speicherklasse, die eine verschlüsselte Blockspeicherinstanz bereitstellt, indem Sie eine der von „ IBM “ bereitgestellten Speicherklassen als Grundlage verwenden. Sie können die Details einer Speicherklasse abrufen, indem Sie kubectl get sc <storageclass_name> -o yamlausführen. Das folgende Beispiel basiert auf der Speicherklasse ibmc-block-retain-bronze.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <name> # Enter the name of the storage class. Example: my_custom_storageclass
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
     encrypted: "true" # Enter "true" to enable encryption.
     encryptionKeySecret: <secret_name> # # #nter the name of the secret that you created earlier.Example: my_secret
     encryptionKeyNamespace: <namespace> # # #nter the namespace where you created your secret. Example: default
   provisioner: ibm.io/ibmc-block
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   

3. Erstellen Sie die Speicherklasse in Ihrem Cluster.

   kubectl apply -f storageclass.yaml
   

4. Fügen Sie „ Block Storage for Classic “ zu Ihrer App hinzu, indem Sie mithilfe Ihrer eigenen Speicherklasse ein PVC erstellen.

5. Überprüfen Sie die Verschlüsselung Ihrer Block Storage for Classic-Datenträger.

Erstellen Sie einen PVC, der auf Ihren geheimen Block Storage for Classic-Schlüssel verweist.

Sie können eine verschlüsselte Instanz von Block Storage for Classic bereitstellen, indem Sie einen PVC erstellen, für den der geheime Kubernetes-Schlüssel angegeben wird, in dem Ihre Key Protect-Berechtigungsnachweise enthalten sind.

Die folgenden Schritte zeigen, wie Sie in Ihrem PVC auf Ihre Key Protect-Berechtigungsnachweise verweisen können, um eine verschlüsselte Block Storage for Classic-Instanz zu erstellen. Um mehrere verschlüsselte Datenträger zu erstellen, ohne die Key Protect-Berechtigungsnachweise in jedem einzelnen PVC anzugeben, können Sie eine angepasste, verschlüsselte Speicherklasse erstellen.

1. Überprüfen Sie die bereitgestellten Block Storage for Classic-Speicherklassen, um zu ermitteln, welche Speicherklasse die Anforderungen Ihrer App am besten erfüllt. Wenn die bereitgestellten Speicherklassen Ihre App-Anforderungen nicht erfüllen, können Sie eine eigene individuelle Speicherklasse erstellen.

2. Erstellen Sie eine PVC-Konfigurationsdatei namens pvc.yaml, die auf den geheimen Kubernetes-Schlüssel verweist, in dem Sie die Key Protect-Serviceberechtigungsnachweise gespeichert haben. Informationen zum Erstellen dieses geheimen Schlüssels finden Sie unter Verschlüsselung für Block Storage for Classic einrichten.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: <pvc_name> # Enter a name for your PVC.
     annotations:
     volume.beta.kubernetes.io/storage-class: "<storage_class>" # Enter a storage class. To see a list of storageclasses run `kubectl get storageclasses`.
     labels:
       encrypted: "true"
       encryptionKeyNamespace: <namespace> # Enter the namespace where your secret was created.
       encryptionKeySecret: <secret_name> # Enter the name of the secret you created.
   spec:
     accessModes:
       - ReadWriteOnce
       resources:
       requests:
           storage: 20Gi
   

3. Erstellen Sie die PVC in Ihrem Cluster.

   kubectl apply -f pvc.yaml
   

4. Überprüfen Sie den Status Ihres PVC.

   kubectl get pvc
   

5. Warten Sie, bis Ihr PVC gebunden worden ist, und erstellen Sie dann eine Bereitstellung, die Ihren PVC verwendet.

6. Überprüfen Sie die Verschlüsselung Ihrer Block Storage for Classic-Datenträger.

Verschlüsselung Ihrer Block Storage for Classic-Datenträger überprüfen

Sie können die Verschlüsselung Ihrer Datenträger anhand des Datenträgermountpfads überprüfen.

1. Melden Sie sich bei Ihrem App-Pod an. Ersetzen Sie <pod_name> durch den Namen des Pods, der Ihren verschlüsselten Block Storage for Classic-Datenträger anhängt.

   kubectl exec <pod_name> -it bash
   

2. Listen Sie das Dateisystem Ihres Pods auf.

   df -h
   

3. Überprüfen Sie den Dateisystempfad für Ihren verschlüsselten Block Storage for Classic-Datenträger.

   • Verschlüsselte Datenträger haben die Pfadstruktur /dev/mapper/<pvc-ID_encrypted>. In diesem Beispiel wird der verschlüsselte Datenträger an den Dateipfad /test in dem Pod angehängt.

       Filesystem                                            Size  Used Avail Use% Mounted on
       overlay                                                98G  8.2G   85G   9% /
       tmpfs                                                  64M     0   64M   0% /dev
       tmpfs                                                 2.0G     0  2.0G   0% /sys/fs/cgroup
       /dev/mapper/pvc-a011a111-1111-1111-111a-aaa1a1111a11_encrypted   20G   45M   20G   1% /test
       ```
   * Unverschlüsselte Datenträger haben die Pfadstruktur `dev/mapper/<random_string>`.
   
   ```sh {: screen}
       Filesystem                                     Size  Used Avail Use% Mounted on
       overlay                                         98G   16G   78G  17% /
       tmpfs                                           64M     0   64M   0% /dev
       tmpfs                                          7.9G     0  7.9G   0% /sys/fs/cgroup
       /dev/mapper/3600a09803830476e733f4e477370716e   24G   45M   24G   1% /test
       ```
   

Durch das Entfernen Ihres geheimen Kubernetes-Schlüssels wird der Zugriff auf die Datenträgerdaten nicht widerrufen. Wenn Sie eine Podbereitstellung (Bereitstellung nur für einen Pod) erstellt haben, müssen Sie den entsprechenden Pod löschen. Wenn Sie eine Bereitstellung erstellt haben, müssen Sie die entsprechende Bereitstellung löschen.

Informationen des vorhandenen Blockspeichers abrufen

1. Rufen Sie einen API-Schlüssel für Ihr Konto der IBM Cloud-Infrastruktur ab oder generieren Sie einen API-Schlüssel.

   1. Melden Sie sich beim Infrastrukturportal „ IBM Cloud “ an.
   2. Wählen Sie Konto, dann Benutzer und dann Benutzerliste aus.
   3. Suchen Sie nach Ihrer Benutzer-ID.
   4. Klicken Sie in der Spalte API-SCHLÜSSEL auf Generieren, um einen API-Schlüssel zu generieren, oder auf Anzeigen, um Ihren vorhandenen API-Schlüssel anzuzeigen.

2. Rufen Sie den API-Benutzernamen für Ihr Konto der IBM Cloud-Infrastruktur ab.

   1. Wählen Sie im Menü Benutzerliste Ihre Benutzer-ID aus.
   2. Suchen Sie im Abschnitt API-Zugriffsinformationen nach Ihrem API-Benutzernamen.

3. Melden Sie sich beim Befehlszeilen-Plug-in der IBM Cloud-Infrastruktur an.

   ibmcloud sl init
   

4. Wählen Sie die Authentifizierung anhand des Benutzernamens und des API-Schlüssels für Ihr Konto der IBM Cloud-Infrastruktur aus.

5. Geben Sie den Benutzernamen und den API-Schlüssel ein, die Sie in den vorherigen Schritten abgerufen haben.

6. Listen Sie verfügbare Blockspeichereinheiten auf.

   ibmcloud sl block volume-list
   

   Beispielausgabe

   id          username              datacenter   storage_type                capacity_gb   bytes_used   lunId   
   11111111    IBM01AAA1111111-1     wdc07        endurance_block_storage     45            -            2      
   

7. Rufen Sie die Datenträgerdetails ab. Ersetzen Sie <volume_ID> durch die ID des Blockspeicherdatenträgers, die Sie in Schritt 6 abgerufen haben.

   ibmcloud sl block volume-detail <volume_ID>
   

   Beispielausgabe

   ID                         11111111
   User name                  IBM01AAA1111111-1   
   Type                       endurance_block_storage   
   Capacity (GB)              45   
   LUN Id                     2   
   IOPs                       100   
   Datacenter                 wdc07   
   Target IP                  10.XXX.XX.XXX  
   # of Active Transactions   0   
   Replicant Count            0
   

8. Notieren Sie die ID, Capacity, LUN Id, Datacenter und Target IP des Datenträgers, den Sie an Ihren Cluster anhängen möchten. Hinweis: Wenn Sie einen vorhandenen Speicher an einen Cluster anhängen möchten, müssen Sie in derselben Zone, in der sich auch der Speicher befindet, einen Workerknoten haben. Führen Sie ibmcloud ks worker ls --cluster <cluster_name_or_ID> aus, um die Zone Ihres Workerknotens zu überprüfen.

Persistent Volume (PV) und übereinstimmenden Persistent Volume Claim (PVC) erstellen

1. Optional: Wenn Sie Speicher haben, den Sie mit einer retain-Speicherklasse bereitgestellt haben, werden der persistente Datenträger und die physische Speichereinheit nicht entfernt, wenn Sie den PVC entfernen. Zum Wiederverwenden des Speichers in Ihrem Cluster müssen Sie zuerst den persistenten Datenträger entfernen. Listen Sie die vorhandenen PVs auf und suchen Sie den PV, der zu Ihrem persistenten Speicher gehört. Der persistente Datenträger hat den Status "freigegeben" (released).

   kubectl get pv
   

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

   kubectl delete pv <pv_name>
   

3. Überprüfen Sie, ob der PV entfernt wurde.

   kubectl get pv
   

4. Erstellen Sie eine Konfigurationsdatei für Ihren persistenten Datenträger (PV). Schließen Sie die Parameter ein, die Sie zuvor abgerufen haben.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: "block-storage-pv" # Enter a name for your PV. For example, my-static-pv.
     labels:
        failure-domain.beta.kubernetes.io/region: "<region>" # Example us-east.
        failure-domain.beta.kubernetes.io/zone: "<zone>" # Example: wdc04. See /docs/containers?topic=containers-regions-and-zones#zones-sz
   spec:
     capacity:
       storage: "<storage>"
     accessModes:
       - ReadWriteOnce
     flexVolume:
       driver: "ibm/ibmc-block"
       fsType: "<fs_type>" # Enter ext or xfs
       options:
         "Lun": "<Lun_ID>"
         "TargetPortal": "<TargetPortal>"
         "VolumeID": "<VolumeID>"
         "volumeName": "block-storage-pv" # Enter the same value as your PV name from metadata.name
   

   name

   Geben Sie Ihrem PV einen Namen. Beispiel: block-storage-pv. Beachten Sie, dass Sie diesen Wert auch in spec.FlexVolume.options als volumeName eingeben müssen.

   labels

   Geben Sie die Region und die Zone ein, die Sie zuvor abgerufen haben. Zum Anhängen des Speichers an Ihren Cluster müssen Sie mindestens einen Workerknoten in der Region und Zone haben, in der sich auch der persistente Speicher befindet. Zum Abrufen der Datenträgerdetails führen Sie ibmcloud sl block volume-list aus, um die Datenträger-ID abzurufen, und führen Sie anschließend ibmcloud sl block volume-detail <volume_ID> aus, um die Details Ihres Datenträgers abzurufen.

   region

   Geben Sie die Region ein, in der sich Ihr Blockspeicher befindet. Beachten Sie, dass sich Ihr Cluster und Blockspeicher in derselben Region befinden müssen. Führen Sie ibmcloud ks cluster ls aus, um Ihren Clusterstandort zu finden. Weitere Informationen zu den verfügbaren Regionen und Zonen finden Sie unter Regionen und Zonen. Zum Beispiel us-east.

   zone

   Geben Sie die Zone ein, in der sich Ihr Speicherdatenträger befindet. Zum Abrufen der Datenträgerdetails führen Sie ibmcloud sl block volume-list aus, um die Datenträger-ID abzurufen, und führen Sie anschließend ibmcloud sl block volume-detail <volume_ID> aus, um die Details Ihres Datenträgers abzurufen. Beachten Sie, dass zum Zuordnen von Blockspeicher zu Ihrem Cluster ein Workerknoten in derselben Zone verfügbar sein muss wie der Datenträger, den Sie zuordnen möchten. Führen Sie ibmcloud ks worker ls -c <cluster> aus, um die Zonen Ihrer Workerknoten zu suchen. Zum Beispiel wdc04.

   storage

   Geben Sie die Speichergröße des vorhandenen Blockspeicherdatenträgers ein, der Ihrem Cluster zugeordnet werden soll. Die Größe des Speichers muss in Gigabyte angegeben werden, z. B. 20Gi (20 GB) oder 1000Gi (1 TB). Um die Datenträgerdetails abzurufen, führen Sie ibmcloud sl block volume-list aus, um die Datenträger-ID abzurufen, und führen Sie anschließend ibmcloud sl block volume-detail <volume_ID> aus, um die Details Ihres Datenträgers abzurufen.

   fsType

   Geben Sie den Dateisystemtyp ein, der für den vorhandenen Blockspeicher konfiguriert ist. Wählen Sie ext4 oder xfs aus. Wenn Sie diese Option nicht angeben, nimmt der persistente Datenträger standardmäßig den Wert ext4 an. Wenn der falsche Wert für fsType definiert ist, ist zwar die PV-Erstellung erfolgreich, das Anhängen des PVs an einen Pod schlägt jedoch fehl. Zum Abrufen der Datenträgerdetails führen Sie ibmcloud sl block volume-list aus, um die Datenträger-ID abzurufen, und führen Sie anschließend ibmcloud sl block volume-detail <volume_ID> aus, um die Details Ihres Datenträgers abzurufen.

   Lun

   Geben Sie die LUN-ID Ihres Blockspeicherdatenträgers ein. Zum Abrufen der Datenträgerdetails führen Sie ibmcloud sl block volume-list aus, um die Datenträger-ID abzurufen, und führen Sie anschließend ibmcloud sl block volume-detail <volume_ID> aus, um die Details Ihres Datenträgers abzurufen.

   TargetPortal

   Geben Sie die IP-Adresse Ihres Blockspeichers ein. Zum Abrufen des Parameters TargetPortal führen Sie ibmcloud sl block volume-list aus, um die Datenträger-ID abzurufen. Führen Sie anschließend ibmcloud sl block volume-detail <volume_ID> aus und notieren Sie sich die Target IP in der Ausgabe.

   VolumeId

   Geben Sie die ID Ihres Blockspeichers ein. Führen Sie ibmcloud sl block volume-list aus, um die Datenträgerdetails abzurufen.

   volumeName

   Geben Sie denselben Wert wie Ihren PV-Namen ein. Beispiel: block-storage-pv.

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

   kubectl apply -f pv.yaml
   

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

   kubectl get pv
   

7. 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, wird stattdessen automatisch ein neuer PV erstellt.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: block-storage-pvc
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: "20Gi"
     storageClassName: ""
   

8. Erstellen Sie Ihre PVC.

   kubectl apply -f static-pvc.yaml
   

9. Überprüfen Sie, ob Ihr PVC erstellt und an das zuvor erstellte PV gebunden wurde. Dieser Prozess kann einige Minuten dauern.

   kubectl describe pvc static-pvc
   

   Beispielausgabe

   Name:          static-pvc
   Namespace:     default
   StorageClass:  
   Status:        Bound
   

10. Optional Speichern Sie die folgende Beispiel-Pod-Konfiguration als Datei namens pod.yaml.

    apiVersion: v1
    kind: Pod
    metadata:
      name: block-storage
      labels:
        app: block-storage
    spec:
      containers:
        - name: block-storage
          image: nginx
          command: ["/bin/sh"]
          args: ["-c", "while true; do date \"+%Y-%m-%d %H:%M:%S\"; sleep 3600; done"]
          workingDir: /home
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          volumeMounts:
            - name: block-storage-pv
              mountPath: /home
      volumes:
        - name: block-storage-pv
          persistentVolumeClaim:
            claimName: block-storage-pvc
    

11. Erstellen Sie den Pod in Ihrem Cluster.

    kubectl create -f pod.yaml
    

12. Nachdem der Pod den Status Running hat, rufen Sie die Protokolle ab.

    kubectl logs
    

    Beispielausgabe

    2022-01-21 16:11:00
    

Sie haben erfolgreich ein PV (Persistent Volume) erstellt und an einen PVC (Persistent Volume Claim) gebunden. Anschließend haben Sie eine App bereitgestellt, die Blockspeicher verwendet. Clusterbenutzer können nun PVC an Ihre Bereitstellungen anhängen und mit dem Lesen und Schreiben auf dem persistenten Datenträger beginnen.

PVC mit dynamischer Bereitstellung erstellen, wenn Sie eine statusabhängige Gruppe 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.

Führen Sie die folgenden Schritte durch, um zu überprüfen, ob alle vorhandenen statusabhängigen Gruppen in Ihrem Cluster vollständig bereitgestellt wurden. 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.

1. 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. Im folgenden Beispiel wird veranschaulicht, wie NGINX als statusabhängige Gruppe mit drei Replikaten bereitgestellt wird. Für jedes Replikat wird eine 20-Gigabyte-Blockspeichereinheit basierend auf den Spezifikationen bereitgestellt, die in der Speicherklasse ibmc-block-retain-bronze definiert sind. Alle Speichereinheiten werden in der Zone dal10 bereitgestellt. Da von anderen Zonen nicht auf Blockspeicher zugegriffen werden kann, 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" # Enter the region where your cluster is located.
       zone: "dal10"
   template:
     metadata:
     labels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     spec:
     containers:
     - name: nginx
       image: nginx
       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-block-retain-bronze
   

   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 Blockspeicher erstellt wird. Stattdessen verwendet die statusabhängige Gruppe eine Anti-Affinität-Regel, um sicherzustellen, dass die Pods auf Workerknoten und Zonen verteilt werden. Durch die Definition von topologykey: failure-domain.beta.kubernetes.io/zone kann der Kubernetes-Scheduler keinen Pod auf einem Workerknoten planen, wenn sich der Workerknoten in derselben Zone wie ein Pod mit der Bezeichnung app: nginx befindet. Für jeden Pod einer statusabhängigen Gruppe werden zwei PVCs wie im Abschnitt volumeClaimTemplates definiert erstellt, jedoch wird die Erstellung der Blockspeicherinstanzen 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-block-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-block
   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:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
   

   name

   Geben Sie 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 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.

   • 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. Nachfolgend werden Beispiele für Bezeichnungen aufgeführt, die Sie einschließen können:

   • Region und Zone: Wenn alle Replikate und PVCs der statusabhängigen Gruppe 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 die Abrechnungsart ein, die Sie für Ihre 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: template: metadata' 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 des Blockspeichers 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 block “ 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-block verwendet wird, damit die statusabhängige Gruppe mit Blockspeicher 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 unter Verwendung bestehender PVCs mit einem Stateful Set

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 für Ihre statusabhängige Gruppe vorab bereitstellen wollen, bevor Sie die statusabhängige Gruppe erstellen, führen Sie die Schritte 1 bis 3 unter Blockspeicher 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 drei 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 Speichereinheit 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 den 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. Stellen Sie sicher, dass die PVCs in den Replikatpods Ihrer statusabhängigen Gruppe verwendet werden, indem Sie die Pods in Ihrem Cluster auflisten. Suchen Sie die Pods, die zur 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
   ...
   

Regelmäßige Snapshots einrichten

Sie können für Ihren Blockspeicher das Erstellen regelmäßiger Snapshots 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 Blockspeicher anfordern. Snapshots werden in der in derselben Zone vorhandenen Speicherinstanz gespeichert. Sie können Daten aus einer Momentaufnahme wiederherstellen, wenn ein Benutzer versehentlich wichtige Daten aus dem Datenträger entfernt. \n \n **Führen Sie die folgenden Schritte aus, um eine Momentaufnahme 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 Größe und die Anzahl der E/A-Operationen pro Sekunde werden im Abschnitt Labels der CLI-Ausgabe angezeigt.

   kubectl describe pv <pv_name>
   

5. Um die Datenträger-ID zu finden, überprüfen Sie die Annotation ibm.io/network-storage-id der CLI-Ausgabe.

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

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

7. Warten Sie, bis die Snapshotgröße erstellt wurde. Die Snapshotgröße wird erfolgreich bereitgestellt, wenn der Wert für Snapshot Size (GB) (Snapshotgröße (GB)) in der CLI-Ausgabe von "0" in die von Ihnen angeforderte Größe geändert wird.

   ibmcloud sl block volume-detail <volume_ID>
   

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

   ibmcloud sl block snapshot-create <volume_ID>
   

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

   ibmcloud sl block snapshot-list <volume_ID>
   

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

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

    ibmcloud sl block 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 Blockspeicherinstanz, 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 eine replizierte Blockspeicherinstanz nicht 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 Blockspeicherinstanz 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. Erstellen Sie zur Vorbereitung einer Duplizierung zunächst Snapshots für den Datenträger.

Daten in IBM Cloud® Object Storage sichern

Sie können das Helm-Chart ibm-backup-restore verwenden, damit ein Pod für Sicherung und Wiederherstellung in Ihrem Cluster den Betrieb aufnimmt.

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.

Blockspeicher wird mit dem RWO-Zugriffsmodus (ReadWriteOnce) angehängt. This access allows only one pod to be mounted to the block storage at a time. Zum Sichern Ihrer Daten müssen Sie den Speicher von Ihrem App-Pod abhängen, ihn an Ihren Sicherungspod anhängen, die Daten sichern und den Speicher wieder an Ihren App-Pod anhängen.

Damit Ihre Daten noch besser hoch verfügbar sind und um Ihre App vor einem Zonenausfall zu schützen, konfigurieren Sie eine zweite Object Storage-Instanz und replizieren Sie die Daten zonenübergreifend. Falls Sie Daten von Ihrer Object Storage-Instanz wiederherstellen müssen, verwenden Sie das Wiederherstellungspod, 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 herauskopieren.

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

Wenn Sie den Befehl kubectl cp ausführen und 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> <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

Bronze

Name

ibmc-block-bronze

ibmc-block-retain-bronze

Typ

Endurance-Speicher

Dateisystem

ext4

IOPS pro Gigabyte

2

Größenbereich in Gigabyte

20-12000 Gi

Festplatte

SSD

Rückforderungsrichtlinie

ibmc-block-bronze: Löschen

ibmc-block-retain-bronze: Beibehalten

Silber

Name

ibmc-block-silver

ibmc-block-retain-silver

Typ

Endurance-Speicher

Dateisystem

ext4

IOPS pro Gigabyte

4

Größenbereich in Gigabyte

20-12000 Gi

Festplatte

SSD

Rückforderungsrichtlinie

ibmc-block-silver: Löschen

ibmc-block-retain-silver: Beibehalten

Gold

Name

ibmc-block-gold

ibmc-block-retain-gold

Typ

Endurance-Speicher

Dateisystem

ext4

IOPS pro Gigabyte

10

Größenbereich in Gigabyte

20-4000 Gi

Festplatte

SSD

Rückforderungsrichtlinie

ibmc-block-gold: Löschen

ibmc-block-retain-gold: Beibehalten

Angepasst

Name

ibmc-block-custom

ibmc-block-retain-custom

Typ

Performance-Dateisystem

ext4

E/A-Operationen pro Sekunde (IOPS) und Größe

Größenbereich im Gigabyte/IOPS-Bereich in Vielfachen von 100

• 20-39 Gi / 100-1000 IOPS
• 40-79 Gi / 100-2000 IOPS
• 80-99 Gi / 100-4000 IOPS
• 100-499 Gi / 100-6000 IOPS
• 500-999 Gi / 100-10000 IOPS
• 1000-1999 Gi / 100-20000 IOPS
• 2000-2999 Gi / 200-40000 IOPS
• 3000-3999 Gi / 200-48000 IOPS
• 4000-7999 Gi / 300-48000 IOPS
• 8000-9999 Gi / 500-48000 IOPS
• 10000-12000 Gi / 1000-48000 IOPS

Festplatte

Das Verhältnis zwischen der Anzahl E/A-Operationen pro Sekunde und Gigabyte bestimmt den Typ der Festplatte, die bereitgestellt wird. Um das Verhältnis zwischen der Anzahl E/A-Operationen pro Sekunde zu Gigabyte zu bestimmen, teilen Sie die Anzahl E/A-Operationen pro Sekunde durch die Größe Ihres Speichers.

Beispiel: Sie haben 500Gi für den Speicher mit 100 IOPS ausgewählt. Ihr Verhältnis ist 0,2 (100 E/A-Operationen pro Sekunde/500 Gigabyte).

Übersicht über die Festplattentypen pro Verhältnis:

• Kleiner-gleich 0,3: SATA
• Größer als 0,3: SSD

Rückforderungsrichtlinie

ibmc-block-custom: Löschen

ibmc-block-retain-custom: Beibehalten

Topologieorientierten Speicher erstellen

Zur Verwendung von Blockspeicher in einem Mehrzonencluster muss Ihr Pod in derselben Zone wie Ihre Blockspeicherinstanz 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 Blockspeicherinstanz automatisch durch die dynamische Bereitstellung Ihres Speichers erstellt, wenn ein PVC erstellt wurde. Wenn Sie Ihren Pod erstellten, versuchte der Kubernetes-Scheduler, den Pod in demselben Rechenzentrum wie Ihre Blockspeicherinstanz bereitzustellen.

Eine Erstellung der Blockspeicherinstanz 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 Blockspeicherinstanz verzögert, bis der erste Pod erstellt wird, der den Speicher verwendet.

Stellen Sie zur Verwendung der topologieorientierten Datenträgerplanung sicher, dass Sie das IBM Cloud Block Storage-Plug-in der Version 1.2.0 oder höher installiert haben.

Die folgenden Beispiele zeigen, wie Speicherklassen erstellt werden, die die Erstellung der Blockspeicherinstanz 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 gesetzt und die Blockspeicherinstanz wird erstellt, wenn Sie den PVC erstellen.

Beispiel für Endurance-Blockspeicher

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

Beispiel für Performance-Blockspeicher

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-performance-storageclass
  labels:
  kubernetes.io/cluster-service: "true"
  provisioner: ibm.io/ibmc-block
  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 und Region angeben

Wenn Sie Ihren Blockspeicher 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 das IBM Cloud Block Storage-Plug-in Version 1.0.0 verwenden oder wenn Sie in einer bestimmten Zone Blockspeicher statisch bereitstellen möchten. In allen anderen Fällen geben Sie die Zone direkt im PVC an.

Die folgende .yaml-Datei passt eine Speicherklasse an, die auf der Speicherklasse ibm-block-silver ohne 'retain' (Beibehaltung) basiert: Der Typ (type) ist "Endurance", der Wert für iopsPerGB ist 4, der Wert für sizeRange ist "[20-12000]Gi" und für reclaimPolicy wird die Einstellung "Delete" festgelegt. Die Zone wird als dal12 angegeben. Lesen Sie in der Speicherklassenreferenz nach, wenn Sie eine andere Speicherklasse als Basis verwenden möchten.

Erstellen Sie die Speicherklasse in derselben Region und Zone wie Ihren Cluster und Ihre Workerknoten. 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-Blockspeicher

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

Beispiel für Performance-Blockspeicher

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-block-performance-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-block
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Performance"
  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]"
reclaimPolicy: "Delete"

Blockspeicher mit einem Dateisystem XFS anhängen

In den folgenden Beispielen wird eine Speicherklasse erstellt, die Blockspeicher mit einem Dateisystem XFS bereitstellt.

Beispiel für Endurance-Blockspeicher

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
labels:
  addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  fsType: "xfs"
reclaimPolicy: "Delete"

Beispiel für Performance-Blockspeicher

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  classVersion: "2"
  type: "Performance"
  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]
  fsType: "xfs"
reclaimPolicy: "Delete"

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 block volume-list --columns id --columns notes | grep <pv_name>
    

    Beispielausgabe

    12345678   {"plugin":"ibmcloud-block-storage-plugin-689df949d6-4n9qg","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"block-storage-pvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-block-silver","reclaim":"Delete"}
    

    Erläuterungen zu den Informationen im Feld notes:

    "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":"block-storage-pvc"

    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 block volume-cancel <classic_block_id>
    

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

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

ibmcloud sl block volume-list