Configuration de File Storage for Classic

Types de stockage de fichiers

Choisissez le type de File Storage for Classic que vous souhaitez mettre à disposition.

Classes de stockage Bronze, Silver et Gold

Ces classes de stockage fournit un stockage d'endurance. Le stockage Endurance vous permet de choisir la taille de stockage en gigaoctets à des niveaux d'opérations d'entrée-sortie par seconde prédéfinis.

Classe de stockage personnalisée

Cette classe de stockage fournit un stockage de performance. Avec le stockage Performance, vous disposez d'un contrôle accru sur la taille de stockage et les opérations d'entrée-sortie par seconde.

IOPS

Choisissez la taille et le nombre d'IOPS pour File Storage for Classic. La taille et le nombre d'IOPS définissent le nombre total d'IOPS (opérations d'entrée-sortie par seconde) qui sert d'indicateur pour mesurer la rapidité de votre stockage. Plus votre stockage comporte d'IOPS, plus il traite rapidement les opérations de lecture/écriture.

Classes de stockage Bronze, Silver et Gold

Ces classes de stockage sont fournies avec un nombre fixe d'IOPS par gigaoctet et sont mises à disposition sur les disques durs SSD. Le nombre total d'IOPS dépend de la taille de stockage que vous choisissez. Vous pouvez sélectionner tout nombre entier représentant la taille en gigaoctets dans la plage de taille autorisée, par exemple 20 Gi, 256 Gi ou 11854 Gi. Pour déterminer le nombre total d'IOPS, vous devez multiplier les IOPS par la taille sélectionnée. Par exemple, si vous sélectionnez une taille File Storage for Classic de 1000 Gi dans la classe de stockage Silver offrant 4 IOPS par Go, votre stockage dispose d'un total de 4000 IOPS.

Classe de stockage personnalisée

Lorsque vous choisissez cette classe de stockage, vous avez plus de contrôle sur la taille et l'IOPS que vous souhaitez. En ce qui concerne la taille, vous pouvez sélectionner n'importe quel nombre entier comme valeur de gigaoctets dans la plage de tailles autorisée. La taille que vous choisissez détermine la plage d'IOPS dont vous pourrez bénéficier. Vous pouvez choisir une valeur d'IOPS multiple de 100 comprise dans la plage spécifiée. Le nombre d'IOPS que vous choisissez est statique et ne s'adapte pas à la taille du stockage. Par exemple, si vous choisissez 40Gi avec 100 IOPS, le nombre total d'IOPS restera 100.

Le rapport IOPS/gigaoctet détermine le type de disque dur mis à votre disposition. Par exemple, si vous avez 500Gi à 100 IOPS, votre rapport IOPS/gigaoctet est 0,2. Un stockage avec un rapport inférieur ou égal à 0,3 est fourni sur des disques durs SATA. Si votre rapport est supérieur à 0,3, votre stockage est fourni sur des disques durs SSD.

Stratégie de récupération

Déterminez si vous souhaitez conserver vos données après la suppression du cluster ou de la réservation de volume persistant (PVC).

• Pour conserver vos données, choisissez une classe de stockage retain. Lorsque vous supprimez la PVC, seule la réservation de volume persistant est supprimée. Le volume persistant (PV), l'unité de stockage physique dans votre compte d'infrastructure IBM Cloud, ainsi que vos données existent toujours. Pour récupérer le stockage et l'utiliser à nouveau dans votre cluster, vous devez retirer le volume persistant et suivre les étapes d'utilisation de la solution File Storage for Classic existante.
• Si vous souhaitez que le volume persistant, les données et votre unité File Storage for Classic physique soient supprimés en même temps que la PVC, choisissez une classe de stockage sans retain.

Type de facturation

Choisissez entre une facturation à l'heure ou au mois Consultez la tarification pour plus d'informations.

Par défaut, toutes les unités File Storage for Classic sont mises à disposition avec une facturation à l'heure.

Si vous optez pour un type de facturation au mois, lorsque vous supprimez le stockage persistant, vous devez quand même payer les frais mensuels, même si vous ne l'avez utilisé que pendant très peu de temps.

Préparation de votre stockage existant

Avant de commencer à monter votre stockage existant sur une application, vous devez obtenir toutes les informations nécessaires pour votre volume persistant (PV) et préparer le stockage pour le rendre accessible dans votre cluster.

Pour le stockage provisionné avec une classe de stockage « retain ».

Si vous avez mis à disposition du stockage avec une classe de stockage retain, lorsque vous retirez la réservation de volume persistant (PVC), le volume persistant (PV) et l'unité de stockage physique ne sont pas retirés automatiquement. Pour réutiliser le stockage dans votre cluster, vous devez d'abord supprimer le volume persistant restant.

Pour utiliser du stockage existant dans un cluster différent de celui où vous l'avez mis à disposition, suivez les étapes concernant le stockage créé en dehors du cluster pour ajouter le stockage dans le sous-réseau de votre noeud worker.

1. Répertoriez les volumes persistants (PV) existants.

   kubectl get pv
   

   Recherchez le volume persistant (PV) appartenant à votre stockage persistant. Ce PV est à l'état released.

2. Obtenez les détails du volume persistant.

   kubectl describe pv <pv_name>
   

3. Notez les valeurs de CapacityGb, storageClass, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, server et path.

4. Supprimez le volume persistant.

   kubectl delete pv <pv_name>
   

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

   kubectl get pv
   

Pour le stockage persistant provisionné en dehors du cluster

Si vous envisagez d'utiliser du stockage existant que vous avez mis à disposition auparavant mais que vous n'avez encore jamais utilisé dans votre cluster, vous devez le rendre accessible dans le même sous-réseau que vos noeuds worker.

1. Dans le portail d'infrastructure « IBM Cloud », cliquez sur « Stockage ».
2. Cliquez sur File Storage for Classic et, dans le menu Actions, sélectionnez Autoriser l'hôte.
3. Sélectionnez Sous-réseaux.
4. Dans la liste déroulante, sélectionnez le sous-réseau de VLAN privé auquel est connecté votre noeud worker. Pour rechercher le sous-réseau de votre nœud worker, exécutez ibmcloud ks worker ls --cluster <cluster_name> et comparez le Private IP de votre nœud worker au sous-réseau que vous avez trouvé dans la liste déroulante.
5. Cliquez sur Submit.
6. Cliquez sur le nom de l'instance File Storage for Classic.
7. Notez les zones Mount Point, size et Location. La zone Mount Point s'affiche sous la forme <nfs_server>:<file_storage_path>.

Création d'un volume persistant et d'une revendication de volume persistant

1. Créez un fichier de configuration de stockage pour votre volume persistant. Incluez les valeurs que vous avez récupérées précédemment.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   Entrez le nom de l'objet PV à créer.

   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 nœud worker dans la même région et zone.

   storage

   Entrez la taille de stockage du partage de fichiers NFS existant que vous avez récupérée précédemment. Cette taille doit être indiquée en gigaoctets, par exemple 20Gi (20 Go) ou 1000Gi (1 To), et correspondre à celle du partage de fichiers existant.

   accessMode

   Indiquez l'une des options suivantes.

   • ReadWriteMany : la réservation de volume persistant peut être montée par plusieurs pods. Tous les pods peuvent effectuer des opérations de lecture et d'écriture dans le volume.
   • ReadOnlyMany : la réservation de volume persistant peut être montée par plusieurs pods. Tous les pods ont un accès en lecture seule.
   • ReadWriteOnce : la réservation de volume persistant ne peut être montée que par un seul pod. Ce pod peut effectuer des opérations de lecture et d'écriture dans le volume.

   server

   Entrez l'ID du serveur de partage de fichiers NFS que vous avez récupéré précédemment.

   path

   Entrez le chemin d'accès au partage de fichiers NFS que vous avez récupéré précédemment.

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

   kubectl apply -f mypv.yaml
   

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

   kubectl get pv
   

4. 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 à l'instance PV, une nouvelle instance PV et une nouvelle instance de stockage physique sont alors provisionnées de manière dynamique.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. Créez votre PVC.

   kubectl apply -f mypvc.yaml
   

6. Vérifiez que votre PVC est créée et liée au volume persistant (PV).

   kubectl describe pvc mypvc
   

   Exemple de sortie

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

Vous venez de créer un volume persistant que vous avez lié à une PVC. Les utilisateurs du cluster peuvent désormais monter la PVC sur leurs déploiements et commencer à effectuer des opérations de lecture et d'écriture sur l'objet PV.

Création du PVC lorsque vous créez un ensemble avec état à l'aide de la mise à disposition dynamique

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.

1. Vérifiez que tous les ensembles avec état existants de 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. 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.

   Exemple d'ensemble avec état qui spécifie une zone. L'exemple suivant montre comment déployer NGINX sous forme d'ensemble avec état avec 3 répliques. Pour chaque réplique, une unité File Storage for Classic de 20 gigaoctets est mise à disposition en fonction des spécifications indiquées dans la classe de stockage ibmc-file-retain-bronze. Toutes les unités de stockage sont mises à disposition dans la zone dal10. Comme File Storage for Classic n'est pas accessible à partir d'autres zones, toutes les répliques de l'ensemble avec état sont également déployées sur les 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"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           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-file-retain-bronze
   

   Exemple d'ensemble avec état avec une règle d'anti-affinité et création d'instance File Storage for Classic différée. L'exemple suivant montre comment déployer NGINX sous forme d'ensemble avec état avec 3 répliques. L'ensemble avec état n'indique pas la région et la zone où est créé File Storage for Classic. 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. L'anti-affinité des noeuds worker est assurée en définissant le libellé app: nginx. Ce libellé indique au planificateur de Kubernetes de ne pas planifier de pod sur un noeud worker si un pod ayant le même libellé s'exécute déjà sur ce noeud worker. Le libellé 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 qui se trouve dans la même zone qu'un noeud worker qui exécute déjà un pod avec 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 File Storage for Classic 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-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   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:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

   Dans les métadonnées, 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

   Dans la section spec, 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. Sélectionnez l'une des options suivantes.

   • 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é 3 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. Passez en revue les exemples de libellés suivants.

   • region et zone : si vous voulez que toutes les répliques de votre ensemble avec état et toutes vos 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 : entrez le type de facturation que vous désirez 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.template.spec.affinity, 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 pour File Storage for Classic 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 file ». 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-file dans la section 'provisioner' de sorte que votre ensemble avec état soit mis à disposition avec File Storage for Classic.

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

Mise à disposition statique : Utilisation d'une PVC existante avec votre ensemble avec état

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 votre PVC avant de créer l'ensemble avec état, suivez les étapes 1 à 3 de la section Ajout de File Storage for Classic à 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 à partir de 0.

Par exemple, si vous devez créer 3 répliques de l'ensemble avec état, créez 3 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 instance File Storage for Classic 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 PVC sont utilisées dans les pods de réplique de votre ensemble avec état en répertoriant les pods de votre cluster et en identifiant ceux qui appartiennent à 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
   ...
   

Création d'une classe de stockage personnalisée avec une version spécifique d' NFS

1. Créez une classe de stockage personnalisée avec la version NFS que vous voulez mettre à disposition.

2. Créez la classe de stockage dans votre cluster.

   kubectl apply -f nfsversion_storageclass.yaml
   

3. Vérifiez que la classe de stockage personnalisée a été créée.

   kubectl get sc
   

4. Mettez à disposition File Storage for Classic avec votre classe de stockage personnalisée.

Modification de votre PV existant pour utiliser une autre version d' NFS

1. Récupérez le volume persistant (PV) de l'instance File Storage for Classic dont vous voulez modifier la version NFS et notez le nom de ce volume.

   kubectl get pv
   

2. Ajoutez une annotation à votre volume persistant. Remplacez <version_number> par la version NFS que vous souhaitez utiliser. Par exemple, pour passer à NFS version 3.0, entrez 3.

   kubectl patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. Supprimez le pod qui utilise File Storage for Classic et recréez le pod.

   1. Sauvegardez le fichier YAML du pod sur votre machine locale.

       kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
       ```
   2. Supprimez le pod.
   
   ```sh {: pre}
       kubectl deleted pod <pod_name>
       ```
   3. Recréez le pod.
   
   ```sh {: pre}
       kubectl apply -f pod.yaml
       ```
   

4. Patientez jusqu'à la fin du déploiement du pod. Le pod est complètement déployé lorsque le statut passe à Running.

   kubectl get pods
   

5. Connectez-vous à votre pod.

   kubectl exec -it <pod_name> sh
   

6. Vérifiez que l'instance File Storage for Classic a été montée avec la version NFS que vous avez spécifiée auparavant.

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   Exemple de sortie

   nfs vers=3.0
   

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

Vous pouvez configurer la prise d'instantanés régulière de votre instance File Storage for Classic. Un instantané est 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'image instantanée dans votre instance File Storage for Classic. 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 l'utilisateur supprime accidentellement des données importantes du volume.

Pour créer un instantané 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). L'ID du volume, la taille et le nombre d'IOPS se trouvent dans la section Labels de la sortie de l'interface de ligne de commande.

   kubectl describe pv <pv_name>
   

5. 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 file snapshot-order <volume_ID> --size <size> --tier <iops>
   

6. Attendez que la taille de l'instantané soit créée. La taille de l'instantané est mise à disposition avec succès lorsque ** Taille de l'instantané (Go)** dans votre sortie CLI passe de 0 à la taille que vous avez commandée.

   ibmcloud sl file volume-detail <volume_ID>
   

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

   ibmcloud sl file snapshot-create <volume_ID>
   

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

   ibmcloud sl file snapshot-list <volume_ID>
   

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

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

    ibmcloud sl file 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 File Storage for Classic 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 File Storage for Classic 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 File Storage for Classic 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, commencez par configurer des instantanés pour le volume.

Sauvegarde des données dans IBM Cloud® Object Storage

Vous pouvez utiliser le graphique ibm-backup-restore Helm pour démarrer une sauvegarde et restaurer un pod 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.

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 IBM Cloud® Object Storage et répliquez les données entre les différentes zones. Si vous devez restaurer des données à partir de votre instance IBM Cloud® Object Storage, utilisez le script 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.

Avant de commencer : Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster. 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></var> <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

Création de stockage tenant compte de la topologie

Pour utiliser File Storage for Classic dans un cluster multizone, vous devez planifier votre pod dans la même zone que votre instance File Storage for Classic 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 File Storage for Classic 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 sur un noeud worker dans le même centre de données que votre instance File Storage for Classic.

La création de l'instance File Storage for Classic 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 File Storage for Classic est différée jusqu'à ce que le premier pod utilisant le stockage soit créé.

Les exemples suivants montrent comment créer des classes de stockage qui retardent la création de l'instance File Storage for Classic 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 File Storage for Classic est créée lorsque vous créez le PVC.

Exemple pour File Storage for Classic Endurance.

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

Exemple pour File Storage for Classic Performance.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
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 zone pour les clusters multizones

Si vous souhaitez créer votre instance File Storage for Classic 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 si vous souhaitez effectuer une mise à disposition statique de File Storage for Classic dans une zone spécifique. Dans tous les autres cas, indiquez la zone directement dans votre PVC.

Lorsque vous créez la classe de stockage personnalisée, indiquez la même région et la même zone dans lesquelles se trouvent votre cluster et les 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 pour File Storage for Classic Endurance.

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

Exemple pour File Storage for Classic Performance.

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

Modification de la version NFS par défaut

La classe de stockage personnalisée suivante vous permet de définir la version NFS que vous désirez mettre à disposition. Par exemple, pour fournir NFS version 3.0, remplacez <nfs_version> par 3.0.

Exemple pour File Storage for Classic Endurance.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

Exemple pour File Storage for Classic Performance.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  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]"
  mountOptions: nfsvers=<nfs_version>

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 après la suppression de 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 via 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 file volume-list --columns id  --columns notes | grep <pv_name>
    

    Exemple de sortie pour File Storage for Classic.

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

    "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":"mypvc"

    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 file volume-cancel <classic_file_id>
    

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

    ibmcloud sl file volume-list
    

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