Verstehen der Erstellung und Entfernung von Eimern

• Sie können einen vorhandenen Bucket verwenden, indem Sie den Bucket-Namen in Ihrem PVC angeben.
• Wenn Sie einen Bucket-Namen angeben und dieser Bucket nicht existiert, wird ein Bucket mit diesem Namen erstellt.
• Wenn Sie keinen Bucket-Namen angeben, rclone-<timestamp>-xxx wird je nach Mounter-Typ ein Bucket mit der Namenskonvention s3fs-<timestamp>-xxx oder erstellt.
• Buckets werden auf der Grundlage der in Ihrer Speicherklasse definierten Rückforderungsrichtlinie gelöscht.
  • Wenn reclaimPolicy: Delete gesetzt ist, wird der Bucket gelöscht, wenn der PVC gelöscht wird.
  • Wenn reclaimPolicy: Retain gesetzt ist, bleibt der Bereich auch nach dem Löschen des PVC erhalten.

Einschränkung der Pod-Planung für Nodeserver

Standardmäßig werden die COS-CSI-Treiber-Nodeserver-Pods auf allen Knoten des Clusters eingeplant. Mit dem Parameter „ restrictNodeServerScheduling “ können Sie die Planung von Nodeserver-Pods auf diejenigen Knoten beschränken, die mit dem Label „ cos.csi.ibm.io/csi-node=true “ versehen sind.

Sie können „ restrictNodeServerScheduling “ bei der Aktivierung des Add-ons konfigurieren oder später durch Anwenden eines Patches auf die Datei „ ConfigMap “ aktualisieren.

• Um bei der Aktivierung des Add-ons die Option „ restrictNodeServerScheduling “ festzulegen, fügen Sie das Flag „ --param “ in den Befehl „enable“ ein.

  ibmcloud oc cluster addon enable ibm-object-csi-driver --cluster CLUSTER --param "restrictNodeServerScheduling=true"
  

• Um „ restrictNodeServerScheduling “ zu aktualisieren, nachdem das Add-on bereits aktiviert wurde, führen Sie die folgenden Schritte aus.

1. Listen Sie die Knoten in Ihrem Cluster auf und legen Sie fest, wo die COS-Treiber-Pods ausgeführt werden sollen.

   oc get nodes
   

   Beispielausgabe

   NAME            STATUS   ROLES    AGE    VERSION
   10.241.0.11     Ready    <none>   5d2h   v1.35.5+IKS
   10.241.0.12     Ready    <none>   5d2h   v1.35.5+IKS
   10.241.0.13     Ready    <none>   5d2h   v1.35.5+IKS
   10.241.128.10   Ready    <none>   5d2h   v1.35.5+IKS
   10.241.128.11   Ready    <none>   5d2h   v1.35.5+IKS
   10.241.128.9    Ready    <none>   5d2h   v1.35.5+IKS
   10.241.65.12    Ready    <none>   5d2h   v1.35.5+IKS
   10.241.65.13    Ready    <none>   5d2h   v1.35.5+IKS
   10.241.65.14    Ready    <none>   5d2h   v1.35.5+IKS
   

2. Überprüfen Sie, ob die Nodeserver-Pods derzeit auf allen Knoten laufen.

   oc get pods -n ibm-object-csi-operator -l app.kubernetes.io/component=node -o wide
   

   Beispielausgabe

   NAME                        READY   STATUS    RESTARTS   AGE    IP              NODE            NOMINATED NODE   READINESS GATES
   ibm-object-csi-node-2pj2j   3/3     Running   0          145m   172.17.14.10    10.241.0.12     <none>           <none>
   ibm-object-csi-node-7bhwh   3/3     Running   0          145m   172.17.1.72     10.241.65.12    <none>           <none>
   ibm-object-csi-node-7l9hc   3/3     Running   0          145m   172.17.17.6     10.241.128.9    <none>           <none>
   ibm-object-csi-node-cxzt7   3/3     Running   0          145m   172.17.39.72    10.241.0.11     <none>           <none>
   ibm-object-csi-node-dw6qs   3/3     Running   0          145m   172.17.46.77    10.241.128.10   <none>           <none>
   ibm-object-csi-node-rpcvr   3/3     Running   0          145m   172.17.32.198   10.241.65.13    <none>           <none>
   ibm-object-csi-node-swqtg   3/3     Running   0          145m   172.17.16.69    10.241.0.13     <none>           <none>
   ibm-object-csi-node-sxbbs   3/3     Running   0          145m   172.17.26.7     10.241.65.14    <none>           <none>
   ibm-object-csi-node-xm8bt   3/3     Running   0          145m   172.17.20.200   10.241.128.11   <none>           <none>
   

3. Kennzeichnen Sie die Knoten, auf denen die Nodeserver-Pods eingeplant werden sollen.

   oc label nodes NODE-NAME-1 NODE-NAME-2 cos.csi.ibm.io/csi-node=true
   

   Beispielausgabe

   node/10.241.0.11 labeled
   node/10.241.0.12 labeled
   

4. Aktivieren Sie die Einschränkung, indem Sie die Datei „ ConfigMap “ aktualisieren.

   oc patch cm managed-addon-ibm-object-csi-driver -n kube-system \
     --type merge -p '{"data":{"restrictNodeServerScheduling":"true"}}'
   

   Beispielausgabe

   configmap/managed-addon-ibm-object-csi-driver patched
   

5. Stellen Sie sicher, dass Nodeserver-Pods ausschließlich auf mit einem Label versehenen Knoten eingeplant werden.

   oc get pods -n ibm-object-csi-operator -l app.kubernetes.io/component=node -o wide
   

   Beispielausgabe

   NAME                        READY   STATUS    RESTARTS   AGE    IP             NODE           NOMINATED NODE   READINESS GATES
   ibm-object-csi-node-cxzt7   3/3     Running   0          145m   172.17.39.72   10.241.0.11    <none>           <none>
   ibm-object-csi-node-7bhwh   3/3     Running   0          145m   172.17.1.72    10.241.65.12   <none>           <none>
   

Festlegen der maximalen Volumes pro Knoten

Standardmäßig begrenzt der COS-CSI-Treiber die Anzahl der Volumes, die auf einem einzelnen Knoten eingebunden werden können, nicht. Mit dem Parameter „ maxVolumesPerNode “ können Sie die maximale Anzahl von Volumes pro Knoten festlegen.

Sie können „ maxVolumesPerNode “ bei der Aktivierung des Add-ons konfigurieren oder später durch Anwenden eines Patches auf die Datei „ ConfigMap “ aktualisieren.

• Um bei der Aktivierung des Add-ons die Option „ maxVolumesPerNode “ festzulegen, fügen Sie das Flag „ --param “ in den Befehl „enable“ ein.

  ibmcloud oc cluster addon enable ibm-object-csi-driver --cluster CLUSTER --param "maxVolumesPerNode=VALUE"
  

• Um „ maxVolumesPerNode “ zu aktualisieren, nachdem das Add-on bereits aktiviert wurde, wenden Sie den Patch für das verwaltete Add-on an: ConfigMap.

  oc patch cm managed-addon-ibm-object-csi-driver -n kube-system --type merge -p '{"data":{"maxVolumesPerNode":"VALUE"}}'
  

  Beispielausgabe

  configmap/managed-addon-ibm-object-csi-driver patched
  

Bereitstellung einer App, die IBM Cloud Object Storage nutzt

cos.csi.driver/secret: "<custom-secret>"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cos-secret-1 # Give your PVC the same name as the secret you created in the previous step.
  namespace: <namespace> # The namespace where you want to create the PVC.
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: <storage_class_name> # The storage class you want to use.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cos-csi-pvc1
  namespace: <namespace> # The namespace where you want to create the PVC.
  annotations:
    cos.csi.driver/secret: "<custom-secret>"
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 256Mi
  storageClassName: <storage_class_name> # The storage class you want to use.

Deaktivierung des IBM Cloud Object Storage Add-ons

Die vorhandenen Geheimnisse, PVCs und Bereitstellungen werden durch das Deaktivieren des Add-ons oder durch Patch-Updates nicht gelöscht. Es gibt keine Unterbrechungen der bestehenden Arbeitsbelastung der Kunden.

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

    ibmcloud oc cluster addon disable ibm-object-csi-driver --cluster CLUSTER
   

   Beispielausgabe

   Data and resources that you created for the add-on might be deleted when the add-on is disabled. Continue? [y/N]> y
   Disabling add-on ibm-object-csi-driver for cluster XXX...
   OK
   

2. Überprüfen Sie, ob das Add-on entfernt wurde.

   ibmcloud oc cluster addon ls --cluster CLUSTER
   

Umstellung vom Helm auf das Cluster-Add-on

1. Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

2. Lassen Sie sich die Details Ihrer PVCs anzeigen und wählen Sie eine aus, die Sie migrieren möchten.

   oc get pvc --all-namespaces -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name' | tail -n +2 | while read namespace pvc; do kubectl describe pvc "$pvc" -n "$namespace" | grep 'volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs' > /dev/null ; if [ $? -eq 0 ]; then echo "PVC: $pvc in Namespace: $namespace uses ibm.io/ibmc-s3fs storage provisioner"; fi; done
   

   Beispielausgabe

   PVC: pvc-test in Namespace: default uses ibm.io/ibmc-s3fs storage provisioner
   

3. Beschreiben Sie das PVC und erhalten Sie den Namen des Eimers.

   oc describe pvc <pvc_name> | grep ibm.io/bucket:
   

   Beispielausgabe

   ibm.io/bucket: test-s3
   

4. Stellen Sie Ihr Geheimnis mit dem Namen des Eimers wieder her.

   apiVersion: v1
   kind: Secret
   type: cos-s3-csi-driver
   metadata:
       name: cos-secret-1 # Name your secret.
       namespace: <namespace> # Specify the namespace where you want to create the secret.
   data:
       accessKey: <base64-encoded-HMAC-access-key>
       secretKey: <base64-encoded-HMAC-secret-key>
   stringData:
       bucketName: <bucket-name>
       mountOptions: |
           # uid=3000  # Optional: Run as non-root user. Must match runAsUser in SecurityContext of pod spec.
           key1=value1
           key2=value2
   

5. Suchen Sie die Speicherklasse, die in Ihrem PVC verwendet wurde.

   oc describe pvc <pvc_name> | grep StorageClass:
   

   Beispielbefehl für eine PVC namens test-s3.

   oc describe pvc test-s3 | grep StorageClass:
   

   Beispielausgabe

   StorageClass:  ibmc-s3fs-smart-perf-regional
   

6. Überprüfen Sie die neuen Speicherklassen, die mit dem Add-on verfügbar sind, und wählen Sie eine Ersatzklasse aus.

   • Wenn Sie eine flex verwendet haben, wählen Sie eine der neuen smart.
   • Wenn Sie eine standard verwendet haben, wählen Sie eine der neuen standard.
   • Die Klassen cold und vault sind mit dem Add-on nicht mehr verfügbar; wählen Sie stattdessen eine Klasse smart oder standard.

7. Überprüfen Sie die Details Ihrer PVC.

   oc describe pvc test-s3
   

   Beispielausgabe

   Name:          pvc-test
   Namespace:     default
   StorageClass:  ibmc-s3fs-smart-perf-regional
   Status:        Bound
   Volume:        pvc-c625474d-31f0-4929-bc3e-feace1fb42fb
   Labels:        <none>
   Annotations:   ibm.io/auto-create-bucket: true
               ibm.io/auto-delete-bucket: true
               ibm.io/bucket: bha-test-s23
               ibm.io/secret-name: satstoragesecret
               pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.kubernetes.io/storage-provisioner: ibm.io/ibmc-s3fs
   Finalizers:    [kubernetes.io/pvc-protection]
   Capacity:      3Gi
   Access Modes:  RWO
   VolumeMode:    Filesystem
   Used By:       test-pod
   Events:        <none>
   

8. Erstellen Sie eine Ersatz-PVC, die eine neue Speicherklasse verwendet und auf das zuvor erstellte Geheimnis verweist.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
   name: cos-csi-pvc1
   namespace: <namespace> # The namespace where you want to create the PVC.
   annotations:
       cos.csi.driver/secret: "cos-secret-1"  # Secret created in step 4
   spec:
   accessModes:
   - ReadWriteOnce
   resources:
       requests:
       storage: 256Mi
   storageClassName: <storage_class_name> # The storage class you picked based on old storage class mapping.
   

9. Überprüfen Sie, ob das PVC Bound ist.

   oc get pvc
   

10. Erhalten Sie detaillierte Informationen zu Ihrer App.

    oc get pods
    

11. Verkleinern Sie Ihre Anwendung auf Null.

    kubectl scale deployment --replicas=0 my-app
    

12. Erstellen Sie eine Ersatzbereitstellung, die auf die im vorherigen Schritt erstellte PVC verweist.

13. Nachdem die neue Bereitstellung ausgeführt wurde, können Sie die alte Bereitstellung löschen.

14. Wiederholen Sie diese Schritte für jede PVC, die Sie migrieren möchten.

cluster-Zusatzspeicherklassen IBM Cloud Object Storage

Das IBM Cloud Object Storage cluster add-on bietet Speicherklassen für die Mounter s3fs und rclone. Wählen Sie eine Speicherklasse aus, die Ihren Datenzugriffsanforderungen entspricht. Die Speicherklasse bestimmt die Bucket-Klasse, die Rückforderungsrichtlinie und das Standard-Mount-Verhalten für den Bucket, der für Ihren Workload erstellt wird.

Standard

Verwendung für Hot Data, auf die häufig zugegriffen wird. Gängige Anwendungsfälle sind Web-Apps oder Mobile Apps.

Vault

Verwenden Sie diese für Workloads oder Cool Data, auf die nur selten zugegriffen wird, beispielsweise einmal im Monat oder seltener. Gängige Anwendungsfälle sind Archive, kurzfristige Datenaufbewahrung, Aufbewahrung digitaler Assets, Bandwechsel oder Disaster-Recovery.

Kalt

Verwendung für Cold Data, auf die selten zugegriffen wird (alle 90 Tage oder seltener), oder für inaktive Daten. Gängige Anwendungsfälle sind Archive, langfristige Sicherung, Langzeitdaten, die Sie für Compliance-Zwecke aufbewahren, oder Workloads und Apps, auf die selten zugegriffen wird.

Intelligent

Verwendung für Arbeitslasten und Daten, die keinem bestimmten Nutzungsmuster folgen, oder wenn das Nutzungsmuster schwer vorhersehbar ist.

Entscheiden Sie über die Ausfallsicherheit für die Daten, die in Ihrem Bucket gespeichert sind. Weitere Informationen finden Sie im Abschnitt zu Regionen und Endpunkten.

regionsübergreifend

Ihre Daten werden zur Gewährleistung höchster Verfügbarkeit in drei Regionen innerhalb eines geografischen Standorts gespeichert. Wenn Sie über Workloads verfügen, die über Regionen verteilt sind, werden Anforderungen an den nächsten regionalen Endpunkt weitergeleitet. Der Endpunkt IBM Cloud Object Storage für die Geolokalisierung wird automatisch basierend auf dem Standort Ihres Clusters festgelegt. Befindet sich Ihr Cluster beispielsweise in US South, dann sind Ihre Speicherklassen so konfiguriert, dass sie den Endpunkt US GEO für Ihre Buckets verwenden. Wählen Sie eine Speicherklasse, deren Name cross-region enthält.

Regional

Ihre Daten werden über mehrere Zonen innerhalb einer Region hinweg repliziert. Wenn Sie Workloads haben, die sich in derselben Region befinden, stellen Sie eine geringere Latenz und eine bessere Leistung als bei einer regionsübergreifenden Konfiguration fest. Der regionale Endpunkt wird automatisch anhand des Standorts Ihres Clusters festgelegt. Befindet sich Ihr Cluster beispielsweise in US South, dann sind Ihre Speicherklassen so konfiguriert, dass US South als regionaler Endpunkt für Ihre Buckets verwendet wird. Wählen Sie eine Speicherklasse, deren Name kein cross-region enthält.

Um die detaillierte Bucket-Konfiguration für eine Speicherklasse zu überprüfen, führen Sie oc describe storageclass <storageclass_name> oder oc describe storageclass <storageclass_name> aus.