Atualizando o plug-in do IBM Cloud Block Storage

É possível fazer upgrade do plug-in existente do IBM Cloud Block Storage para a versão mais recente.

Antes de iniciar: efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

1. Atualize o repositório Helm para recuperar a versão mais recente de todos os gráficos Helm nesse repositório.

   helm repo update
   

2. Opcional: faça download do gráfico Helm mais recente em sua máquina local. Em seguida, extraia o pacote e revise o arquivo release.md para localizar as informações de liberação mais recentes.

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

3. Encontre o nome de liberação e o namespace do gráfico do Helm de armazenamento de blocos que você instalou em seu cluster.

   helm ls -A
   

   Saída de exemplo

   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. Faça upgrade do plug-in do IBM Cloud Block Storage para a versão mais recente. Inclua o nome da liberação e o namespace que você recuperou anteriormente.

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

5. Opcional: quando você atualiza o plug-in, a classe de armazenamento default está desconfigurada. Para configurar a classe de armazenamento padrão para uma classe de armazenamento de sua escolha, execute o comando a seguir.

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

Removendo o plug-in do IBM Cloud Block Storage

Se não quiser provisionar e usar o IBM Cloud Block Storage no cluster, será possível desinstalar o gráfico Helm.

A remoção do plug-in não remove os PVCs, PVs ou dados existentes. Quando você remove o plug-in, todos os pods e conjuntos de daemon relacionados são removidos do cluster. Não é possível provisionar um novo armazenamento de bloco para o cluster ou usar PVCs e PVs de armazenamento de blocos existentes após remover o plug-in.

Antes de Iniciar:

• Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.
• Certifique-se de que não haja PVCs ou PVs no cluster utilizando armazenamento de bloco.

Para remover o plug-in:

1. Encontre o nome do release e o namespace do gráfico de armazenamento de blocos que você instalou em seu cluster.

   helm ls -A
   

   Saída de exemplo

   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. Exclua o plug-in do IBM Cloud Block Storage.

   helm uninstall NAME -n kube-system
   

3. Verifique se os pods de armazenamento de bloco foram removidos.

   kubectl get pods -n kube-system | grep block
   

   A remoção dos pods será bem-sucedida se nenhum pod for exibido na saída da CLI.

4. Verifique se as classes de armazenamento de bloco foram removidas. A remoção das classes de armazenamento será bem-sucedida se nenhuma classe de armazenamento for exibida na saída da CLI.

   kubectl get sc | grep block
   

Criptografia de dados de volume usando sua própria classe de armazenamento

É possível implantar aplicativos que utilizam volumes criptografados criando, primeiro, sua própria classe de armazenamento.

As etapas a seguir explicam como criar uma classe de armazenamento customizado e criptografado que pode ser usada para criar diversas instâncias de armazenamento de bloco criptografado com a mesma configuração. Se você desejar criar um PVC criptografado usando uma das classes de armazenamento fornecidas pela IBM, será possível fazer isso referenciando as credenciais do Key Protect diretamente em seu PVC.

1. Decidir sobre uma configuração de armazenamento.

2. Crie sua própria classe de armazenamento que provisiona uma instância de armazenamento em bloco criptografada, utilizando como base uma das classes de armazenamento fornecidas pelo IBM. É possível recuperar os detalhes uma classe de armazenamento executando kubectl get sc <storageclass_name> -o yaml. O exemplo a seguir é baseado na classe de armazenamento 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. Crie a classe de armazenamento em seu cluster.

   kubectl apply -f storageclass.yaml
   

4. Adicione o Block Storage for Classic ao seu aplicativo usando sua própria classe de armazenamento para criar um PVC.

5. Verifique a criptografia de seus volumes do Block Storage for Classic.

Crie um PVC que referencie seu segredo do Block Storage for Classic

É possível provisionar o Block Storage for Classic criptografado criando um PVC que especifique o segredo do Kubernetes que retém suas credenciais do Key Protect.

As etapas a seguir mostram como é possível referenciar suas credenciais do Key Protect em seu PVC para criar uma instância do Block Storage for Classic criptografada. Para criar diversos volumes criptografados sem especificar as credenciais do Key Protect em cada PVC, é possível criar uma classe de armazenamento customizado e criptografado.

1. Revise as classes de armazenamento do Block Storage for Classic fornecidas para determinar qual classe de armazenamento melhor atende aos seus requisitos de app. Se as classes de armazenamento fornecidas não atenderem aos seus requisitos de app, será possível criar sua própria classe de armazenamento customizada.

2. Crie um arquivo de configuração do PVC denominado pvc.yaml e que referencie o segredo do Kubernetes no qual você armazenou as credenciais de serviço do Key Protect. Para criar esse segredo, consulte Configurando a criptografia para o 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. Crie o PVC em seu cluster.

   kubectl apply -f pvc.yaml
   

4. Verifique o status de seu PVC.

   kubectl get pvc
   

5. Aguarde até que seu PVC seja ligado, em seguida, crie uma implementação que use o seu PVC.

6. Verifique a criptografia de seus volumes do Block Storage for Classic.

Verificando a criptografia de seus volumes do Block Storage for Classic

É possível verificar a criptografia de seus volumes verificando o caminho de montagem do volume.

1. Efetue login em seu pod de app. Substitua <pod_name> pelo nome do pod que monta o seu volume criptografado do Block Storage for Classic.

   kubectl exec <pod_name> -it bash
   

2. Liste o sistema de arquivos de seu pod.

   df -h
   

3. Revise o caminho do sistema de arquivos para o seu volume criptografado do Block Storage for Classic.

   • Os volumes criptografados possuem uma estrutura de caminho de /dev/mapper/<pvc-ID_encrypted>. Neste exemplo, o volume criptografado é montado no caminho do arquivo /test no 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
       ```
   * Os volumes não criptografados têm uma estrutura de caminho de `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
       ```
   

Remover o segredo do Kubernetes não revoga o acesso aos dados do volume. Se você tiver criado uma implementação somente de pod, o pod deverá ser excluído. Se você tiver criado uma implementação, ela deverá ser excluída.

Recuperando as informações do armazenamento de blocos existente

1. Recupere ou gere uma chave de API para sua conta de infraestrutura da IBM Cloud.

   1. Efetue login no Portal de infraestrutura IBM Cloud.
   2. Selecione Conta, depois Usuários e, em seguida, Lista de usuários.
   3. Localize o ID de usuário.
   4. Na coluna CHAVE API, clique em Gerar para gerar uma chave API ou em Visualizar para visualizar a chave API existente.

2. Recupere o nome de usuário da API para sua conta de infraestrutura da IBM Cloud.

   1. No menu Lista de usuários, selecione seu ID de usuário.
   2. Na seção Informações de acesso da API, localize o seu Nome do usuário da API.

3. Efetue login no plug-in da CLI da infraestrutura da IBM Cloud.

   ibmcloud sl init
   

4. Escolha autenticar usando o nome de usuário e a chave de API para sua conta de infraestrutura da IBM Cloud.

5. Insira o nome de usuário e a chave de API que você recuperou nas etapas anteriores.

6. Liste os dispositivos de armazenamento de bloco disponíveis.

   ibmcloud sl block volume-list
   

   Saída de exemplo

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

7. Recupere os detalhes do volume. Substitua <volume_ID> pelo ID do volume do Block storage recuperado na etapa 6.

   ibmcloud sl block volume-detail <volume_ID>
   

   Saída de exemplo

   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. Anote o ID, Capacity, LUN Id, o Datacenter e Target IP do volume que você deseja montar para o cluster. Nota: para montar o armazenamento existente em um cluster, deve-se ter um nó do trabalhador na mesma zona que seu armazenamento. Para verificar a zona do nó do trabalhador, execute ibmcloud ks worker ls --cluster <cluster_name_or_ID>.

Criando um volume persistente (PV) e uma reclamação de volume persistente (PVC) correspondente

1. Opcional: se você tiver um armazenamento que provisionou com uma classe de armazenamento retain, ao remover a PVC, o PV e o dispositivo de armazenamento físico não serão removidos. Para reutilizar o armazenamento em seu cluster, deve-se remover o PV primeiro. Liste os PVs existentes e procure o PV que pertence ao seu armazenamento persistente. O PV está em um estado released.

   kubectl get pv
   

2. Remova o PV.

   kubectl delete pv <pv_name>
   

3. Verificar se o PV é removido.

   kubectl get pv
   

4. Crie um arquivo de configuração para seu PV. Inclua os parâmetros que você recuperou anteriormente.

   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

   Dê um nome ao PV. Por exemplo, block-storage-pv. Note que esse valor também deve ser inserido em spec.FlexVolume.options como o volumeName.

   labels

   Insira a região e a zona que você recuperou anteriormente. Deve-se ter pelo menos um nó do trabalhador na mesma região e zona que o seu armazenamento persistente para montar o armazenamento em seu cluster. Para recuperar detalhes do volume, execute ibmcloud sl block volume-list para obter o ID do volume. Em seguida, execute ibmcloud sl block volume-detail <volume_ID> para obter os detalhes do seu volume.

   region

   Entre na região na qual o Block Storage está localizado. Note que o cluster e o Block Storage devem estar na mesma região. Para localizar o local do cluster, execute ibmcloud ks cluster ls. Para obter mais informações sobre as regiões e zonas disponíveis, consulte regiões e zonas. Por exemplo, us-east.

   zone

   Entre na zona na qual o volume de armazenamento está localizado. Para recuperar detalhes do volume, execute ibmcloud sl block volume-list para obter o ID do volume. Em seguida, execute ibmcloud sl block volume-detail <volume_ID> para obter os detalhes do seu volume. Note que para anexar o Block Storage ao cluster, deve-se ter um nó do trabalhador disponível na mesma zona do volume que você deseja anexar. Para localizar as zonas dos nós do trabalhador, execute ibmcloud ks worker ls -c <cluster>. Por exemplo, wdc04.

   storage

   Insira o tamanho de armazenamento do volume do Block Storage existente que você deseja anexar ao cluster. O tamanho do armazenamento deve ser gravado em gigabytes, por exemplo, 20 Gi (20 GB) ou 1000 Gi (1 TB). Para recuperar detalhes do volume, execute ibmcloud sl block volume-list para obter o ID do volume. Em seguida, execute ibmcloud sl block volume-detail <volume_ID> para obter os detalhes do seu volume.

   fsType

   Insira o tipo de sistema de arquivos que está configurado para seu armazenamento de bloco existente. Escolha entre ext4 ou xfs. Se você não especificar essa opção, o PV será padronizado para ext4. Quando o fsType errado for definido, a criação do PV será bem-sucedida, mas a montagem do PV em um pod falhará. Para recuperar detalhes do volume, execute ibmcloud sl block volume-list para obter o ID do volume. Em seguida, execute ibmcloud sl block volume-detail <volume_ID> para obter os detalhes do seu volume.

   Lun

   Insira o ID de LUN do volume do Block Storage. Para recuperar detalhes do volume, execute ibmcloud sl block volume-list para obter o ID do volume. Em seguida, execute ibmcloud sl block volume-detail <volume_ID> para obter os detalhes do seu volume.

   TargetPortal

   Insira o endereço IP do Block Storage. Para recuperar o parâmetro TargetPortal, execute ibmcloud sl block volume-list para obter o ID de volume e, em seguida, execute ibmcloud sl block volume-detail <volume_ID> e anote o Target IP na saída.

   VolumeId

   Insira o ID do Block Storage. Para recuperar os detalhes do volume, execute ibmcloud sl block volume-list.

   volumeName

   Insira o mesmo valor do nome do PV. Por exemplo, block-storage-pv.

5. Crie o PV em seu cluster.

   kubectl apply -f pv.yaml
   

6. Verifique se o PV é criado.

   kubectl get pv
   

7. Crie outro arquivo de configuração para criar seu PVC. Para que o PVC corresponda ao PV criado anteriormente, deve-se escolher o mesmo valor para storage e accessMode. O campo storage-class deve ser uma sequência de caracteres vazia. Se algum desses campos não corresponder ao PV, um novo PV será criado automaticamente no lugar.

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

8. Crie a PVC.

   kubectl apply -f static-pvc.yaml
   

9. Verifique se o PVC foi criado e está ligado ao PV criado anteriormente. Esse processo pode levar alguns minutos.

   kubectl describe pvc static-pvc
   

   Saída de exemplo

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

10. Opcional Salve a configuração de pod de exemplo a seguir como um arquivo chamado 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. Crie o pod em seu cluster.

    kubectl create -f pod.yaml
    

12. Depois que o pod estiver no status Running, obtenha os logs.

    kubectl logs
    

    Saída de exemplo

    2022-01-21 16:11:00
    

Você criou com êxito um PV e ligou-o a um PVC. Então você implementou um app que usa Block Storage. Agora os usuários de cluster podem montar a PVC para suas implementações e começar a ler e a gravar no volume persistente.

Criando a PVC usando fornecimento dinâmico ao criar um conjunto stateful

Use essa opção se desejar criar automaticamente o PVC ao criar o conjunto stateful.

Antes de iniciar: efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Conclua as etapas a seguir para verificar se todos os conjuntos stateful existentes em seu cluster estão totalmente implementados Se um conjunto stateful ainda estiver sendo implementado, não será possível começar a criar o conjunto stateful. Deve-se aguardar até que todos os conjuntos stateful no cluster estejam totalmente implementados para evitar resultados inesperados.

1. Liste os conjuntos stateful existentes em seu cluster.

   kubectl get statefulset --all-namespaces
   

   Saída de exemplo

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. Visualize o Status dos pods de cada conjunto stateful para assegurar-se de que a implementação do conjunto stateful esteja concluída.

   kubectl describe statefulset <statefulset_name>
   

   Saída de exemplo

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

   Um conjunto stateful é totalmente implementado quando o número de réplicas localizadas na seção Réplicas de sua saída da CLI é igual ao número de pods Em execução na seção Status dos pods. Se um conjunto stateful ainda não estiver totalmente implementado, aguarde até que a implementação seja concluída antes de continuar.

3. Crie um arquivo de configuração para seu conjunto stateful e o serviço usado para expor o conjunto stateful. O exemplo a seguir mostra como implementar NGINX como um conjunto stateful com três réplicas. Para cada réplica, um dispositivo de armazenamento de bloco de 20 gigabyte é provisionado com base nas especificações que são definidas na classe de armazenamento ibmc-block-retain-bronze. Todos os dispositivos de armazenamento são provisionados na zona dal10. Como o Block Storage não pode ser acessado de outras zonas, todas as réplicas do conjunto stateful também serão implementadas em nós do trabalhador localizados em 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
   

   O exemplo a seguir mostra como implementar NGINX como um conjunto stateful com três réplicas. O conjunto stateful não especifica a região e a zona em que o armazenamento de bloco é criado. Em vez disso, o conjunto stateful usa uma regra de antiafinidade para assegurar que os pods sejam distribuídos entre os nós do trabalhador e as zonas. Ao definir topologykey: failure-domain.beta.kubernetes.io/zone, o planejador de Kubernetes não poderá planejar um pod em um nó do trabalhador se o nó do trabalhador estiver na mesma zona que um pod com o rótulo app: nginx. Para cada pod do conjunto stateful, dois PVCs são criados conforme definido na seção volumeClaimTemplates, mas a criação das instâncias de armazenamento de bloco é atrasada até que um pod do conjunto stateful que use o armazenamento seja planejado. Essa configuração é referida como planejamento de volume com reconhecimento de topologia.

   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

   Insira um nome para seu conjunto stateful. O nome inserido é usado para criar o nome da PVC no formato: <volume_name>-<statefulset_name>-<replica_number>.

   serviceName

   Insira o nome do serviço que deseja usar para expor o conjunto stateful.

   replicas

   Insira o número de réplicas para seu conjunto stateful.

   podManagementPolicy

   Insira a política de gerenciamento de pod que deseja usar para o conjunto stateful.

   • OrderedReady: Com essa opção, as réplicas do conjunto stateful são implementadas uma após a outra. Por exemplo, se você especificou três réplicas, o Kubernetes criará o PVC para a sua primeira réplica, esperará até que o PVC seja ligado, implementará a réplica do conjunto stateful e montará o PVC na réplica. Depois que a implementação é concluída, a segunda réplica é implementada. Para obter mais informações sobre esta opção, consulte Gerenciamento de pod OrderedReady
   • Parallel: com esta opção, a implementação de todas as réplicas do conjunto stateful é iniciada ao mesmo tempo. Se o seu app suportar a implementação paralela de réplicas, use essa opção para economizar tempo de implementação para seus PVCs e réplicas do conjunto stateful.

   matchLabels

   Na seção de seletor de especificação, insira todos os rótulos que você deseja incluir em seu conjunto stateful e seu PVC. Os rótulos incluídos no volumeClaimTemplates de seu conjunto stateful não são reconhecidos pelo Kubernetes. Os rótulos de amostra que é possível que você queira incluir são:

   • região e zona: se quiser que todas as réplicas de conjunto stateful e PVCs sejam criadas em uma zona específica, inclua ambos os rótulos. Também é possível especificar a zona e a região na classe de armazenamento usada. Se você não especificar uma zona e região e tiver um cluster multizona, a zona na qual o armazenamento é provisionado será selecionada em uma base round-robin para equilibrar as solicitações de volume uniformemente em todas as zonas.
   • billingType: Insira o tipo de cobrança que você deseja usar para seus PVCs. Escolha entre hourly ou monthly. Se você não especificar esse rótulo, todas as PVCs serão criadas com um tipo de faturamento por hora.

   labels

   Na seção de metadados do modelo de especificação, insira os mesmos rótulos que os incluídos na seção spec.selector.matchLabels.

   affinity

   Na seção de especificação de modelo de especificação, especifique sua regra de antiafinidade para garantir que seus pods de conjunto stateful sejam distribuídos em nós e zonas do trabalhador. O exemplo mostra uma regra de antiafinidade na qual o pod do conjunto stateful prefere não ser planejado em um nó do trabalhador no qual um pod que tem o rótulo app: nginx é executado. O topologykey: failure-domain.beta.kubernetes.io/zone restringe essa regra de antiafinidade ainda mais e evita que o pod seja planejado em um nó trabalhador se o nó do trabalhador estiver na mesma zona que um pod que possui o rótulo app: nginx. Usando essa regra de antiafinidade, é possível alcançar a antiafinidade entre os nós do trabalhador e as zonas.

   name

   Na seção de metadados de modelos de solicitação de volume de especificação, insira um nome para o seu volume. Use o mesmo nome definido na seção spec.containers.volumeMount.name. O nome inserido aqui é usado para criar o nome para a PVC no formato: <volume_name>-<statefulset_name>-<replica_number>.

   storage

   Na seção de solicitações de recursos de especificação de modelos de solicitação de volume de especificação, digite o tamanho do armazenamento de blocos em gigabytes (Gi).

   iops

   Na seção de solicitações de recursos de especificação de modelos de solicitação de volume de especificação, se você desejar provisionar o armazenamento de desempenho, digite o número de IOPS. Se você usar uma classe de armazenamento do Endurance e especificar vários IOPS, o número de IOPS será ignorado. Em vez disso, o IOPS especificado em sua classe de armazenamento é usado.

   storageClassName

   Na seção de especificação de modelos de solicitação de volume de especificação, insira a classe de armazenamento que você deseja usar. Para listar as classes de armazenamento existentes, execute o comando kubectl get sc | grep block``. Se você não especificar uma classe de armazenamento, a PVC será criada com a classe de armazenamento padrão que está configurada no cluster. Certifique-se de que a classe de armazenamento padrão use o provisionador ibm.io/ibmc-block para que seu conjunto stateful seja provisionado com armazenamento de bloco.

4. Crie seu conjunto stateful.

   kubectl apply -f statefulset.yaml
   

5. Aguarde o seu conjunto stateful ser implementado.

   kubectl describe statefulset <statefulset_name>
   

   Para ver o status atual de seus PVCs, execute kubectl get pvc. O nome da PVC é formatado como <volume_name>-<statefulset_name>-<replica_number>.

Provisionamento estático utilizando PVCs existentes com um conjunto com estado

É possível pré-provisionar seus PVCs antes de criar seu conjunto stateful ou usar PVCs existentes com esse conjunto.

Quando você provisionar dinamicamente seus PVCs ao criar o conjunto stateful, o nome do PVC será designado com base nos valores usados no arquivo YAML do conjunto stateful. Para que o conjunto stateful use PVCs existentes, o nome dos PVCs deve corresponder ao nome que seria criado automaticamente ao usar o fornecimento dinâmico.

Antes de iniciar: efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

1. Para pré-fornecer o PVC para seu conjunto stateful antes de criar o conjunto stateful, siga as etapas de 1 a 3 em Incluindo armazenamento de bloco em apps para criar um PVC para cada réplica do conjunto stateful. Certifique-se de criar a PVC com um nome que siga o seguinte formato: <volume_name>-<statefulset_name>-<replica_number>.

volume_name

Use o nome que deseja especificar na seção spec.volumeClaimTemplates.metadata.name do conjunto stateful, como nginxvol.

statefulset_name

Use o nome que deseja especificar na seção metadata.name do conjunto stateful, como nginx_statefulset.

replica_number

Insira o número da réplica, começando com 0.

Por exemplo, se três réplicas de conjunto stateful devem ser criadas, crie três PVCs com nomes a seguir: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 e nginxvol-nginx_statefulset-2.

Procurando criar um PVC e um PV para um dispositivo de armazenamento existente? Crie seu PVC e PV usando o fornecimento estático.

1. Siga as etapas em Fornecimento dinâmico: criando o PVC ao criar um conjunto stateful para criar seu conjunto stateful. O nome da PVC segue o formato <volume_name>-<statefulset_name>-<replica_number>. Certifique-se de usar os valores a seguir de seu nome do PVC na especificação do conjunto stateful: spec.volumeClaimTemplates.metadata.name : Insira o <volume_name> do nome da PVC.

metadata.name

Insira o <statefulset_name> do nome da PVC.

spec.replicas

Insira o número de réplicas que deseja criar para o conjunto stateful. O número de réplicas deve ser igual ao número de PVCs criados anteriormente.

Se as PVCs estiverem em zonas diferentes, não inclua um rótulo de região ou zona no conjunto stateful.

1. Verifique se as PVCs são usadas nos pods de réplica do conjunto stateful listando os pods em seu cluster. Identifique os pods que pertencem ao conjunto stateful.

   kubectl get pods
   

2. Verifique se o PVC existente está montado na réplica do conjunto stateful. Revise o ClaimName na seção Volumes de sua saída da CLI.

   kubectl describe pod <pod_name>
   

   Saída de exemplo

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

Configurar capturas instantâneas periódicas

É possível configurar capturas instantâneas periódicas para o seu armazenamento de bloco, que é uma imagem somente leitura que captura o estado da instância em um momento.

Para armazenar a captura instantânea, deve-se solicitar espaço de captura instantânea em seu armazenamento de bloco. As capturas instantâneas são armazenadas na instância de armazenamento existente dentro da mesma zona. Será possível restaurar dados de uma captura instantânea se um usuário remover dados importantes acidentalmente do volume. \n \n **Para criar uma captura instantânea para o volume, conclua as etapas a seguir.

1. Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

2. Efetue login na CLI ibmcloud sl.

   ibmcloud sl init
   

3. PVs de Lista existente em seu cluster.

   kubectl get pv
   

4. Obtenha os detalhes para o PV para o qual você deseja criar espaço de captura instantânea e anote o ID do volume, o tamanho e o IOPS. O tamanho e o IOPS são mostrados na seção Labels de sua saída da CLI.

   kubectl describe pv <pv_name>
   

5. Para localizar o ID do volume, revise a anotação ibm.io/network-storage-id de sua saída da CLI.

6. Crie o tamanho da captura instantânea para o volume existente com os parâmetros que você recuperou na etapa anterior.

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

7. Espere o tamanho da captura instantânea para criar. O tamanho da captura instantânea é provisionado com êxito quando o Tamanho da captura instantânea (GB) na saída da CLI muda de 0 para o tamanho solicitado.

   ibmcloud sl block volume-detail <volume_ID>
   

8. Crie a captura instantânea para o volume e anote o ID da captura instantânea que é criado para você.

   ibmcloud sl block snapshot-create <volume_ID>
   

9. Verifique se a captura instantânea foi criada com êxito.

   ibmcloud sl block snapshot-list <volume_ID>
   

10. Configure o planejamento de capturas instantâneas Para obter mais informações sobre as opções disponíveis para seu planejamento de captura instantânea, consulte a documentação da CLI.

    ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
    

11. Para restaurar dados de uma captura instantânea para um volume existente, execute o comando a seguir.

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

Replicando capturas instantâneas para outra zona

Para proteger seus dados de uma falha de zona, é possível replicar capturas instantâneas para uma instância de armazenamento de bloco que está configurada em outra zona.

Os dados podem ser replicados do armazenamento primário para o armazenamento de backup somente. Não é possível montar uma instância replicada do Block Storage para um cluster. Quando seu armazenamento primário falha, é possível configurar manualmente o armazenamento de backup replicado para ser o primário. Em seguida, é possível montá-lo para seu cluster. Depois que o armazenamento primário é restaurado, é possível restaurar os dados do armazenamento de backup.

Duplicar o armazenamento

É possível duplicar sua instância de armazenamento de bloco na mesma zona que a instância de armazenamento original.

Uma duplicata tem os mesmos dados que a instância de armazenamento original no momento em que é criada. Diferentemente de réplicas, use a duplicata como uma instância de armazenamento independente da original. Para duplicar, primeiramente configure capturas instantâneas para o volume.

Fazendo backup dos dados para o IBM Cloud® Object Storage

É possível usar o gráfico do Helm ibm-backup-restore para acelerar um pod de backup e restauração no cluster.

Esse pod contém um script para executar um backup único ou periódico para qualquer persistent volume claim (PVC) em seu cluster. Os dados são armazenados em sua instância do IBM Cloud® Object Storage que você configurou em uma zona.

O armazenamento de bloco é montado com um modo de acesso RWO. This access allows only one pod to be mounted to the block storage at a time. Para fazer backup de seus dados, deve-se desmontar o pod do aplicativo do armazenamento, montá-lo em seu pod de backup, fazer backup dos dados e remontar o armazenamento para o pod do aplicativo.

Para tornar os seus dados ainda mais altamente disponíveis e proteger o seu app de uma falha de zona, configure uma segunda instância do Object Storage e replique dados entre as zonas. Se você precisar restaurar dados de sua instância do Object Storage, use o pod de restauração fornecido com o gráfico do Helm.

Copiando dados de e para pods e contêineres

É possível usar o comando kubectl cp para copiar arquivos e diretórios para/de pods ou contêineres específicos no cluster.

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Ao executar o comando kubectl cp, se você não especificar um contêiner com -c, o comando usará o primeiro contêiner disponível no pod.

Copiar dados de sua máquina local para um pod em seu cluster.

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

Copiar dados de um pod em seu cluster para a sua máquina local.

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

Copiar dados de sua máquina local para um contêiner específico que é executado em um pod em seu cluster.

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

Bronze

Nome

ibmc-block-bronze

ibmc-block-retain-bronze

Tipo

Armazenamento de resistência

Sistema de arquivos

ext4

IOPS por gigabyte

2

Intervalo de tamanho em gigabytes

20-12.000 Gi

Disco rígido

SSD

Política de recuperação

ibmc-block-bronze: Excluir

ibmc-block-retain-bronze: Reter

Prata

Nome

ibmc-block-silver

ibmc-block-retain-silver

Tipo

Armazenamento de resistência

Sistema de arquivos

ext4

IOPS por gigabyte

4

Intervalo de tamanho em gigabytes

20-12.000 Gi

Disco rígido

SSD

Política de recuperação

ibmc-block-silver: Excluir

ibmc-block-retain-silver: Reter

Ouro

Nome

ibmc-block-gold

ibmc-block-retain-gold

Tipo

Armazenamento de resistência

Sistema de arquivos

ext4

IOPS por gigabyte

10

Intervalo de tamanho em gigabytes

20-4000 Gi

Disco rígido

SSD

Política de recuperação

ibmc-block-gold: Excluir

ibmc-block-retain-gold: Reter

Customizado

Nome

ibmc-block-custom

ibmc-block-retain-custom

Tipo

Sistema PerformanceFile

ext4

IOPS e tamanho

Faixa de tamanho em gigabytes/intervalo de IOPS em múltiplos 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

Disco rígido

A razão de IOPS para gigabyte determina o tipo de disco rígido que é provisionado. Para determinar a sua razão de IOPS para gigabyte, você divide o IOPS pelo tamanho de seu armazenamento.

Exemplo: você escolheu 500Gi de armazenamento com 100 IOPS. A sua razão é 0,2 (100 IOPS/500 Gi).

Visão geral dos tipos de disco rígido por proporção:

• Menor ou igual a 0,3: SATA
• Maior que 0,3: SSD

Política de recuperação

ibmc-block-custom: Excluir

ibmc-block-retain-custom: Reter

Criando armazenamento de reconhecimento de topologia

Para usar o armazenamento de bloco em um cluster com diversas zonas, seu pod deve ser planejado na mesma zona que a sua instância de armazenamento de bloco para que seja possível ler e gravar no volume. Antes da introdução do planejamento de volume com reconhecimento de topologia pelo Kubernetes, o fornecimento dinâmico de seu armazenamento criava automaticamente a instância de armazenamento de bloco quando um PVC era criado. Em seguida, quando você criou sua pod, o planejador Kubernetes tentou implementar o pod no mesmo centro de dados que sua instância de armazenamento de bloco.

A criação da instância de armazenamento de bloco sem saber as restrições do pod pode levar a resultados indesejados. Por exemplo, seu pod pode não estar apto a ser planejado para o mesmo nó do trabalhador que seu armazenamento porque o nó do trabalhador tem recursos insuficientes ou o nó do trabalhador está contaminado e não permite que o pod seja planejado. Com o planejamento de volume de reconhecimento de topologia, a instância de armazenamento de bloco é atrasada até que o primeiro pod que usa o armazenamento seja criado.

Para usar o planejamento de volume direcionado à topologia, certifique-se de ter instalado o plug-in do IBM Cloud Block Storage versão 1.2.0 ou mais recente.

Os exemplos a seguir mostram como criar classes de armazenamento que atrasem a criação da instância de armazenamento de bloco até que o primeiro pod que usa esse armazenamento esteja pronto para ser planejado. Para atrasar a criação, deve-se incluir a opção volumeBindingMode: WaitForFirstConsumer. Se você não incluir essa opção, o volumeBindingMode será configurado automaticamente como Immediate e a instância do Block Storage será criada na criação da PVC.

Exemplo para o armazenamento de bloco de resistência.

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

Exemplo para o armazenamento de bloco de desempenho.

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

Especificando a zona e a região

Se você deseja criar seu armazenamento de bloco em uma zona específica, será possível especificar a zona e a região em uma classe de armazenamento customizada.

Use a classe de armazenamento customizada se você usar o plug-in IBM Cloud Block Storage versão 1.0.0 ou se você desejar provisionar estaticamente o armazenamento de bloco em uma zona específica. Em todos os outros casos, especifique a zona diretamente em seu PVC.

O arquivo .yaml a seguir customiza uma classe de armazenamento que é baseada na classe de armazenamento sem retenção ibm-block-silver: o type é "Endurance", o iopsPerGB é 4, o sizeRange é "[20-12000]Gi" e o reclaimPolicy é configurado para "Delete". A zona é especificada como dal12. Para usar uma classe de armazenamento diferente como sua base, consulte a referência de classe de armazenamento.

Crie a classe de armazenamento na mesma região e zona que os nós do cluster e do trabalhador. Para obter a região do cluster, execute ibmcloud ks cluster get --cluster <cluster_name_or_ID> e procure o prefixo da região na URL principal, como eu-de em https://c2.eu-de.containers.cloud.ibm.com:11111. Para obter a zona do nó do trabalhador, execute ibmcloud ks worker ls --cluster <cluster_name_or_ID>.

Exemplo para o armazenamento de bloco de resistência.

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"

Exemplo para o armazenamento de bloco de desempenho.

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"

Montando o armazenamento de bloco com um sistema de arquivos XFS

Os exemplos a seguir criam uma classe de armazenamento que provisiona armazenamento de bloco com um sistema de arquivos XFS.

Exemplo para o armazenamento de bloco de resistência.

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"

Exemplo para o armazenamento de bloco de desempenho.

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"

Entendendo suas opções de remoção de armazenamento

A remoção do armazenamento persistente de sua conta do IBM Cloud varia dependendo de como você provisionou o armazenamento e quais componentes você já removeu.

Meu armazenamento persistente é excluído quando eu excluo meu cluster?

Durante a exclusão do cluster, você tem a opção de remover seu armazenamento persistente. No entanto, dependendo de como seu armazenamento foi provisionado, a remoção de seu armazenamento pode não incluir todos os componentes de armazenamento. Se você provisionou dinamicamente o armazenamento com uma classe de armazenamento que define a opção “ reclaimPolicy: Delete ”, seu PVC, PV e a instância de armazenamento serão excluídos automaticamente quando você excluir o cluster. No caso de armazenamento provisionado estaticamente ou de armazenamento provisionado com uma classe de armazenamento que define a opção “ reclaimPolicy: Retain ”, o PVC e o PV são removidos quando você exclui o cluster, mas sua instância de armazenamento e seus dados permanecem. Você ainda é cobrado por sua instância de armazenamento. Além disso, se você excluiu seu cluster em um estado não funcional, o armazenamento ainda poderá existir mesmo se você escolheu removê-lo.

Como faço para excluir o armazenamento se quiser manter meu cluster?

Ao provisionar dinamicamente o armazenamento com uma classe de armazenamento que configura reclaimPolicy: Delete, é possível remover o PVC para iniciar o processo de exclusão de seu armazenamento persistente. O PVC, o PV e a instância de armazenamento são removidos automaticamente. No caso de armazenamento provisionado estaticamente ou de armazenamento provisionado com uma classe de armazenamento que defina a opção “ reclaimPolicy: Retain ”, é necessário remover manualmente o PVC, o PV e a instância de armazenamento para evitar cobranças adicionais.

Como a cobrança é interrompida depois que eu excluir meu espaço de armazenamento?

Dependendo de quais componentes de armazenamento você excluir e quando, o ciclo de faturamento pode não parar imediatamente. Se você excluir o PVC e o PV, mas não a instância de armazenamento em sua conta do IBM Cloud, essa instância ainda existirá e você será cobrado por ela.

Se você excluir o PVC, o PV e a instância de armazenamento, o ciclo de faturamento parará, dependendo do billingType que você escolheu ao provisionar seu armazenamento e de como escolheu excluir o armazenamento.

• Quando você cancela manualmente a instância de armazenamento persistente pelo console do IBM Cloud ou pela CLI, o faturamento é interrompido da seguinte forma:

  • Armazenamento por hora: o faturamento é parado imediatamente. Depois que seu armazenamento for cancelado, você ainda poderá ver sua instância de armazenamento no console por até 72 horas.
  • Armazenamento mensal: é possível escolher entre cancelamento imediato ou cancelamento na data do aniversário. Em ambos os casos, você é faturado até o término do ciclo de faturamento atual e as paradas de faturamento para o próximo ciclo de faturamento. Depois que seu armazenamento for cancelado, você ainda poderá ver sua instância de armazenamento no console ou na CLI por até 72 horas.
  • Cancelamento imediato: escolha essa opção para remover imediatamente seu armazenamento. Nem você nem seus usuários poderão mais usar o armazenamento ou recuperar os dados.
  • Data do aniversário: escolha essa opção para cancelar seu armazenamento na data do próximo aniversário. Suas instâncias de armazenamento permanecem ativas até a data do próximo aniversário e é possível continuar a usá-las até essa data para que a sua equipe tenha tempo para fazer backups dos dados.

• Ao provisionar dinamicamente o armazenamento com uma classe de armazenamento que configura reclaimPolicy: Delete e você optar por remover o PVC, o PV e a instância de armazenamento serão removidos imediatamente. Para armazenamento em faturamento por hora, o faturamento é parado imediatamente. Para o armazenamento faturado mensal, você ainda é cobrado pelo restante do mês. Depois que seu armazenamento for removido e o faturamento for interrompido, você ainda poderá ver sua instância de armazenamento no console ou na CLI por até 72 horas.

O que preciso saber antes de excluir o armazenamento persistente?

Ao limpar o armazenamento persistente, você exclui todos os dados que estão armazenados nele. Se precisar de uma cópia dos dados, faça um backup.

Apaguei minha instância de armazenamento. Por que ainda consigo ver minha instância?

Depois de remover o armazenamento persistente, ele pode levar até 72 horas para que a remoção seja totalmente processada e para que o armazenamento desapareça do console ou da CLI do IBM Cloud.

Limpando o armazenamento persistente

Remova o PVC, o PV e a instância de armazenamento de sua conta do IBM Cloud para evitar encargos adicionais para seu armazenamento persistente.

Antes de Iniciar:

• Certifique-se de ter feito backup de todos os dados que deseja manter.
• Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Para limpar os dados persistentes:

1. Liste os PVCs em seu cluster e anote o NAME do PVC, o STORAGECLASS e o nome do PV que está ligado ao PVC e mostrado como VOLUME.

   kubectl get pvc
   

   Saída de exemplo

   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. Revise o ReclaimPolicy e o billingType para a classe de armazenamento.

   kubectl describe storageclass <storageclass_name>
   

   Se a política de recuperação indicar Delete, seu PV e o armazenamento físico serão removidos quando você remover o PVC. Se a política de recuperação indicar Retain ou se você provisionar o armazenamento sem uma classe de armazenamento, o PV e o armazenamento físico não serão removidos quando o PVC for removido. Deve-se remover o PVC, o PV e o armazenamento físico separadamente.

   Se o seu armazenamento for cobrado mensalmente, você ainda será cobrado pelo mês inteiro, mesmo se remover o armazenamento antes do término do ciclo de faturamento.

3. Remova quaisquer pods que montam o PVC. Liste os pods que montam o PVC. Se nenhum pod for retornado na saída da CLI, você não tem um pod que usa PVC.

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

   Saída de exemplo

   depl-12345-prz7b:    claim1
   

4. Remova o pod que usa o PVC. Se o pod fizer parte de uma implementação, remova a implementação.

   kubectl delete pod <pod_name>
   

5. Verifique se o pod foi removido.

   kubectl get pods
   

6. Remova a PVC.

   kubectl delete pvc <pvc_name>
   

7. Revise o status de seu PV. Use o nome do PV que você recuperou anteriormente como VOLUME. Quando você remove o PVC, o PV que está ligado ao PVC é liberado. Dependendo de como você provisionou seu armazenamento, seu PV entrará em um estado Deleting se o PV for excluído automaticamente ou em um estado Released se o PV deverá ser excluído manualmente. Nota: para PVs que são excluídos automaticamente, o status pode indicar brevemente Released antes de ser excluído. Execute novamente o comando após alguns minutos para ver se o PV foi removido.

   kubectl get pv <pv_name>
   

8. Se o seu PV não for excluído, remova-o manualmente.

   kubectl delete pv <pv_name>
   

9. Verifique se o PV foi removido.

   kubectl get pv
   

10. Liste a instância de armazenamento físico para a qual o PV apontou e observe o id da instância de armazenamento físico.

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

    Saída de exemplo

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

    Entendendo as informações do campo do Notas:

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

    O plug-in de armazenamento que o cluster usa.

    "region":"us-south"

    A região em que seu cluster está.

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    O ID do cluster que está associado à instância de armazenamento.

    "type":"Endurance"

    O tipo de arquivo ou armazenamento de blocos, seja Endurance ou Performance.

    "ns":"default"

    O espaço de nomes em que a instância de armazenamento está implementada.

    "pvc":"block-storage-pvc"

    O nome da PVC associada à instância de armazenamento.

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

    A PV associada à instância de armazenamento.

    "storageclass":"ibmc-file-gold"

    O tipo de classe de armazenamento: bronze, prata, ouro ou customizado.

11. Remova a instância de armazenamento físico.

    ibmcloud sl block volume-cancel <classic_block_id>
    

12. Verifique se a instância de armazenamento físico foi removida.

O processo de exclusão pode levar até 72 horas para ser concluído.

ibmcloud sl block volume-list