Mise à jour du plug-in IBM Cloud Block Storage

Vous pouvez mettre à niveau le plug-in IBM Cloud Block Storage existant à la version la plus récente.

Avant de commencer : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

1. Mettez à jour le référentiel Helm pour extraire la dernière version de toutes les chartes Helm figurant dans ce référentiel.

   helm repo update
   

2. Facultatif : téléchargez la charte Helm la plus récente sur votre machine locale. Ensuite, extrayez le package et consultez le fichier release.md pour trouver les informations relatives à la dernière édition.

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

3. Recherchez le nom d'édition et l'espace de noms de la charte Helm de stockage par blocs que vous avez installée dans votre cluster.

   helm ls -A
   

   Exemple de sortie

   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. Mettez à niveau le plug-in IBM Cloud Block Storage à la version la plus récente. Incluez le nom de l'édition et l'espace de nom que vous avez extrait précédemment.

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

5. Facultatif : lorsque vous mettez à jour le plug-in, la classe de stockage default n'est pas définie. Pour définir la classe de stockage par défaut par une classe de stockage de votre choix, exécutez la commande suivante.

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

Retrait du plug-in IBM Cloud Block Storage

Si vous ne souhaitez pas fournir et utiliser IBM Cloud Block Storage dans votre cluster, vous pouvez désinstaller le graphique Helm.

Le retrait du plug-in ne retire pas les réservations de volume persistant (PVC), les volumes persistants (PV) ou les données. Lorsque vous retirez le plug-in, tous les pods associés et les ensembles de démons sont retirés de votre cluster. Vous ne pouvez pas fournir de nouvelles unités de stockage de blocs pour votre cluster ou utiliser des PVC et des PV de stockage de blocs existants après avoir supprimé le plug-in.

Avant de commencer :

• Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.
• Vérifiez que vous n'avez pas de PVC ou de PV dans votre cluster qui utilise le stockage de blocs.

Pour supprimer le plug-in :

1. Recherchez le nom d'édition et l'espace de noms de la charte Helm de stockage par blocs que vous avez installée dans votre cluster.

   helm ls -A
   

   Exemple de sortie

   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. Supprimez le plug-in IBM Cloud Block Storage.

   helm uninstall NAME -n kube-system
   

3. Vérifiez que les pods de stockage par blocs sont retirés.

   kubectl get pods -n kube-system | grep block
   

   Le retrait des pods a abouti lorsqu'aucun pod n'est affiché dans la sortie de votre interface de ligne de commande.

4. Vérifiez que les classes de stockage par blocs sont retirées. Le retrait des classes de stockage a abouti lorsqu'aucune classe de stockage n'est affichée dans la sortie de votre interface de ligne de commande.

   kubectl get sc | grep block
   

Chiffrement des données d'un volume à l'aide de votre propre classe de stockage

Vous pouvez déployer des applications qui utilisent des volumes chiffrés en créant au préalable votre propre classe de stockage.

Les étapes ci-après montrent comment créer une classe de stockage chiffrée personnalisée que vous pouvez utiliser pour créer plusieurs instances de stockage par blocs chiffrées avec la même configuration. Si vous souhaitez créer une PVC chiffrée en utilisant l'une des classes de stockage fournies par IBM, vous pouvez le faire en faisant directement référence aux données d'identification Key Protect dans votre PVC.

1. Déterminez la configuration de stockage à adopter.

2. Créez votre propre classe de stockage qui provisionne une instance de stockage en blocs chiffrée en vous basant sur l'une des classes de stockage fournies par IBM. Vous pouvez extraire les détails d'une classe de stockage en exécutant kubectl get sc <storageclass_name> -o yaml. L'exemple suivant est basé sur la classe de stockage 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. Créez la classe de stockage dans votre cluster.

   kubectl apply -f storageclass.yaml
   

4. Ajoutez « Block Storage for Classic » à votre application en utilisant votre propre classe de stockage pour créer un PVC.

5. Vérifiez le chiffrement de vos volumes Block Storage for Classic.

Création d'une PVC qui fait référence à votre secret Block Storage for Classic

Vous pouvez mettre à disposition une instance Block Storage for Classic chiffrée en créant une PVC qui spécifie le secret Kubernetes contenant vos données d'identification Key Protect.

Les étapes ci-après montrent comment faire référence à vos données d'identification Key Protect dans votre PVC pour créer une instance Block Storage for Classic chiffrée. Pour créer plusieurs volumes chiffrés sans spécifier les données d'identification Key Protect dans chaque PVC, vous pouvez créer une classe de stockage chiffrée personnalisée.

1. Passez en revue les classes de stockage Block Storage for Classic fournies afin de déterminer celle qui répond le mieux aux exigences de votre application. Si les classes de stockage fournies ne répondent pas aux exigences de votre application, vous pouvez créer votre propre classe de stockage personnalisée.

2. Créez un fichier de configuration de PVC nommé pvc.yaml faisant référence au secret Kubernetes dans lequel vous avez stocké les données d'identification du service Key Protect. Pour créer ce secret, voir Configuration du chiffrement pour Block Storage for Classic.

   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. Créez la PVC dans votre cluster.

   kubectl apply -f pvc.yaml
   

4. Vérifiez le statut de votre PVC.

   kubectl get pvc
   

5. Attendez que votre PVC soit liée, puis créez un déploiement qui utilise votre PVC.

6. Vérifiez le chiffrement de vos volumes Block Storage for Classic.

Vérification du chiffrement de vos volumes Block Storage for Classic

Vous pouvez contrôler le chiffrement de vos volumes en vérifiant le chemin de montage du volume.

1. Connectez-vous à votre pod d'application. Remplacez <pod_name> par le nom du pod qui monte votre volume Block Storage for Classic chiffré.

   kubectl exec <pod_name> -it bash
   

2. Répertoriez le système de fichiers de votre pod.

   df -h
   

3. Passez en revue le chemin du système de fichiers pour votre volume Block Storage for Classic chiffré.

   • Les volumes chiffrés ont une structure de chemin d'accès /dev/mapper/<pvc-ID_encrypted>. Dans cet exemple, le volume chiffré est monté sur le chemin de fichier /test dans le pod.

       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
       ```
   * Les volumes non chiffrés possèdent une structure de chemin d'accès `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
       ```
   

La suppression de votre secret Kubernetes ne révoque pas l'accès aux données de volume. Si vous avez créé un déploiement qui ne comprend qu'un pod, vous devez supprimer le pod. Si vous avez créé un déploiement, vous devez le supprimer.

Récupération des informations de votre stockage de bloc existant

1. Récupérez ou générez une clé d'API pour votre compte d'infrastructure IBM Cloud.

   1. Connectez-vous au portail de l'infrastructure « IBM Cloud ».
   2. Sélectionnez Compte, puis Utilisateurs et ensuite Liste d'utilisateurs.
   3. Recherchez votre ID utilisateur.
   4. Dans la colonne Clé d'API, cliquez sur Générer pour générer la clé d'API ou sur Afficher pour afficher votre clé d'API existante.

2. Récupérez le nom d'utilisateur de l'API pour votre compte d'infrastructure IBM Cloud.

   1. Dans le menu Liste d'utilisateurs, sélectionnez votre ID utilisateur.
   2. Dans la section Informations d'accès à l'API, retrouvez votre Nom d'utilisateur de l'API.

3. Connectez-vous au plug-in d'interface de ligne de commande (CLI) de l'infrastructure IBM Cloud.

   ibmcloud sl init
   

4. Optez pour l'authentification à l'aide du nom d'utilisateur et de la clé d'API de votre compte d'infrastructure IBM Cloud.

5. Entrez le nom d'utilisateur et la clé d'API que vous avez récupérés dans les étapes précédentes.

6. Affichez la liste des unités de stockage par blocs.

   ibmcloud sl block volume-list
   

   Exemple de sortie

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

7. Récupérez les détails du volume. Remplacez <volume_ID> par l'ID du volume de stockage de bloc que vous avez extrait lors de l'étape 6.

   ibmcloud sl block volume-detail <volume_ID>
   

   Exemple de sortie

   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. Notez les ID, Capacity, LUN Id, Datacenteret Target IP du volume que vous souhaitez monter sur votre cluster. Remarque : pour monter du stockage existant sur un cluster, vous devez disposer d'un noeud worker dans la même zone que votre stockage. Pour vérifier la zone de votre nœud worker, exécutez ibmcloud ks worker ls --cluster <cluster_name_or_ID>.

Création d'un volume persistant (PV) et d'une réclamation de volume persistant correspondante (PVC)

1. Facultatif : si vous avez un stockage que vous avez mis à disposition avec une classe de stockage retain, lorsque vous supprimez le PVC, le PV et l'unité de stockage physique ne sont pas supprimés. Pour réutiliser le stockage dans votre cluster, vous devez d'abord supprimer le volume persistant. Répertoriez les volumes persistants appartenant à votre stockage persistant. Ce PV est à l'état released.

   kubectl get pv
   

2. Supprimez le volume persistant.

   kubectl delete pv <pv_name>
   

3. Vérifiez que le volume persistant est supprimé.

   kubectl get pv
   

4. Créez un fichier de configuration pour votre volume persistant. Incluez les paramètres que vous avez extraits précédemment.

   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

   Donnez un nom à votre volume persistant. Par exemple, block-storage-pv. Notez que vous devez également entrer cette valeur dans spec.FlexVolume.options en tant que volumeName.

   labels

   Entrez la région et la zone que vous avez récupérées précédemment. Vous devez disposer d'au moins un noeud worker dans la même région et dans la même zone que votre stockage persistant pour monter le stockage sur votre cluster. Pour extraire vos détails de volume, exécutez ibmcloud sl block volume-list pour obtenir l'ID volume, puis exécutez ibmcloud sl block volume-detail <volume_ID> pour obtenir les détails de votre volume.

   region

   Entrez la région où se trouve votre espace de stockage de blocs. Notez que votre cluster et votre espace de stockage doivent être dans la même région. Pour rechercher l'emplacement de votre cluster, exécutez ibmcloud ks cluster ls. Pour plus d'informations sur les régions et zones disponibles, voir Régions et zones. Par exemple, us-east.

   zone

   Entrez la zone dans laquelle se trouve votre volume de stockage. Pour extraire vos détails de volume, exécutez ibmcloud sl block volume-list pour obtenir l'ID volume, puis exécutez ibmcloud sl block volume-detail <volume_ID> pour obtenir les détails de votre volume. Notez que pour connecter le stockage de bloc à votre cluster, vous devez disposer d'un poste de travail dans la même zone que le volume à joindre. Pour rechercher les zones de vos nœuds worker, exécutez ibmcloud ks worker ls -c <cluster>. Par exemple, wdc04.

   storage

   Entrez la taille de stockage du volume de stockage de bloc existant que vous souhaitez connecter à votre cluster. La taille de stockage doit être indiquée en gigaoctets, par exemple 20Gi (20 Go) ou 1000Gi (1 To). Pour extraire vos détails de volume, exécutez ibmcloud sl block volume-list pour obtenir l'ID volume, puis exécutez ibmcloud sl block volume-detail <volume_ID> pour obtenir les détails de votre volume.

   fsType

   Entrez le type de système de fichiers configuré pour votre stockage par blocs existant. Choisissez entre ext4 ou xfs. Si vous ne spécifiez pas cette option, la valeur par défaut est ext4. Si le mauvais type fsType est défini, la création du volume persistant aboutit, mais le montage de ce volume sur un pod est voué à l'échec. Pour extraire vos détails de volume, exécutez ibmcloud sl block volume-list pour obtenir l'ID volume, puis exécutez ibmcloud sl block volume-detail <volume_ID> pour obtenir les détails de votre volume.

   Lun

   Entrez l'ID du numéro d'unité logique de votre volume de stockage de bloc. Pour extraire vos détails de volume, exécutez ibmcloud sl block volume-list pour obtenir l'ID volume, puis exécutez ibmcloud sl block volume-detail <volume_ID> pour obtenir les détails de votre volume.

   TargetPortal

   Entrez l'adresse IP de votre espace de stockage. Pour extraire le paramètre TargetPortal, exécutez ibmcloud sl block volume-list pour obtenir l'ID volume, puis exécutez ibmcloud sl block volume-detail <volume_ID> et notez le Target IP dans la sortie.

   VolumeId

   Entrez l'ID de votre espace de stockage. Pour extraire les détails de votre volume, exécutez ibmcloud sl block volume-list.

   volumeName

   Entrez la même valeur que votre nom de volume persistant. Par exemple, block-storage-pv.

5. Créez le volume persistant dans votre cluster.

   kubectl apply -f pv.yaml
   

6. Vérifiez que le volume persistant (PV) est créé.

   kubectl get pv
   

7. Créez un autre fichier de configuration pour créer votre PVC. Pour que cette réservation corresponde au volume persistant que vous avez créé auparavant, vous devez sélectionner la même valeur pour storage et accessMode. La zone storage-class doit contenir une chaîne vide. Si l'un de ces champs ne correspond pas au volume persistant, alors un nouveau volume persistant est créé automatiquement.

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

8. Créez votre PVC.

   kubectl apply -f static-pvc.yaml
   

9. Vérifiez que votre PVC est créée et liée au volume persistant que vous avez créé auparavant. Ce processus peut prendre quelques minutes.

   kubectl describe pvc static-pvc
   

   Exemple de sortie

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

10. Facultatif Sauvegardez l'exemple de configuration de pod suivant en tant que fichier appelé 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. Créez le pod dans votre cluster.

    kubectl create -f pod.yaml
    

12. Une fois que le pod est à l'état Running, obtenez les journaux.

    kubectl logs
    

    Exemple de sortie

    2022-01-21 16:11:00
    

Vous venez de créer un volume persistant que vous avez lié à une PVC. Ensuite, vous avez déployé cette application qui utilise le stockage par bloc. Les utilisateurs de cluster peuvent désormais monter le circuit virtuel permanent à leurs déploiements et commencer à lire et à écrire dans le volume persistant.

Création du circuit virtuel permanent à l'aide de l'application des accès dynamique lorsque vous créez un ensemble avec état

Utilisez cette option pour créer automatiquement la PVC lorsque vous créez l'ensemble avec état.

Avant de commencer : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Procédez comme suit pour vérifier que tous les ensembles avec état existants dans votre cluster sont entièrement déployés. Si un ensemble avec état est encore en cours de déploiement, vous ne pouvez pas commencer à créer votre ensemble avec état. Vous devez attendre jusqu'à ce que tous les ensembles avec état de votre cluster soient entièrement déployés pour éviter d'obtenir des résultats imprévisibles.

1. Répertoriez les ensembles avec état existants dans votre cluster.

   kubectl get statefulset --all-namespaces
   

   Exemple de sortie

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. Affichez le statut des pods de chaque ensemble avec état pour vérifier que le déploiement de tous les ensembles avec état est terminé.

   kubectl describe statefulset <statefulset_name>
   

   Exemple de sortie

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

   Un ensemble avec état est entièrement déployé lorsque le nombre de répliques que vous trouvez dans la section Replicas de la sortie de l'interface de ligne de commande est égale au nombre de pods en cours d'exécution (Running) dans la section Pods Status. Si un ensemble avec état n'est pas tout à fait déployé, patientez jusqu'à ce que le déploiement soit terminé avant de poursuivre.

3. Créez un fichier de configuration pour votre ensemble avec état et le service que vous utilisez pour exposer cet ensemble. L'exemple suivant montre comment déployer NGINX sous forme d'ensemble avec état avec trois répliques. Pour chaque réplique, une unité de stockage par blocs de 20 gigaoctets est mise à disposition en fonction des spécifications qui sont définies dans la classe de stockage ibmc-block-retain-bronze. Toutes les unités de stockage sont mises à disposition dans la zone dal10. Étant donné que l'espace de stockage de bloc n'est pas accessible à partir d'autres zones, toutes les répliques de l'ensemble avec état sont également déployées sur des nœuds worker situés dans dal10.

   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
   

   L'exemple suivant montre comment déployer NGINX sous forme d'ensemble avec état avec trois répliques. L'ensemble avec état n'indique pas la région et la zone où est créé le stockage par blocs. A la place, l'ensemble avec état utilise une règle d'anti-affinité pour garantir que les pods sont répartis sur les noeuds worker et les zones. En définissant topologykey: failure-domain.beta.kubernetes.io/zone, le planificateur de Kubernetes ne peut pas planifier un pod sur un nœud worker si celui-ci se trouve dans la même zone qu'un pod portant le libellé app: nginx. Pour chaque pod d'ensemble avec état, deux PVC sont créées selon la définition indiquée à la section volumeClaimTemplates, mais la création des instances de stockage par blocs est retardée jusqu'à ce qu'un pod d'ensemble avec état qui utilise le stockage soit planifié. Cette configuration est appelée « planification des volumes tenant compte de la topologie ».

   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

   Entrez un nom pour votre ensemble avec état. Le nom entré est utilisé pour créer le nom de votre PVC au format : <volume_name>-<statefulset_name>-<replica_number>.

   serviceName

   Entrez le nom du service que vous souhaitez utiliser pour exposer votre ensemble avec état.

   replicas

   Entrez le nombre de répliques de votre ensemble avec état.

   podManagementPolicy

   Entrez la règle de gestion de pod que vous souhaitez utiliser pour votre ensemble avec état.

   • OrderedReady : avec cette option, les répliques de l'ensemble avec état sont déployées l'une après l'autre. Par exemple, si vous avez spécifié trois répliques, Kubernetes crée la PVC pour la première réplique, attend jusqu'à ce que la PVC soit liée, déploie la réplique de l'ensemble avec état et monte la PVC sur la réplique. Une fois le déploiement terminé, la deuxième réplique est déployée. Pour plus d'informations sur cette option, consultez la section « Gestion des pods » sur OrderedReady
   • Parallel : avec cette option, le déploiement de toutes les répliques de l'ensemble avec état démarre en même temps. Si votre application prend en charge le déploiement parallèle des répliques, utilisez cette option afin de gagner du temps pour le déploiement de vos PVC et des répliques de l'ensemble avec état.

   matchLabels

   Dans la section spec.selector, entrez tous les libellés que vous souhaitez inclure dans votre ensemble avec état et votre PVC. Les libellés que vous indiquez dans la section volumeClaimTemplates de votre ensemble avec état ne sont pas reconnus par Kubernetes. Exemples de libellés que vous pouvez envisager d'inclure :

   • Région et Zone : si vous souhaitez que toutes les répliques d'ensemble avec état et les PVC soient créées dans une zone spécifique, ajoutez les deux libellés. Vous pouvez également indiquer la zone et la région dans la classe de stockage que vous utilisez. Si vous ne spécifiez pas de zone et de région et que vous disposez d'un cluster à zones multiples, la zone dans laquelle votre espace de stockage est mis à disposition est sélectionnée sur une base de permutation circulaire pour équilibrer les demandes de volume également dans toutes les zones.
   • billingType: Indiquez le type de facturation que vous souhaitez utiliser pour vos PVC. Choisissez entre une facturation à l'heure (hourly) ou au mois (monthly). Si vous ne spécifiez pas ce libellé, tous les PVC sont créés avec un type de facturation horaire.

   labels

   Dans la section de métadonnées du modèle de spécification, entrez les mêmes libellés que ceux que vous avez ajoutés dans la section spec.selector.matchLabels.

   affinity

   Dans la section spec.templace.sec, spécifiez votre règle d'anti-affinité pour garantir que les pods de votre ensemble avec état sont répartis sur les noeuds worker et les zones. L'exemple montre une règle d'anti-affinité dans laquelle le pod de l'ensemble avec état préfère ne pas être planifié sur un noeud worker où s'exécute un pod avec le libellé app: nginx. La section topologykey: failure-domain.beta.kubernetes.io/zone limite davantage cette règle d'anti-affinité et empêche la planification du pod sur un noeud worker si ce noeud figure dans la même zone que le pod ayant le libellé app: nginx. En utilisant cette règle d'anti-affinité, vous pouvez appliquer l'anti-affinité aux différents noeuds worker et aux différentes zones.

   name

   Dans la section spec.volume.claim.templates.metadata, entrez un nom pour votre volume. Utilisez le même nom que vous avez défini dans la section spec.containers.volumeMount.name. Le nom que vous entrez ici est utilisé pour créer le nom de votre PVC au format : <volume_name>-<statefulset_name>-<replica_number>.

   storage

   Dans la section spec.volume.claim.templates.spec.resources.requests, entrez la taille du stockage par blocs en gigaoctets (Gi).

   iops

   Dans la section spec.volume.claim.templates.spec.resources.requests, si vous souhaitez mettre à disposition du stockage de type performance, entrez le nombre d'IOPS. Si vous utilisez une classe de stockage Endurance et que vous indiquez un nombre d'IOPS, le nombre d'IOPS est ignoré. Le nombre d'IOPS indiqué dans votre classe de stockage est utilisé à la place.

   storageClassName

   Dans la section spec.volume.claim.templates.spec, entrez la classe de stockage que vous souhaitez utiliser. Pour afficher la liste des classes de stockage existantes, exécutez la commande « kubectl get sc | grep block ». Si vous ne spécifiez pas de classe de stockage, le PVC est créé avec la classe de stockage par défaut définie dans votre cluster. Vérifiez que la classe de stockage par défaut comporte ibm.io/ibmc-block dans la section 'provisioner' de sorte que votre ensemble avec état soit mis à disposition avec du stockage par blocs.

4. Créez votre ensemble avec état.

   kubectl apply -f statefulset.yaml
   

5. Patientez jusqu'à ce que votre ensemble avec état soit déployé.

   kubectl describe statefulset <statefulset_name>
   

   Pour voir le statut actuel de vos PVC, exécutez la commande kubectl get pvc. Le nom de votre PVC est formaté en tant que <volume_name>-<statefulset_name>-<replica_number>.

Provisionnement statique à l'aide de PVC existants avec un « stateful set »

Vous pouvez mettre à disposition vos PVC de manière anticipée avant de créer votre ensemble avec état ou utiliser des PVC existantes avec votre ensemble avec état.

Lorsque vous effectuez une mise à disposition dynamique de vos PVC lors de la création de l'ensemble avec état, le nom de la PVC est affecté en fonction des valeurs que vous avez utilisées dans le fichier YAML de l'ensemble avec état. Pour que l'ensemble avec état utilise des PVC existantes, le nom de vos PVC doit correspondre à celui qui serait automatiquement créé via une mise à disposition dynamique.

Avant de commencer : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

1. Si vous souhaitez effectuer une mise à disposition préalable de la PVC pour votre ensemble avec état avant de créer l'ensemble avec état, suivez les étapes 1 à 3 de la section Ajout de stockage par blocs à des applications pour créer une PVC pour chaque réplique de l'ensemble avec état. Assurez-vous de créer votre PVC avec un nom qui suit le format suivant : <volume_name>-<statefulset_name>-<replica_number>.

volume_name

Utilisez le nom que vous souhaitez spécifier dans la section spec.volumeClaimTemplates.metadata.name de votre ensemble avec état, par exemple nginxvol.

statefulset_name

Utilisez le nom que vous souhaitez spécifier dans la section metadata.name de votre ensemble avec état, par exemple nginx_statefulset.

replica_number

Entrez le numéro de votre réplique, en commençant par 0.

Par exemple, si vous devez créer trois répliques de l'ensemble avec état, créez trois PVC avec les noms suivants : nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 et nginxvol-nginx_statefulset-2.

Vous envisagez de créer une PVC et un volume persistant pour une unité de stockage existante ? Créez votre PVC et le volume persistant en utilisant une mise à disposition statique.

1. Suivez les étapes indiquées à la section Mise à disposition dynamique : Création de la PVC lorsque vous créez un ensemble avec état pour créer votre ensemble avec état. Le nom de votre PVC suit le format <volume_name>-<statefulset_name>-<replica_number>. Veillez à utiliser les valeurs suivantes pour le nom de votre PVC dans la spécification de l'ensemble avec état : spec.volumeClaimTemplates.metadata.name : Entrez le <volume_name> de votre nom de PVC.

metadata.name

Entrez le <statefulset_name> de votre nom de PVC.

spec.replicas

Entrez le nombre de répliques que vous souhaitez créer pour votre ensemble avec état. Le nombre de répliques doit être égal au nombre de PVC que vous avez créées précédemment.

Si vos PVC se trouvent dans des zones différentes, n'incluez pas d'étiquette de région ou de zone dans votre ensemble avec état.

1. Vérifiez que les réservations de volume persistant sont utilisées dans vos pods de réplique d'ensemble avec état en répertoriant les pods de votre cluster. Identifiez les pods appartenant à votre ensemble avec état.

   kubectl get pods
   

2. Vérifiez que votre PVC existante est montée sur la réplique de votre ensemble avec état. Examinez la valeur de ClaimName dans la section Volumes de la sortie de l'interface de ligne de commande.

   kubectl describe pod <pod_name>
   

   Exemple de sortie

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

Configuration de la prise régulière d'instantanés

Vous pouvez configurer la prise régulière d'instantanés pour votre stockage par blocs, ce qui consiste en une image en lecture seule qui capture l'état de l'instance à un moment donné.

Pour stocker l'instantané, vous devez demander de l'espace d'instantané dans votre stockage par blocs. Les instantanés sont stockés dans l'instance de stockage existante figurant dans la même zone. Vous pouvez restaurer des données à partir d'un instantané si un utilisateur supprime accidentellement des données importantes du volume. \n \n ** Pour créer une image instantanée pour votre volume, procédez comme suit.

1. Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

2. Connectez-vous à l'interface de ligne de commande ibmcloud sl.

   ibmcloud sl init
   

3. Répertoriez les volumes persistants existants dans votre cluster.

   kubectl get pv
   

4. Obtenez les détails du volume persistant pour lequel vous voulez créer un espace d'instantané et notez l'ID du volume, la taille et le nombre d'entrées-sorties par seconde (IOPS). La taille et le nombre d'IOPS sont affichés dans la section Labels de la sortie de l'interface de ligne de commande.

   kubectl describe pv <pv_name>
   

5. Pour trouver l'ID du volume, consultez l'annotation ibm.io/network-storage-id dans la sortie de l'interface de ligne de commande.

6. Créez la taille de l'instantané pour le volume existant à l'aide des paramètres que vous avez récupérés à l'étape précédente.

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

7. Attendez que la taille de l'instantané soit créée. La taille de l'instantané est mise à disposition lorsque la section Snapshot Size (GB) de la sortie de l'interface de ligne de commande passe de 0 à la taille que vous avez commandée.

   ibmcloud sl block volume-detail <volume_ID>
   

8. Créez l'instantané de votre volume et notez l'ID de l'instantané qui a été créé pour vous.

   ibmcloud sl block snapshot-create <volume_ID>
   

9. Vérifiez que la création de l'instantané a abouti.

   ibmcloud sl block snapshot-list <volume_ID>
   

10. Définissez la planification de l'image instantanée. Pour plus d'informations sur les options disponibles pour votre planification d'instantané, voir la documentation de l'interface de ligne de commande.

    ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
    

11. Pour restaurer les données d'un instantané sur un volume existant, exécutez la commande suivante :

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

Réplication d'instantanés dans une autre zone

Pour protéger vos données en cas de défaillance d'une zone, vous pouvez répliquer des instantanés sur une instance de stockage par blocs configurée dans une autre zone.

Les données peuvent être répliquées du stockage principal uniquement vers le stockage de sauvegarde. Vous ne pouvez pas monter une instance de stockage de blocs répliquée sur un cluster. En cas de défaillance de votre stockage principal, vous pouvez manuellement définir votre stockage de sauvegarde répliqué comme stockage principal. Vous pouvez ensuite le monter sur votre cluster. Une fois votre stockage principal restauré, vous pouvez récupérer les données dans le stockage de sauvegarde.

Duplication du stockage

Vous pouvez dupliquer votre instance de stockage par blocs dans la même zone que l'instance de stockage d'origine.

Un doublon contient les mêmes données que l'instance de stockage d'origine au moment où vous créez le doublon. Contrairement aux répliques, le doublon s'utilise comme une instance de stockage indépendante de l'original. Pour effectuer la duplication, configurez d'abord des instantanés pour le volume.

Sauvegarde des données dans IBM Cloud® Object Storage

Vous pouvez utiliser la charte Helm ibm-backup-restore pour constituer un pod de sauvegarde et de restauration dans votre cluster.

Ce pod contient un script pour exécuter une sauvegarde unique ou régulière d'une réservation de volume persistant (PVC) dans votre cluster. Les données sont stockées dans votre instance IBM Cloud® Object Storage que vous avez configurée dans une zone.

Le stockage par blocs est monté avec un mode d'accès RWO. Ce type d'accès autorise uniquement le montage d'un pod à la fois sur le stockage par blocs. Pour sauvegarder vos données, vous devez démonter le pod d'application du stockage, le monter sur votre pod de sauvegarde, sauvegarder les données et monter à nouveau le stockage sur votre pod d'application.

Pour rendre vos données hautement disponibles et protéger votre application en cas de défaillance d'une zone, configurez une deuxième instance Object Storage et répliquez les données entre les différentes zones. Si vous devez restaurer des données à partir de votre instance Object Storage, utilisez le pod de restauration fourni avec la charte Helm.

Copie de données vers et depuis des pods et des conteneurs

Vous pouvez utiliser la commande kubectl cp pour copier des fichiers et des répertoires vers et depuis des pods ou des conteneurs spécifiques de votre cluster.

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Lorsque vous exécutez la commande kubectl cp, si vous ne spécifiez pas de conteneur avec -c, la commande utilise le premier conteneur disponible dans le pod.

Copiez les données de votre machine locale vers un pod de votre cluster.

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

Copiez les données d'un pod de votre cluster vers votre machine locale.

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

Copiez les données de votre machine locale vers un conteneur spécifique qui s'exécute dans un pod de votre cluster.

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

Bronze

Nom

ibmc-block-bronze

ibmc-block-retain-bronze

Type

Stockage d'endurance

Système de fichiers

ext4

IOPS par gigaoctet

2

Plage de tailles en gigaoctets

20 - 12000 Gi

Disque dur

SSD

Stratégie de récupération

ibmc-block-bronze : Supprimer

ibmc-block-retain-bronze : Conserver

Silver

Nom

ibmc-block-silver

ibmc-block-retain-silver

Type

Stockage d'endurance

Système de fichiers

ext4

IOPS par gigaoctet

4

Plage de tailles en gigaoctets

20 - 12000 Gi

Disque dur

SSD

Stratégie de récupération

ibmc-block-silver : Supprimer

ibmc-block-retain-silver : Conserver

Gold

Nom

ibmc-block-gold

ibmc-block-retain-gold

Type

Stockage d'endurance

Système de fichiers

ext4

IOPS par gigaoctet

10

Plage de tailles en gigaoctets

20 - 4000 Gi

Disque dur

SSD

Stratégie de récupération

ibmc-block-gold : Supprimer

ibmc-block-retain-gold : Conserver

Personnalisé

Nom

ibmc-block-custom

ibmc-block-retain-custom

Type

Système de fichiers de performances

ext4

IOPS et taille

Plage de taille en gigaoctets / plage IOPS en multiples de 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

Disque dur

Rapport IOPS/gigaoctet qui détermine le type de disque dur mis à disposition. Pour déterminer ce rapport, divisez la valeur des IOPS par la taille de votre stockage.

Exemple : Vous avez choisi 500Gi de stockage avec 100 IOPS. Votre rapport est 0,2 (100 IOPS/500Gi).

Présentation des types de disque dur par ratio :

• Inférieur ou égal à 0,3 : SATA
• Supérieur à 0,3 : SSD

Stratégie de récupération

ibmc-block-custom : Supprimer

ibmc-block-retain-custom : Conserver

Création de stockage tenant compte de la topologie

Pour utiliser du stockage par blocs dans un cluster multizone, votre pod doit être planifié dans la même zone que votre instance de stockage par blocs pour que vous puissiez effectuer des opérations de lecture et d'écriture dans le volume. Avant l'introduction de ce type de planification par Kubernetes, la mise à disposition dynamique de votre stockage créait automatiquement l'instance de stockage par blocs dès qu'une PVC était créée. Ensuite, lorsque vous créiez votre pod, le planificateur de Kubernetes essayait de déployer le pod dans le même centre de données que votre instance de stockage par blocs.

La création de l'instance de stockage par blocs sans connaître les contraintes liées au pod peut entraîner des résultats indésirables. Par exemple, il peut arriver que votre pod ne puisse pas être planifié sur le même noeud worker que votre stockage car ce noeud ne dispose pas de ressources suffisantes ou une tache lui est appliquée et il n'autorise pas la planification du pod. Avec une planification de volume tenant compte de la topologie, la création de l'instance de stockage par blocs est différée jusqu'à ce que le premier pod utilisant le stockage soit créé.

Pour utiliser la planification de volume tenant compte de la topologie, vérifiez que vous avez installé le plug-in IBM Cloud Block Storage version 1.2.0 ou ultérieure.

Les exemples suivants montrent comment créer des classes de stockage qui retardent la création de l'instance de stockage par blocs jusqu'à ce que le premier pod utilisant ce stockage soit prêt à être planifié. Pour différer la création, vous devez inclure l'option volumeBindingMode: WaitForFirstConsumer. Si vous n'incluez pas cette option, volumeBindingMode est automatiquement défini sur Immediate et l'instance de stockage de bloc est créée lorsque vous créez le PVC.

Exemple relatif au stockage par blocs de type Endurance.

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

Exemple relatif au stockage par blocs de type Performance.

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

Spécification de la zone et de la région

Si vous souhaitez créer votre stockage par blocs dans une zone précise, vous pouvez spécifier la zone et la région dans une classe de stockage personnalisée.

Utilisez la classe de stockage personnalisée avec le plug-in IBM Cloud Block Storage version 1.0.0 ou pour mettre à disposition du stockage par blocs de manière statique dans une zone spécifique. Dans tous les autres cas, indiquez la zone directement dans votre PVC.

Le fichier .yaml suivant personnalise une classe de stockage basée sur la classe de stockage ibm-block-silver sans retain : le type type est "Endurance", le nombre d'IOPS par gigaoctet (iopsPerGB) est 4, la plage de tailles (sizeRange) est "[20-12000]Gi" et la règle de récupération (reclaimPolicy) est définie par "Delete". La zone indiquée est dal12. Pour utiliser une autre classe de stockage comme référence, voir la rubrique Référence des classes de stockage.

Créez la classe de stockage dans la même région et dans la même zone que votre cluster et vos noeuds worker. Pour obtenir la région de votre cluster, exécutez ibmcloud ks cluster get --cluster <cluster_name_or_ID> et recherchez le préfixe de région dans URL principale, tel que eu-de dans https://c2.eu-de.containers.cloud.ibm.com:11111. Pour obtenir la zone de votre noeud worker, exécutez ibmcloud ks worker ls --cluster <cluster_name_or_ID>.

Exemple relatif au stockage par blocs de type Endurance.

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"

Exemple relatif au stockage par blocs de type Performance.

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"

Montage de stockage par blocs avec un système de fichiers XFS

Les exemples suivants illustrent la création d'une classe de stockage qui met à disposition du stockage par blocs avec un système de fichiers XFS.

Exemple relatif au stockage par blocs de type Endurance.

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"

Exemple relatif au stockage par blocs de type Performance.

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"

Description de vos options de retrait de stockage

La procédure de retrait du stockage persistant de votre compte IBM Cloud varie en fonction de la façon dont vous avez mis à disposition le stockage et des composants que vous avez déjà retirés.

Mon stockage persistant est-il supprimé lorsque je supprime mon cluster?

Lors de la suppression du cluster, vous avez la possibilité de retirer votre stockage persistant. Toutefois, selon la façon dont votre stockage a été mis à disposition, la procédure de retrait de votre stockage peut ne pas inclure tous les composants de stockage. Si vous avez provisionné dynamiquement du stockage avec une classe de stockage définissant l'option « reclaimPolicy: Delete », votre PVC, votre PV et l'instance de stockage sont automatiquement supprimés lorsque vous supprimez le cluster. Pour le stockage provisionné de manière statique ou celui que vous avez provisionné avec une classe de stockage définissant l'option « reclaimPolicy: Retain », le PVC et le PV sont supprimés lorsque vous supprimez le cluster, mais votre instance de stockage et vos données sont conservées. L'utilisation de votre instance de stockage vous est toujours facturée. Par ailleurs, si vous avez supprimé votre cluster alors qu'il n'était pas à l'état sain, le stockage peut encore exister, même si vous choisissez de le supprimer.

Comment puis-je supprimer l'espace de stockage tout en conservant mon cluster?

Lorsque vous avez mis à disposition le stockage de façon dynamique avec une classe de stockage indiquant reclaimPolicy: Delete, vous pouvez retirer la réservation de volume persistant (PVC) pour lancer le processus de suppression de votre stockage persistant. Votre réservation de volume persistant (PVC), votre volume persistant (PV) et votre instance de stockage sont automatiquement retirés. Pour le stockage provisionné de manière statique ou celui que vous avez provisionné avec une classe de stockage définissant l'option « reclaimPolicy: Retain », vous devez supprimer manuellement le PVC, le PV et l'instance de stockage afin d'éviter toute facturation supplémentaire.

Comment la facturation prend-elle fin une fois que j'ai supprimé mon espace de stockage?

Selon les composants de stockage que vous supprimez et le moment auquel vous les supprimez, il se peut que le cycle de facturation ne s'arrête pas immédiatement. Si vous supprimez la réservation de volume persistant et le volume persistant, mais pas l'instance dans votre compte IBM Cloud, cette instance continue à exister et vous êtes facturé pour son utilisation.

Si vous supprimez la PVC, le PV et l'instance de stockage, le cycle de facturation s'arrête en fonction du type de facturation (billingType) que vous avez choisi lors de la mise à disposition de votre stockage et de la façon dont vous avez choisi de supprimer le stockage.

• Lorsque vous supprimez manuellement l'instance de stockage persistant depuis la console IBM Cloud ou l'interface de ligne de commande (CLI), la facturation prend fin comme suit :

  • Stockage horaire : la facturation cesse immédiatement. Une fois votre stockage annulé, il se peut que votre instance de stockage soit toujours visible dans la console pendant une durée maximale de 72 heures.
  • Stockage mensuel : vous pouvez choisir l'option Annulation immédiate ou Annulation à la date anniversaire. Dans les deux cas, la facturation se poursuit jusqu'à la fin du cycle de facturation en cours et cesse pour le cycle de facturation suivant. Une fois votre stockage annulé, il se peut que votre instance de stockage soit toujours visible dans la console ou l'interface de ligne de commande pendant une durée maximale de 72 heures.
  • Annulation immédiate : choisissez cette option pour retirer immédiatement votre stockage. Ni vous ni vos utilisateurs ne pouvez plus utiliser le stockage ou récupérer les données.
  • Annulation à la date anniversaire : choisissez cette option pour annuler votre stockage à la date anniversaire suivante. Vos instances de stockage restent actives jusqu'à la date anniversaire suivante et vous pouvez continuer de les utiliser jusqu'à cette date, par exemple, afin de permettre à votre équipe de créer des copies de sauvegarde de vos données.

• Lorsque vous avez mis à disposition le stockage de façon dynamique avec une classe de stockage indiquant reclaimPolicy: Delete que vous choisissez de retirer la réservation de volume persistant (PVC), le volume persistant (PV) et l'instance de stockage sont immédiatement retirés. Pour le stockage facturé à l'heure, la facturation s'arrête immédiatement. Pour le stockage facturé au mois, vous êtes facturé jusqu'à la fin du mois en cours. Une fois votre stockage retiré et la facturation arrêtée, il se peut que votre instance de stockage soit toujours visible dans la console ou l'interface de ligne de commande pendant une durée maximale de 72 heures.

Que dois-je savoir avant de supprimer un espace de stockage persistant?

Lorsque vous nettoyez du stockage persistant, vous supprimez toutes les données qui y sont stockées. Si vous avez besoin d'une copie des données, effectuez une sauvegarde.

J'ai supprimé mon instance de stockage. Pourquoi est-ce que je vois toujours mon instance?

Une fois que vous avez retiré le stockage persistant, il peut s'écouler jusqu'à 72 heures avant que le retrait soit total et que le stockage disparaisse de votre console ou interface de ligne de commande IBM Cloud.

Nettoyage de stockage persistant

Retirez la PVC, le PV et l'instance de stockage de votre compte IBM Cloud afin d'éviter d'autres frais liés à votre stockage persistant.

Avant de commencer :

• Vérifiez que vous avez sauvegardé les données que vous souhaitez conserver.
• Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Pour nettoyer des données persistantes :

1. Répertoriez les réservations de volume persistant (PVC) figurant dans votre cluster et notez le nom de la PVC (NAME), la classe de stockage (STORAGECLASS) et le nom du volume persistant lié à la PVC indiqué sous VOLUME.

   kubectl get pvc
   

   Exemple de sortie

   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. Passez en revue la ReclaimPolicy et le billingType correspondant à la classe de stockage.

   kubectl describe storageclass <storageclass_name>
   

   Si la politique de récupération indique Delete, votre volume persistant et le stockage physique sont supprimés en même temps que la PVC. Si la politique de récupération indique Retain ou si vous avez mis à disposition votre stockage sans classe de stockage, votre volume persistant et votre stockage physique ne sont pas supprimés en même temps que la PVC. Vous devez supprimer la PVC, le volume persistant et le stockage physique séparément.

   Si vous êtes facturé tous les mois pour le stockage, vous êtes redevable pour le mois complet, même si vous supprimez le stockage avant la fin du cycle de facturation.

3. Supprimez les pods qui montent la PVC. Répertoriez les pods qui montent la PVC. Si aucun pod n'est retourné dans votre sortie CLI, vous n'avez pas de pod qui utilise le PVC.

   kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
   

   Exemple de sortie

   depl-12345-prz7b:    claim1
   

4. Supprimez le pod utilisant la PVC. Si le pod fait partie d'un déploiement, retirez ce déploiement.

   kubectl delete pod <pod_name>
   

5. Vérifiez que le pod est supprimé.

   kubectl get pods
   

6. Supprimez la PVC.

   kubectl delete pvc <pvc_name>
   

7. Examinez le statut de votre volume persistant. Utilisez le nom du volume persistant que vous avez récupéré précédemment sous VOLUME. Lorsque vous supprimez la PVC, le volume persistant lié à cette PVC est libéré. Selon le mode de mise à disposition de votre stockage, votre volume persistant va passer à l'état Deleting (suppression) si sa suppression est automatique ou à l'état Released (libéré) si vous devez le supprimer manuellement. Remarque : pour les volumes persistants supprimés automatiquement, l'état peut brièvement indiquer Released avant sa suppression définitive. Exécutez à nouveau la commande au bout de quelques minutes pour voir si le volume persistant est supprimé.

   kubectl get pv <pv_name>
   

8. Si votre volume persistant n'est pas supprimé, supprimez-le manuellement.

   kubectl delete pv <pv_name>
   

9. Vérifiez que le volume persistant (PV) est supprimé.

   kubectl get pv
   

10. Répertoriez l'instance de stockage physique que votre volume persistant a pointé et notez la id de l'instance de stockage physique.

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

    Exemple de sortie

    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"}
    

    Description des informations indiquées sous notes :

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

    Le plug-in de stockage utilisé par le cluster.

    "region":"us-south"

    Région dans laquelle se trouve votre cluster.

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    L'ID du cluster associé à l'instance de stockage.

    "type":"Endurance"

    Le type de stockage de fichier ou de bloc, Endurance ou Performance.

    "ns":"default"

    L'espace de nom sur lequel l'instance de stockage est déployée.

    "pvc":"block-storage-pvc"

    Le nom du circuit virtuel permanent associé à l'instance de stockage.

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

    Le PV qui est associé à l'instance de stockage.

    "storageclass":"ibmc-file-gold"

    Type de classe de stockage: bronze, argent, or ou personnalisé.

11. Retirez l'instance de stockage physique.

    ibmcloud sl block volume-cancel <classic_block_id>
    

12. Vérifiez que l'instance de stockage physique est supprimée.

L'exécution du processus de suppression peut durer jusqu'à 72 heures.

ibmcloud sl block volume-list