Tipos de armazenamento de arquivos

Escolha o tipo de File Storage for Classic que você deseja provisionar.

Classes de armazenamento bronze, prata e ouro

Essas classes de armazenamento provisionam o armazenamento do Endurance. O armazenamento do Endurance permite que você escolha o tamanho do armazenamento em gigabytes em camadas do IOPS predefinidas.

Classe de armazenamento customizada

Esta classe de armazenamento provisiona o armazenamento de desempenho. Com o armazenamento de desempenho, você tem mais controle sobre o tamanho do armazenamento e do IOPS.

IOPS

Escolha o tamanho e o IOPS para o seu File Storage for Classic. O tamanho e o número de IOPS definem o número total de IOPS (operações de entrada/saída por segundo) que serve como um indicador de quão rápido o seu armazenamento é. Quanto mais total de IOPS o seu armazenamento tiver, mais rápido ele processará operações de leitura e gravação.

Classes de armazenamento bronze, prata e ouro

Essas classes de armazenamento vêm com um número fixo de IOPS por gigabyte e são provisionadas em discos rígidos SSD. O número total de IOPS depende do tamanho do armazenamento que você escolher. É possível selecionar qualquer número inteiro de gigabyte dentro do intervalo de tamanho permitido, como 20 Gi, 256 Gi ou 11854 Gi. Para determinar o número total de IOPS, deve-se multiplicar o IOPS com o tamanho selecionado. Por exemplo, se você selecionar um tamanho do File Storage for Classic de 1.000 Gi na classe de armazenamento de prata que vem com 4 IOPS por GB, seu armazenamento terá um total de 4.000 IOPS.

Classe de armazenamento customizada

Ao escolher essa classe de armazenamento, você tem mais controle sobre o tamanho e IOPS desejados. Para o tamanho, é possível selecionar qualquer número inteiro de gigabyte dentro do intervalo de tamanho permitido. O tamanho que você escolher determinará o intervalo de IOPS que estará disponível para você. É possível escolher um IOPS que é um múltiplo de 100 que esteja no intervalo especificado. O IOPS que você escolhe é estático e não escala com o tamanho do armazenamento. Por exemplo, se você escolher 40 Gi com 100 IOPS, o seu IOPS total permanecerá 100.

A razão de IOPS para gigabytes também determina o tipo de disco rígido provisionado para você. Por exemplo, se você tiver 500 Gi a 100 IOPS, a sua razão de IOPS para gigabyte será 0,2. O armazenamento com uma razão menor ou igual a 0,3 é provisionado em discos rígidos SATA. Se a sua razão for maior que 0,3, o armazenamento será provisionado em discos rígidos SSD.

Política de recuperação

Escolha se você deseja manter os seus dados após o cluster ou a solicitação de volume persistente (PVC) ser excluída.

• Para manter seus dados, escolha uma classe de armazenamento retain. Quando você exclui o PVC, somente ele é excluído. O PV, o dispositivo de armazenamento físico em sua conta de infraestrutura da IBM Cloud e seus dados ainda existem. Para recuperar o armazenamento e usá-lo novamente no cluster, deve-se remover o PV e seguir as etapas para usar o File Storage for Classic existente.
• Para que o PV, os dados e seu dispositivo físico do File Storage for Classic sejam excluídos quando você excluir o PVC, escolha uma classe de armazenamento sem retain.

Tipo de faturamento

Escolha por hora ou mensal. Revise a precificação para obter mais informações.

Por padrão, todos os dispositivos File Storage for Classic são provisionados com um tipo de faturamento por hora.

Se você escolher um tipo de faturamento mensal, quando remover o armazenamento persistente, ainda pagará o encargo mensal por ele, mesmo que o tenha usado apenas por um curto período de tempo.

Preparando seu armazenamento existente

Para que seja possível iniciar a montagem de seu armazenamento existente em um app, deve-se recuperar todas as informações necessárias para seu PV e preparar o armazenamento para ser acessível em seu cluster.

Para o armazenamento que foi provisionado com uma classe de armazenamento retain.

Se você provisionou o armazenamento com uma classe de armazenamento retain e remover o PVC, o PV e o dispositivo de armazenamento físico não serão removidos automaticamente. Para reutilizar o armazenamento em seu cluster, deve-se remover o PV restante primeiro.

Para usar o armazenamento existente em um cluster diferente daquele no qual você o provisionou, siga as etapas para armazenamento que foi criado fora do cluster para incluir o armazenamento na sub-rede de seu nó do trabalhador.

1. Liste PVs existentes.

   kubectl get pv
   

   Procure o PV que pertence ao seu armazenamento persistente. O PV está em um estado released.

2. Obter os detalhes do PV.

   kubectl describe pv <pv_name>
   

3. Observe o CapacityGb, storageClass, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, server e path.

4. Remova o PV.

   kubectl delete pv <pv_name>
   

5. Verifique se o PV foi removido.

   kubectl get pv
   

Para armazenamento persistente que foi provisionado fora do cluster

Se desejar usar o armazenamento existente que você provisionou anteriormente, mas nunca usou em seu cluster antes, deve-se tornar o armazenamento disponível na mesma sub-rede que os seus nós do trabalhador.

1. No portal de infraestruturaIBM Cloud, clique em Armazenamento.
2. Clique em File Storage for Classic e no menu Ações, selecione Autorizar host.
3. Selecione Subnets.
4. Na lista suspensa, selecione a sub-rede VLAN privada à qual o seu nó do trabalhador está conectado. Para localizar a sub-rede do nó do trabalhador, execute ibmcloud ks worker ls --cluster <cluster_name> e compare o Private IP do nó do trabalhador com a sub-rede localizada na lista suspensa.
5. Clique em Enviar.
6. Clique no nome do File Storage for Classic.
7. Observe o Mount Point, o size e o campo Location. O campo Mount Point é exibido como <nfs_server>:<file_storage_path>.

Criação de um volume persistente e de uma reivindicação de volume persistente

1. Crie um arquivo de configuração de armazenamento para seu PV. Inclua os valores que você recuperou anteriormente.

   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

   Insira o nome do objeto PV a ser criado.

   labels

   Insira a região e a zona que você recuperou anteriormente. É necessário ter pelo menos um nó do trabalhador na mesma região e zona.

   storage

   Insira o tamanho de armazenamento do compartilhamento de arquivo NFS existente que você recuperou anteriormente. O tamanho de armazenamento deve ser gravado em gigabytes, por exemplo, 20Gi (20 GB) ou 1000Gi (1 TB), e o tamanho deve corresponder ao tamanho do compartilhamento de arquivo existente.

   accessMode

   Especifique uma das seguintes opções.

   • ReadWriteMany: o PVC pode ser montado por vários pods. Todos os pods podem ler e gravar no volume.
   • ReadOnlyMany: o PVC pode ser montado por vários pods. Todos os pods têm acesso somente leitura.
   • ReadWriteOnce: o PVC pode ser montado por um único pod. Esse pod pode ler e gravar no volume.

   server

   Insira o ID do servidor de compartilhamento de arquivo NFS que você recuperou anteriormente.

   path

   Insira o caminho para o compartilhamento de arquivo NFS que você recuperou anteriormente.

2. Crie o PV em seu cluster.

   kubectl apply -f mypv.yaml
   

3. Verifique se o PV é criado.

   kubectl get pv
   

4. 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 e uma nova instância de armazenamento físico serão provisionados dinamicamente.

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

5. Crie a PVC.

   kubectl apply -f mypvc.yaml
   

6. Verifique se o PVC foi criado e ligado ao PV.

   kubectl describe pvc mypvc
   

   Saída de exemplo

   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
   

Você criou com êxito um PV e ligou-o a um PVC. Os usuários do cluster agora podem montar o PVC para suas implementações e começar a ler e gravar no objeto PV.

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

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.

1. Verifique se todos os conjuntos stateful existentes no 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. 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.

   Conjunto stateful de exemplo que especifica uma zona. O exemplo a seguir mostra como implementar o NGINX como um conjunto stateful com 3 réplicas. Para cada réplica, um dispositivo File Storage for Classic de 20 gigabytes é provisionado com base nas especificações na classe de armazenamento ibmc-file-retain-bronze. Todos os dispositivos de armazenamento são provisionados na zona dal10. Como o File Storage for Classic 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"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: k8s.gcr.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
   

   Conjunto stateful de exemplo com regra de antiafinidade e criação atrasada de File Storage for Classic. O exemplo a seguir mostra como implementar o NGINX como um conjunto stateful com 3 réplicas. O conjunto stateful não especifica a região e zona onde o File Storage for Classic é 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. A antiafinidade do nó do trabalhador é obtida definindo o rótulo app: nginx. Esse rótulo instrui o planejador do Kubernetes a não planejar um pod em um nó do trabalhador se um pod com o mesmo rótulo já estiver em execução nesse nó do trabalhador. O rótulo topologykey: failure-domain.beta.kubernetes.io/zone restringe essa regra de antiafinidade ainda mais e evita que o pod seja planejado em um nó do trabalhador que está localizado na mesma zona que um nó do trabalhador que já executa um pod com o rótulo app: nginx. Para cada pod de conjunto stateful, dois PVCs são criados conforme definido na seção volumeClaimTemplates, mas a criação das instâncias do File Storage for Classic é adiada até que um pod de conjunto stateful que use o armazenamento esteja planejado. Essa configuração é referida como planejamento de volume com reconhecimento de topologia.

   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: k8s.gcr.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

   Nos metadados, digite 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

   Na seção de especificação, digite o nome do serviço que você deseja usar para expor seu 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. Escolha entre as opções a seguir.

   • OrderedReady: Com essa opção, as réplicas do conjunto stateful são implementadas uma após a outra. Por exemplo, se você tiver especificado 3 réplicas, o Kubernetes criará o PVC para sua primeira réplica, aguardará até que o PVC seja ligado, implementará a réplica do conjunto stateful e montará o PVC para a 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. Revise os rótulos de amostra a seguir.

   • region e zone: se você desejar que todas as réplicas e PVCs do conjunto stateful sejam criados 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 faturamento 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 afinidade de especificação do 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 solicitação de recursos de especificação de recursos, digite o tamanho do File Storage for Classic 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 kubectl get sc | grep file. 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 provedor ibm.io/ibmc-file para que seu conjunto stateful seja provisionado com o File Storage for Classic.

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

Fornecimento estático: usando um PVC existente com seu conjunto stateful

É 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é-provisionar a sua PVC antes de criar o conjunto stateful, siga as etapas de 1 a 3 em Incluindo o File Storage for Classic em apps para criar uma PVC para cada réplica de 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 for necessário criar 3 réplicas do conjunto stateful, crie 3 PVCs com os nomes a seguir: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 e nginxvol-nginx_statefulset-2.

   Procurando criar um PVC e PV para uma instância File Storage for Classic existente? Crie seu PVC e PV usando o fornecimento estático.

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

3. Verifique se os PVCs são usados em seus pods de réplica do conjunto stateful, listando os pods em seu cluster e identificando os pods que pertencem ao seu conjunto stateful.

   kubectl get pods
   

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

Criação de uma classe de armazenamento personalizada com uma versão específica NFS

1. Crie uma classe de armazenamento customizada com a versão do NFS que você deseja provisionar.

2. Crie a classe de armazenamento em seu cluster.

   kubectl apply -f nfsversion_storageclass.yaml
   

3. Verifique se a classe de armazenamento customizado foi criada.

   kubectl get sc
   

4. Provisione o File Storage for Classic com sua classe de armazenamento customizada.

Alteração do PV existente para usar uma versão diferente NFS

1. Obtenha o PV do File Storage for Classic no qual você deseja mudar a versão do NFS e anote o nome do PV.

   kubectl get pv
   

2. Inclua uma anotação em seu PV. Substitua <version_number> pela versão de NFS que deseja usar. Por exemplo, para mudar para o NFS versão 3.0, insira 3.

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

3. Exclua o pod que usa o File Storage for Classic e recrie o pod.

   1. Salve o YAML do pod em sua máquina local.

      kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
      

   2. Exclua o pod.

      kubectl deleted pod <pod_name>
      

   3. Recrie o pod.

      kubectl apply -f pod.yaml
      

4. Aguarde o pod para implementar. O pod é totalmente implementado quando o status muda para Running.

   kubectl get pods
   

5. Efetue login em seu pod.

   kubectl exec -it <pod_name> sh
   

6. Verifique se o File Storage for Classic foi montado com a versão NFS que você especificou anteriormente.

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

   Saída de exemplo

   nfs vers=3.0
   

Configurar capturas instantâneas periódicas

É possível configurar capturas instantâneas periódicas para o seu File Storage for Classic, 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 no File Storage for Classic. As capturas instantâneas são armazenadas na instância de armazenamento existente dentro da mesma zona. É possível restaurar dados de uma captura instantânea se um usuário acidentalmente remove dados importantes do volume.

Conclua as etapas a seguir para criar uma captura instantânea para o seu volume.

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 os IOPS. O ID do volume, o tamanho e o IOPS podem ser localizados na seção Labels de sua saída da CLI.

   kubectl describe pv <pv_name>
   

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

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

6. Espere o tamanho da captura instantânea para criar. O tamanho da captura instantânea é fornecido com sucesso quando o Tamanho da Captura Instantânea (GB) na saída da CLI muda de 0 para o tamanho que você solicitou.

   ibmcloud sl file volume-detail <volume_ID>
   

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

   ibmcloud sl file snapshot-create <volume_ID>
   

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

   ibmcloud sl file snapshot-list <volume_ID>
   

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

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

    ibmcloud sl file 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 do File Storage for Classic 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 do File Storage for Classic replicada 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 do File Storage for Classic 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, primeiro configure capturas instantâneas para o volume.

Fazendo backup dos dados para o IBM Cloud® Object Storage

É possível usar o gráfico ibm-backup-restore Helm para girar um pod de backup e restauração em seu 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.

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 IBM Cloud® Object Storage e replique dados entre as zonas. Se for necessário restaurar dados da instância do IBM Cloud® Object Storage, use o script 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.

Antes de iniciar: efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster. 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></var> <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

Criando armazenamento de reconhecimento de topologia

Para usar o File Storage for Classic em um cluster multizona, seu pod deve ser planejado na mesma zona que sua instância do File Storage for Classic para que seja possível ler e gravar no volume. Antes do planejamento do volume direcionado a topologia ser apresentado pelo Kubernetes, o fornecimento dinâmico de seu armazenamento criou automaticamente a instância do File Storage for Classic quando uma PVC foi criada. Em seguida, quando você criou seu pod, o planejador do Kubernetes tentou implementar o pod em um nó do trabalhador no mesmo data center que sua instância do File Storage for Classic.

A criação da instância do File Storage for Classic 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 direcionado a topologia, a instância do File Storage for Classic é atrasada até que o primeiro pod que use o armazenamento seja criado.

Os exemplos a seguir mostram como criar classes de armazenamento que atrasam a criação da instância do File Storage for Classic 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 para Immediate e a instância do File Storage for Classic será criada quando você criar a PVC.

Exemplo para o File Storage for Classic de resistência.

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

Exemplo para o File Storage for Classic de desempenho.

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

Especificando a zona para clusters de diversas zonas

Se você desejar criar o seu File Storage for Classic 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ê quiser provisionar estaticamente o File Storage for Classic em uma zona específica. Em todos os outros casos, especifique a zona diretamente em seu PVC.

Ao criar a classe de armazenamento customizada, especifique a mesma região e zona em que seus nós do cluster e do trabalhador estão. 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 File Storage for Classic de resistência.

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

Exemplo para o File Storage for Classic de desempenho.

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

Mudando a versão do NFS padrão

A classe de armazenamento customizada a seguir permite que você defina a versão do NFS que você deseja fornecer. Por exemplo, para fornecer a NFS versão 3.0, substitua <nfs_version> por 3.0.

Exemplo para o File Storage for Classic de resistência.

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>

Exemplo para o File Storage for Classic de desempenho.

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>

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 reclaimPolicy: Delete, seu PVC, PV e a instância de armazenamento serão automaticamente excluídos quando você excluir o cluster. No caso do armazenamento provisionado estaticamente ou do armazenamento provisionado com uma classe de armazenamento que define reclaimPolicy: Retain, o PVC e o PV são removidos quando você exclui o cluster, mas a instância de armazenamento e os 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 quando quero 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. Para o armazenamento que foi provisionado estaticamente ou para o armazenamento que você provisionou com uma classe de armazenamento que define reclaimPolicy: Retain, você deve 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 excluo meu 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 no console IBM Cloud ou na 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.

Do que preciso estar ciente 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.

Excluí 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 seu PV apontou e anote o id da instância de armazenamento físico.

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

    Saída de exemplo para o 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"

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

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

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

    ibmcloud sl file volume-list
    

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