Installation des Cluster-Add-ons IBM Cloud Object Storage

Sie können das Add-on „ IBM Cloud Object Storage “ über die „ IBM Cloud “-Konsole oder die Befehlszeilenschnittstelle (CLI) aktivieren.

Voraussetzungen:

  • Das Add-on IBM Cloud Object Storage benötigt mindestens 0.3 vCPU und 360 MB Speicher.
  • Das Add-on ist für Red Hat CoreOS (RHCOS) und Ubuntu Worker Nodes verfügbar. Wenn Ihr Cluster sowohl RHEL- als auch RHCOS-Knoten hat, wird das Add-on nur auf den RHCOS-Knoten bereitgestellt.
  • Richten Sie eine Instanz von IBM Cloud Object Storage ein.
  • Optional Wenn Sie die Bucketversionierung verwenden möchten, müssen Ihre Dienstanmeldeinformationen über die Berechtigungen Manager oder Writer verfügen, um die Bucketversionierung für den Bucket zu aktivieren oder zu deaktivieren. Weitere Informationen finden Sie unter „ Erste Schritte mit der Versionsverwaltung “.

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, wird ein Bucket mit der Namenskonvention temp-xxx 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.

Das Add-on „ IBM Cloud Object Storage “ über die Konsole aktivieren

  1. Wählen Sie in der „ Red Hat OpenShift on IBM Cloud Cluster-Dashboard “ den Cluster aus, in dem Sie das Add-on aktivieren möchten.
  2. Suchen Sie im Bereich „ Add-ons “ das Cloud Object Storage Add-on und klicken Sie auf „ Installieren “.
  3. Wählen Sie im Fenster „ Add-on installieren: Cloud Object Storage “ eine Version aus der Dropdown-Liste „Version“ aus.
  4. Optional: Konfigurieren Sie die folgenden Parameter.
maxVolumesPerNode
Legen Sie die maximale Anzahl von „ IBM Cloud Object Storage “-Volumes fest, die auf einem einzelnen Knoten eingebunden werden können. Der Standardwert lautet „ 0 “, was bedeutet, dass keine Begrenzung gilt.
restrictNodeServerScheduling
Stellen Sie den Wert auf „ true “ ein, um die Nodeserver-Pods so einzuschränken, dass sie nur auf Knoten ausgeführt werden, die mit dem Label „ cos.csi.ibm.io/csi-node=true “ versehen sind. Der Standardwert lautet „ false “, was bedeutet, dass Nodeserver-Pods auf allen Knoten eingeplant werden.
  1. Klicken Sie auf Install. Es kann einige Minuten dauern, bis das Add-on bereitgestellt ist und verwendet werden kann.
  2. Überprüfen Sie die Installation. Vergewissern Sie sich im Abschnitt „Add-ons“, dass das Cloud Object Storage Add-on den Gesundheitszustand „ Normal “ anzeigt.

Aktivieren des IBM Cloud Object Storage Add-ons über die CLI

Vorbereitende Schritte: Greifen Sie auf Ihren Red Hat OpenShift-Cluster zu.

  1. Aktualisieren Sie das Plug-in „ container-service “ auf die neueste Version.
    ibmcloud update && ibmcloud plugin update container-service
    
  2. Listen Sie die Add-ons auf und suchen Sie die Version, die Sie installieren möchten.
    ibmcloud oc cluster addon versions
    
  3. Überprüfen Sie die Add-on-Optionen.
    ibmcloud oc cluster addon options --addon ibm-object-csi-driver [--version VERSION]
    
  4. Installieren Sie das Add-on.
    ibmcloud oc cluster addon enable ibm-object-csi-driver --cluster CLUSTER [--version VERSION]
    
  5. Überprüfen Sie die Installation.
    ibmcloud oc cluster addon ls --cluster CLUSTER
    
    OK
    Name                    Version   Health State   Health Status
    ibm-object-csi-driver   1.0       normal         Addon Ready. For more info: http://ibm.biz/addon-state (H1500)
    
  6. Listen Sie die verfügbaren Speicherklassen auf. Der Treiber unterstützt sowohl regionale als auch überregionale Speicherklassen für die Mount-Programme „ s3fs “ und „ rclone “.
    oc get sc | grep object
    
    ibm-object-storage-smart-cross-region-rclone             cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-smart-cross-region-rclone-retain      cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-smart-cross-region-s3fs               cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-smart-cross-region-s3fs-retain        cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-smart-rclone                          cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-smart-rclone-retain                   cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-smart-s3fs                            cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-smart-s3fs-retain                     cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-standard-cross-region-rclone          cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-standard-cross-region-rclone-retain   cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-standard-cross-region-s3fs            cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-standard-cross-region-s3fs-retain     cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-standard-rclone                       cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-standard-rclone-retain                cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    ibm-object-storage-standard-s3fs                         cos.s3.csi.ibm.io   Delete          Immediate           false                  17h
    ibm-object-storage-standard-s3fs-retain                  cos.s3.csi.ibm.io   Retain          Immediate           false                  17h
    

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>
    
restrictNodeServerScheduling Optionen
Einstellung Verhalten
restrictNodeServerScheduling: "false"(Standard) Nodeserver-Pods werden auf allen Knoten eingeplant.
restrictNodeServerScheduling: "true" Nodeserver-Pods werden ausschließlich auf Knoten eingeplant, die mit „ cos.csi.ibm.io/csi-node=true “ gekennzeichnet sind.

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
    
maxVolumesPerNode Optionen
Einstellung Verhalten
maxVolumesPerNode: "0"(Standard) Die Anzahl der Volumes, die pro Knoten eingebunden werden können, ist unbegrenzt.
maxVolumesPerNode: "VALUE" Begrenzt die Anzahl der Volumes, die auf einem einzelnen Knoten eingebunden werden können, auf den angegebenen Wert.

Bereitstellung einer App, die IBM Cloud Object Storage

Erstellen Sie ein „ Kubernetes “-Geheimnis, das Ihre COS-Anmeldedaten enthält.

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

  2. Speichern Sie die folgende Konfiguration in einer Datei mit dem Namen secret.yaml. Geben Sie entweder IAM-Berechtigungsnachweise oder HMAC an, aber nicht beides.

    • Verwenden Sie für IAM-Anmeldeinformationen eine Kombination aus apiKey und serviceId von Object Storage.
    • Für HMAC-Berechtigungsnachweise verwenden Sie accessKey und secretKey von Object Storage.
    apiVersion: v1
    kind: Secret
    type: cos-s3-csi-driver
    metadata:
        name: cos-secret-1 # Name your secret. This same name is used for the PVC in the following steps.
        namespace: <namespace> # Specify the namespace where you want to create the secret.
    data:
        apiKey: <base64-encoded-COS-Service-Instance-apikey>
        serviceID: <base64-encoded-COS-resource_instance_id>
        accessKey: <base64-encoded-HMAC-access_key_id>
        secretKey: <base64-encoded-HMAC-secret_access_key>
        kp-root-key-crn: <CRN> # Key Protect or HPCS root key crn in base64 encoded format
    stringData:
        bucketName: <bucket-name> # Optional. If you don't provide a bucket name, a bucket with the naming convention s3fs-timestamp-xxx or rclone-timestamp-xxx is created.
        bucketVersioning: "false" # Bucket versioning is set to false by default. Set to "true" to enable bucket versioning. Set to "false" to disable versioning for a bucket where versioning is enabled. Must be a string value.
        # uid: "3000" # Optional: Provide a uid to run as non root user. This must match runAsUser in SecurityContext of pod spec.
        mountOptions: |
            # Review or update the following default s3fs mount options
            #multipart_size=52
            #multireq_max=20
            #max_dirty_data=5120
            #parallel_count=20
            #max_stat_cache_size=100000
            #retries=5
            #kernel_cache
            # Review or update the following default rclone mount options
            #acl=private
            #bucket_acl=private
            #upload_cutoff=100Mi
            #chunk_size=16Mi
            #max_upload_parts=1000
            #upload_concurrency=8
    
    mountOptions
    Sie können die Einhängeoptionen entweder für s3fs oder rclone anpassen, indem Sie mountOptions in Ihrem Geheimnis bearbeiten. Stimmen Sie die von Ihnen angegebenen Optionen auf die von Ihrer PVC verwendete Speicherklasse ab. Um die Standardwerte für eine Speicherklasse zu überprüfen, führen Sie oc describe storageclass <storageclass_name> oder oc describe storageclass <storageclass_name> aus. Weitere Informationen finden Sie unter s3fs mount options und rclone mount options.

    Zurzeit ist das Add-on aktiviert, um einen festen Satz von Einhängeoptionen zu unterstützen, wobei jede Einhängeoption ordnungsgemäß validiert wird. Wenn Sie andere Montageoptionen verwenden möchten, die nicht in der Validierungsliste enthalten sind, wenden Sie sich an den Support, um diese Optionen zu aktivieren.

  3. Verschlüsseln Sie alle Parameter der geheimen Daten auf base64.

    echo -n "<value>" | base64
    
  4. Aktualisieren Sie die secret.yaml mit den base64 kodierten Werten.

  5. Geheimen Schlüssel erstellen

    oc apply -f secret.yaml
    

Erstellen Sie ein PVC

Sie können entweder ein einziges Geheimnis für mehrere PVCs oder ein Geheimnis pro PVC verwenden.

Sie können dieses Verhalten durch die Verwendung der folgenden Anmerkungen in der PVC yaml steuern. Diese Anmerkungen helfen dem Treiber, die PVC dem richtigen Geheimnis zuzuordnen.

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

Stellen Sie sicher, dass sich Ihr Secret, Ihr PVC und Ihre Pods alle im selben Namespace befinden.

Beispiel-PVC für eine Zuordnung von 1-to-1 secret zu PVC, indem Sie Ihrem PVC denselben Namen geben wie dem zuvor erstellten 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.

Beispiel-PVC für die Verwendung von 1 Geheimnis für viele PVCs durch Verwendung von Anmerkungen zur Angabe des Geheimnisses.

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.
  1. Wählen Sie eines der vorherigen Beispiele und passen Sie es an Ihren Anwendungsfall an. Eine Liste der Speicherklassen finden Sie in der Referenz der Speicherklassen.

  2. Erstellen Sie den PVC.

    oc apply -f pvc.yaml
    

Bereitstellung erstellen

  1. Speichern Sie die folgende Konfiguration in einer Datei mit dem Namen „ dep.yaml “.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <name>
      labels:
        app: <name>
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: <name>
      template:
        metadata:
          labels:
        app: <name>
        spec:
          containers:
          - name: app-frontend
            image: <image> # Enter your app image.
            imagePullPolicy: IfNotPresent
            volumeMounts:
            - mountPath: <path_you_want_to_mount_the_volume_on> # For example `/dev`
              name: cos-csi-volume
          volumes:
          - name: cos-csi-volume
            persistentVolumeClaim:
              claimName: <pvc_name> # Enter the name of the PVC you created earlier.
    
  2. Erstellen Sie die Implementierung.

    oc apply -f dep.yaml
    

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>
        # uid: "3000" # Optional: Provide a uid to run as non root user. This must match runAsUser in SecurityContext of pod spec.
        mountOptions: |
            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. Rufen Sie die Details zu Ihrer App ab.

    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 jedes PVC, das 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
Verwenden Sie diese Option für Daten, auf die Sie häufig zugreifen, z. B. Daten für das Internet oder mobile Anwendungen.
Intelligent
Verwendung für Arbeitslasten und Daten, die keinem bestimmten Nutzungsmuster folgen, oder wenn das Nutzungsmuster schwer vorhersehbar ist.
COS-Cluster-Zusatzspeicherklassen
Name Bucket-Klasse Ausfallsicherheit Montagegerät Rückforderungsrichtlinie Bindungsmodus
ibm-objekt-speicher-smart-regionsübergreifend-rclone Intelligent Regionsübergreifend rclone Löschen Sofort
ibm-objekt-speicher-smart-regionsübergreifend-rclone-beibehalten Intelligent Regionsübergreifend rclone Beibehalten Sofort
ibm-object-storage-smart-cross-region-s3fs Intelligent Regionsübergreifend s3fs Löschen Sofort
ibm-object-storage-smart-cross-region-s3fs-retain Intelligent Regionsübergreifend s3fs Beibehalten Sofort
ibm-object-storage-smart-rclone Intelligent Regional rclone Löschen Sofort
ibm-objekt-speicher-smart-rclone-retain Intelligent Regional rclone Beibehalten Sofort
ibm-object-storage-smart-s3fs Intelligent Regional s3fs Löschen Sofort
ibm-object-storage-smart-s3fs-retain Intelligent Regional s3fs Beibehalten Sofort
ibm-objekt-speicher-standard-regionenübergreifend-rclone Standard Regionsübergreifend rclone Löschen Sofort
ibm-objekt-speicher-standard-regionenübergreifend-rclone-retain Standard Regionsübergreifend rclone Beibehalten Sofort
ibm-object-storage-standard-cross-region-s3fs Standard Regionsübergreifend s3fs Löschen Sofort
ibm-object-storage-standard-cross-region-s3fs-retain Standard Regionsübergreifend s3fs Beibehalten Sofort
ibm-objekt-speicher-standard-rclone Standard Regional rclone Löschen Sofort
ibm-object-storage-standard-rclone-retain Standard Regional rclone Beibehalten Sofort
ibm-object-storage-standard-s3fs Standard Regional s3fs Löschen Sofort
ibm-object-storage-standard-s3fs-retain Standard Regional s3fs Beibehalten Sofort

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.

Speicherklassenparameter

Alle Cluster-Add-on-Speicherklassen enthalten die folgenden Kernparameter.

Kernparameter für COS-Cluster-Add-on-Speicherklassen
Parameter Beschreibung
client Gibt den Client-Typ an, den der Treiber verwendet. Die Zusatzspeicherklassen verwenden awss3.
cosEndpoint Legt den Endpunkt IBM Cloud Object Storage für die Bucket-Region fest.
csi.storage.k8s.io/node-publish-secret-name Verweist auf den Namen des Geheimnisses, das Ihre IBM Cloud Object Storage Anmeldedaten enthält.
csi.storage.k8s.io/node-publish-secret-namespace Verweist auf den Namespace des Geheimnisses, das Ihre IBM Cloud Object Storage Anmeldedaten enthält.
locationConstraint Definiert die Eimerklasse und die Region, z. B. au-syd-smart oder au-syd-standard.
mounter Gibt an, ob die Speicherklasse den s3fs oder rclone Mounter verwendet.

Standardmäßige s3fs Speicherklassen-Mount-Optionen

Die s3fs Speicherklassen verwenden die folgenden Standard-Mount-Optionen.

Standard-Einbindungsoptionen für die Speicherklassen „ s3fs “ des COS-Add-ons
Option montieren Beschreibung
multipart_size=52 Legt die Teilgröße in MB für jede mehrteilige Anfrage fest.
multireq_max=20 Legt die maximale Anzahl der parallelen Anfragen für die Auflistung von Objekten fest.
max_dirty_data=5120 Leert die schmutzigen Daten auf S3, nachdem eine bestimmte Anzahl von MB geschrieben wurde. Der kleinste unterstützte Wert ist 50. Ein Wert von -1 deaktiviert dieses Verhalten.
parallel_count=20 Legt die Anzahl der parallelen Anfragen für das Hochladen großer Objekte fest. s3fs lädt große Objekte mit Hilfe von mehrteiligen Anfragen hoch und sendet Anfragen parallel.
max_stat_cache_size=100000 Legt die maximale Anzahl der Einträge im Statistik-Cache und im Cache für symbolische Links fest.
retries=5 Legt fest, wie oft eine fehlgeschlagene S3 Transaktion wiederholt werden soll.
kernel_cache Aktiviert den Kernel-Puffer-Cache für den Einhängepunkt des Volumes. Daten, die von IBM Cloud Object Storage gelesen werden, werden im Kernel-Cache gespeichert, um einen schnelleren Lesezugriff zu ermöglichen. Der Kernel-Cache ist für die Speicherklassen Standard und Smart s3fs aktiviert.

Standardmäßige rclone Speicherklassen-Mount-Optionen

Die rclone Speicherklassen verwenden die folgenden Standard-Mount-Optionen.

Standard-Einbindungsoptionen für COS-Add-on-Speicherklassen von rclone
Option montieren Beschreibung
acl=private Stellt sicher, dass hochgeladene Objekte nicht öffentlich zugänglich sind.
bucket_acl=private Setzt die Standard-ACL für Buckets, die rclone erstellt, auf private.
upload_cutoff=100Mi Hochladen von Dateien, die größer als 100 MiB sind, mit Hilfe des mehrteiligen Uploads. Kleinere Dateien werden in einer einzigen Anfrage hochgeladen.
chunk_size=16Mi Legt die Größe der einzelnen Teile in einem mehrteiligen Upload fest.
max_upload_parts=1000 Legt die maximale Anzahl von Teilen pro mehrteiligem Upload fest und begrenzt indirekt die maximale unterstützte Dateigröße mit der konfigurierten chunk_size. Mit chunk_size=16Mi beträgt die maximale Dateigröße 16 GiB.
upload_concurrency=8 Legt die Anzahl der Teile fest, die bei einem mehrteiligen Upload parallel hochgeladen werden.