Comprendre la création et la suppression des seaux

• Vous pouvez utiliser un seau existant en spécifiant le nom du seau dans votre PVC.
• Si vous fournissez un nom de seau et que ce seau n'existe pas, un seau portant ce nom est créé.
• Si vous ne fournissez pas de nom de compartiment, un compartiment respectant la convention de nommage s3fs-<timestamp>-xxx ou rclone-<timestamp>-xxx est créé, en fonction du type de montage.
• Les bacs sont supprimés en fonction de la politique de récupération définie dans votre classe de stockage.
  • Si reclaimPolicy: Delete est défini, le seau est supprimé lorsque le PVC est supprimé.
  • Si reclaimPolicy: Retain est défini, le seau est conservé même après la suppression du PVC.

Restriction de la planification des pods « nodeserver »

Par défaut, les pods « nodeserver » du pilote COS CSI sont planifiés sur tous les nœuds du cluster. Vous pouvez utiliser le paramètre restrictNodeServerScheduling pour limiter la planification des pods du serveur de nœuds aux seuls nœuds portant le libellé « cos.csi.ibm.io/csi-node=true ».

Vous pouvez configurer restrictNodeServerScheduling lors de l'activation du module complémentaire, ou le mettre à jour ultérieurement en appliquant un correctif à l' ConfigMap.

• Pour définir la variable d' restrictNodeServerScheduling ation lors de l'activation du module complémentaire, incluez l'indicateur « --param » dans la commande d'activation.

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

• Pour mettre à jour « restrictNodeServerScheduling » une fois que l'extension est déjà activée, procédez comme suit.

1. Répertoriez les nœuds de votre cluster et déterminez où vous souhaitez que les pods du pilote COS s'exécutent.

   oc get nodes
   

   Exemple de sortie

   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. Vérifiez que les pods « nodeserver » sont bien en cours d'exécution sur tous les nœuds.

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

   Exemple de sortie

   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. Attribuez une étiquette aux nœuds sur lesquels vous souhaitez que les pods « nodeserver » soient planifiés.

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

   Exemple de sortie

   node/10.241.0.11 labeled
   node/10.241.0.12 labeled
   

4. Pour activer cette restriction, mettez à jour le fichier « ConfigMap ».

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

   Exemple de sortie

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

5. Vérifiez que les pods « nodeserver » ne sont planifiés que sur des nœuds étiquetés.

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

   Exemple de sortie

   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>
   

Définition du nombre maximal de volumes par nœud

Par défaut, le pilote COS CSI ne limite pas le nombre de volumes pouvant être montés sur un même nœud. Vous pouvez utiliser le paramètre « maxVolumesPerNode » pour définir le nombre maximal de volumes par nœud.

Vous pouvez configurer maxVolumesPerNode lors de l'activation du module complémentaire, ou le mettre à jour ultérieurement en appliquant un correctif à l' ConfigMap.

• Pour définir la variable d' maxVolumesPerNode ation lors de l'activation du module complémentaire, incluez l'indicateur « --param » dans la commande d'activation.

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

• Pour mettre à jour maxVolumesPerNode une fois que l'extension est déjà activée, appliquez le correctif à l'extension gérée ConfigMap.

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

  Exemple de sortie

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

Déploiement d'une application utilisant l' IBM Cloud Object Storage

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.

Désactivation du module complémentaire IBM Cloud Object Storage

Les secrets, les PVC et les déploiements existants ne sont pas supprimés par la désactivation du module complémentaire ou par les mises à jour des correctifs. Il n'y a pas de perturbation des charges de travail existantes des clients.

1. Exécutez la commande suivante pour désactiver le module complémentaire.

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

   Exemple de sortie

   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. Vérifiez que le module complémentaire a bien été supprimé.

   ibmcloud oc cluster addon ls --cluster CLUSTER
   

Migration du plug-in Helm vers le module complémentaire cluster

1. Accédez à votre cluster Red Hat OpenShift.

2. Obtenez les détails de vos PVC et sélectionnez-en un à migrer.

   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
   

   Exemple de sortie

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

3. Décrire le PVC et obtenir le nom du seau.

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

   Exemple de sortie

   ibm.io/bucket: test-s3
   

4. Recréez votre secret avec le nom du seau inclus.

   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. Recherchez la classe de stockage utilisée dans votre PVC.

   oc describe pvc <pvc_name> | grep StorageClass:
   

   Exemple de commande pour un PVC appelé test-s3.

   oc describe pvc test-s3 | grep StorageClass:
   

   Exemple de sortie

   StorageClass:  ibmc-s3fs-smart-perf-regional
   

6. Examinez les nouvelles classes de stockage disponibles avec le module complémentaire et sélectionnez une classe de remplacement.

   • Si vous avez utilisé une classe flex, choisissez l'une des nouvelles classes smart
   • Si vous avez utilisé une classe standard, choisissez l'une des nouvelles classes standard
   • Les classes cold et vault ne sont plus disponibles avec le module complémentaire ; choisissez une classe smart ou standard à la place.

7. Examinez les détails de votre PVC.

   oc describe pvc test-s3
   

   Exemple de sortie

   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. Créez un PVC de remplacement qui utilise une nouvelle classe de stockage et fait référence au secret que vous avez créé précédemment.

   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. Vérifier que le PVC est Bound.

   oc get pvc
   

10. Obtenez les détails de votre application.

    oc get pods
    

11. Réduisez votre application à zéro.

    kubectl scale deployment --replicas=0 my-app
    

12. Créez un déploiement de remplacement qui fait référence au PVC que vous avez créé à l'étape précédente.

13. Une fois la nouvelle répartition en cours d'exécution, vous pouvez supprimer l'ancienne répartition.

14. Répétez ces étapes pour chaque PVC que vous souhaitez migrer.

IBM Cloud Object Storage classes de stockage supplémentaires pour les clusters

Le module complémentaire de cluster IBM Cloud Object Storage fournit des classes de stockage pour les supports s3fs et rclone. Sélectionnez une classe de stockage qui convient à vos exigences en matière d'accès aux données. La classe de stockage détermine la classe de bac, la politique de récupération et le comportement de montage par défaut du bac créé pour votre charge de travail.

standard

À utiliser pour les données chaudes auxquelles on accède fréquemment. Les cas d'utilisation courants sont les applications Web ou mobiles.

Coffre

À utiliser pour les charges de travail ou les données cool auxquelles on accède rarement, par exemple une fois par mois ou moins. Les cas d'utilisation courants sont les archives, la conservation à court-terme des données, la conservation de documents numériques, le remplacement d'une bande et la reprise après incident.

Froid

À utiliser pour les données froides rarement consultées (tous les 90 jours ou moins) ou les données inactives. Les cas d'utilisation courants sont les archives, les sauvegardes à long terme, les données d'historique que vous conservez à des fins de conformité ou les charges de travail ou les applications auxquelles l'accès est plutôt rare.

Intelligence

A utiliser pour les charges de travail et les données qui ne suivent pas un schéma d'utilisation spécifique, ou lorsque le schéma d'utilisation est difficile à prévoir.

Déterminez le niveau de résilience des données stockées dans votre compartiment. Pour plus d'informations, voir Régions et noeuds finaux.

interrégion

Vos données sont stockées dans trois régions au sein d'une même zone géographique afin de garantir une disponibilité optimale. Si vous disposez de charges de travail réparties sur plusieurs régions, les demandes sont acheminées vers le noeud final régional le plus proche. Le point de terminaison IBM Cloud Object Storage pour la géolocalisation est automatiquement défini en fonction de l'emplacement de votre cluster. Par exemple, si votre cluster se trouve dans US South, vos classes de stockage sont alors configurées pour utiliser le point US GEO de terminaison de vos compartiments. Choisissez une classe de stockage dont le nom contient cross-region.

Régional

Vos données sont répliquées dans plusieurs zones au sein d'une même région. Si vous disposez de charges de travail situées dans la même région, vous observez des temps d'attente plus faibles et de meilleures performances qu'avec une configuration inter-régionale. Le point de terminaison régional est défini automatiquement en fonction de l'emplacement de votre cluster. Par exemple, si votre cluster se trouve dans US South, vos classes de stockage sont alors configurées pour utiliser US South comme point de terminaison régional pour vos compartiments. Choisissez une classe de stockage dont le nom ne cross-region contient pas « ».

Pour examiner la configuration détaillée des seaux d'une classe de stockage, exécutez oc describe storageclass <storageclass_name> ou oc describe storageclass <storageclass_name>.