IBM Cloud Docs
Configurando o File Storage for Classic

Configurando o File Storage for Classic

O IBM Cloud File Storage for Classic é um File Storage for Classic baseado em NFS, persistente, rápido e anexado à rede flexível, que pode ser incluído em seus apps usando volumes persistentes (PVs) do Kubernetes. É possível escolher entre camadas de armazenamento predefinidas com tamanhos de GB e IOPS que atendam aos requisitos de suas cargas de trabalho. Para descobrir se IBM Cloud File Storage for Classic é a opção de armazenamento correta para você, consulte Escolhendo uma solução de armazenamento. Para obter informações de precificação, consulte Precificação.

Infraestrutura clássica

Início rápido para File Storage for Classic

Neste guia de início rápido, você cria um volume de resistência 24Gi File Storage for Classic em seu cluster, criando um PVC para provisionar dinamicamente o volume. Em seguida, você cria uma implementação de app que monta o seu PVC.

Primeira vez usando o File Storage for Classic em seu cluster? Volte aqui uma vez que você esteja familiarizado com as configurações do File Storage for Classic.

  1. Crie um arquivo para o seu PVC e nomeia-o pvc.yaml.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
        name: silver-pvc
        labels:
           billingType: hourly
           region: # Example: us-south
           zone: # Example: dal13
    spec:
     accessModes:
     - ReadWriteMany
     resources:
       requests:
         storage: 24Gi
     storageClassName: ibmc-file-silver
    
  2. Crie o PVC em seu cluster.

    kubectl apply -f pvc.yaml
    
  3. Depois que sua PVC silver-pvc estiver ligado, crie uma implementação de app que use a sua PVC. Crie um arquivo para sua implementação e nomeia-o deployment.yaml.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-deployment
      labels:
        app:
    spec:
      selector:
        matchLabels:
          app: my-app
      template:
        metadata:
          labels:
            app: my-app
        spec:
          containers:
          - image: # Your contanerized app image.
            name: my-container
            volumeMounts:
            - name: my-volume
              mountPath: /mount-path
          volumes:
          - name: my-volume
            persistentVolumeClaim:
              claimName: silver-pvc
    
  4. Crie a implementação em seu cluster.

    kubectl apply -f deployment.yaml
    

Para obter mais informações, veja os links a seguir.

Decidindo sobre a configuração do File Storage for Classic

O IBM Cloud® Kubernetes Service fornece classes de armazenamento pré-definidas para o File Storage for Classic que podem ser usadas para provisionar o File Storage for Classic com uma configuração específica.

Toda classe de armazenamento especifica o tipo de File Storage for Classic que você provisiona, incluindo tamanho disponível, IOPS, sistema de arquivos e a política de retenção.

Depois de provisionar um tipo específico de armazenamento usando uma classe de armazenamento, você não poderá mudar o tipo ou a política retenção para o dispositivo de armazenamento. No entanto, é possível mudar o tamanho e o IOPS se você desejar aumentar a capacidade de armazenamento e o desempenho. Para alterar o tipo e a política de retenção do seu armazenamento, você deve criar uma nova instância de armazenamento e copiar os dados da instância de armazenamento antiga para a nova.

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

Para decidir sobre uma configuração de armazenamento:

  1. Liste as classes de armazenamento disponíveis no IBM Cloud® Kubernetes Service.

    kubectl get sc | grep file
    

    Saída de exemplo

    NAME                         TYPE
    ibmc-file-bronze (default)   ibm.io/ibmc-file
    ibmc-file-custom             ibm.io/ibmc-file
    ibmc-file-gold               ibm.io/ibmc-file
    ibmc-file-retain-bronze      ibm.io/ibmc-file
    ibmc-file-retain-custom      ibm.io/ibmc-file
    ibmc-file-retain-gold        ibm.io/ibmc-file
    ibmc-file-retain-silver      ibm.io/ibmc-file
    ibmc-file-silver             ibm.io/ibmc-file
    
  2. Revise a configuração de uma classe de armazenamento.

    kubectl describe storageclass <storageclass_name>
    

    Para obter mais informações sobre cada classe de armazenamento, consulte a referência de classe de armazenamento. Se não localizar o que está procurando, considere criar sua própria classe de armazenamento customizada. Para iniciar, consulte as amostras de classe de armazenamento customizadas.

  3. Escolha o tipo de armazenamento de arquivo, o IOPS, a política de recuperação e o faturamento que você deseja usar.

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.
Tabela de intervalos de tamanho de classe de armazenamento e IOPS por gigabyte
Classe de armazenamento IOPS por gigabyte Intervalo de tamanho em gigabytes
Bronze 2 IOPS/GB 20-12.000 Gi
Prata 4 IOPS/GB 20-12.000 Gi
Ouro 10 IOPS/GB 20-4000 Gi
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.
Tabela de intervalos de tamanho de classe e IOPS
Intervalo de tamanho em gigabytes Intervalo de IOPS em diversos 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

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.

Incluindo o File Storage for Classic em apps

Crie uma reivindicação de volume persistente (PVC) para provisionar dinamicamente File Storage for Classic para seu cluster. O provisionamento dinâmico cria automaticamente o volume persistente correspondente (PV) e pede o dispositivo de armazenamento físico em sua conta de infraestrutura da IBM Cloud.

Antes de Iniciar:

Procurando implementar o File Storage for Classic em um conjunto stateful? Consulte Usando o File Storage for Classic em um conjunto stateful para obter mais informações.

Para incluir o File Storage for Classic:

  1. Crie um arquivo de configuração para definir a sua solicitação de volume persistente (PVC) e salve a configuração como um arquivo .yaml.

    Exemplo para classes de armazenamento bronze, prata e ouro.

    O arquivo .yaml a seguir cria uma solicitação denominada mypvc da classe de armazenamento "ibmc-file-silver", faturada "monthly", com um tamanho em gigabyte de 24Gi.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mypvc
      labels:
        billingType: "monthly"
        region: us-south
        zone: dal13
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 24Gi
      storageClassName: ibmc-file-silver
    

    Exemplo de uso de sua própria classe de armazenamento

    O arquivo .yaml a seguir cria uma solicitação denominada mypvc da classe de armazenamento ibmc-file-retain-custom, faturada "hourly", com um tamanho em gigabyte de 45Gi e um IOPS de "300".

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mypvc
      labels:
        billingType: "hourly"
        region: us-south
        zone: dal13
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 45Gi
          iops: "300"
      storageClassName: ibmc-file-retain-custom
    
    name
    Insira o nome do PVC.
    billingType
    Especifique a frequência para a qual sua conta de armazenamento é calculada, como "mensal" ou "por hora". Se você não especificar um tipo de faturamento, o armazenamento será provisionado com um tipo de faturamento por hora.
    region
    Opcional: especifique a região na qual você deseja provisionar o seu File Storage for Classic. Para se conectar ao seu armazenamento, crie o armazenamento na mesma região na qual seu cluster está. Se você especifica a região, deve-se também especificar uma zona. Se você não especificar uma região, ou se a região especificada não for localizada, o armazenamento será criado na mesma região do cluster. Para obter a região para o 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. Em vez de especificar a região e a zona no PVC, também é possível especificar esses valores em uma classe de armazenamento customizada. Em seguida, use a classe de armazenamento na seção metadata.annotations.volume.beta.kubernetes.io/storage-class de seu PVC. Se a região e a zona forem especificadas na classe de armazenamento e no PVC, os valores no PVC terão precedência.
    zone
    Opcional: especifique a zona na qual você deseja provisionar o seu File Storage for Classic. Para usar seu armazenamento em um app, crie o armazenamento na mesma zona na qual seu nó do trabalhador está. Para visualizar a zona do nó do trabalhador, execute ibmcloud ks worker ls --cluster <cluster_name_or_ID> e revise a coluna Zona da saída da CLI. Se você especifica a zona, deve-se também especificar uma região. Se você não especificar uma zona ou se a zona especificada não for localizada em um cluster multizona, a zona será selecionada em uma base round-robin. Em vez de especificar a região e a zona no PVC, também é possível especificar esses valores em uma classe de armazenamento customizada. Em seguida, use a classe de armazenamento na seção metadata.annotations.volume.beta.kubernetes.io/storage-class de seu PVC. Se a região e a zona forem especificadas na classe de armazenamento e no PVC, os valores no PVC terão precedência.
    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.
    storage
    Insira o tamanho do File Storage for Classic, em gigabytes (Gi). Depois que o armazenamento é provisionado, não é possível mudar o tamanho do File Storage for Classic. Certifique-se de especificar um tamanho que corresponda à quantia de dados que você deseja armazenar.
    iops
    Essa opção está disponível somente para suas próprias classes de armazenamento personalizado ibmc-file-custom / ibmc-file-retain-custom). Especifique o total de IOPS para o armazenamento, selecionando um múltiplo de 100 dentro do intervalo permitido. Se você escolher um IOPS diferente de um que esteja listado, o IOPS será arredondado para cima.
    storageClassName
    O nome da classe de armazenamento que você deseja usar para prover File Storage for Classic. É possível optar por usar uma das classes de armazenamento fornecidas pela IBM ou criar sua própria classe de armazenamento. Se você não especificar uma classe de armazenamento, o PV será criado com a classe de armazenamento padrão ibmc-file-bronze.

    Para usar uma classe de armazenamento customizado, crie seu PVC com o nome de classe de armazenamento correspondente, um IOPS válido e o tamanho.

  2. Crie o PVC.

    kubectl apply -f mypvc.yaml
    
  3. 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
    
    
  4. Para montar o armazenamento em sua implementação, crie um arquivo de configuração .yaml e especifique o PVC que liga o PV.

    Se você tiver um app que requer um usuário não raiz para gravar no armazenamento persistente, ou um app que requer que o caminho de montagem seja de propriedade do usuário raiz, consulte Incluindo acesso de usuário não raiz na NFS File Storage for Classic.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <deployment_name>
      labels:
        app: <deployment_label>
    spec:
      selector:
        matchLabels:
          app: <app_name>
      template:
        metadata:
          labels:
            app: <app_name>
        spec:
          containers:
          - image: <image_name>
            name: <container_name>
            volumeMounts:
            - name: <volume_name>
              mountPath: /<file_path>
          volumes:
          - name: <volume_name>
            persistentVolumeClaim:
              claimName: <pvc_name>
    
    app
    Na seção de metadados, insira um rótulo para a implementação.
    matchLabels.app e labels.app
    Nas seções de metadados do seletor e do modelo de especificação, insira o rótulo para o seu aplicativo.
    image
    O nome da imagem de contêiner que você deseja usar. Para listar as imagens disponíveis em sua conta do IBM Cloud Container Registry, execute ibmcloud cr image-list.
    name
    O nome do contêiner que você deseja implementar em seu cluster.
    mountPath
    Na seção de montagens de volume do contêiner, insira o caminho absoluto do diretório para onde o volume é montado dentro do contêiner. Os dados que são gravados no caminho de montagem são armazenados sob o diretório root em sua instância física File Storage for Classic. Para compartilhar um volume entre diferentes apps, é possível especificar subcaminhos de volume para cada um dos apps.
    name
    Na seção de montagens de volume de contêineres, insira o nome do volume para montar em seu pod.
    name
    Na seção volumes, insira o nome do volume para montar em seu pod. Geralmente esse nome é o mesmo que volumeMounts.name.
    claimName
    Na seção de solicitação de volume persistente de volumes, insira o nome da PVC que liga o PV que você deseja usar.
  5. Crie a implementação.

    kubectl apply -f <local_yaml_path>
    
  6. Verifique se o PV foi montado com êxito.

    kubectl describe deployment <deployment_name>
    

    O ponto de montagem está no campo Montagens de volume e o volume está no campo Volumes.

    Volume Mounts:
        /var/run/secrets/kubernetes.io/serviceaccount from default-token-tqp61 (ro)
        /volumemount from myvol (rw)
    ...
    Volumes:
    myvol:
        Type:    PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:    mypvc
        ReadOnly:    false
    

Usando o File Storage for Classic existente em seu cluster

Se você tiver um dispositivo de armazenamento físico existente que deseja usar em seu cluster, poderá criar manualmente o PV e o PVC para provisionar estaticamente o armazenamento.

Antes de Iniciar:

Certifique-se de que você tenha pelo menos um nó do trabalhador que exista na mesma zona que a sua instância existente do File Storage for Classic.

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

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.

Usando o File Storage for Classic em um conjunto stateful

Se você tiver um app stateful, como um banco de dados, será possível criar conjuntos stateful que usam o File Storage for Classic para armazenar os dados de seu app. Como alternativa, é possível usar um banco de dados como um serviço do IBM Cloud e armazenar seus dados na nuvem.

Do que preciso estar ciente ao adicionar File Storage for Classic a um conjunto com estado?
Para incluir armazenamento em um conjunto stateful, especifique sua configuração de armazenamento na seção volumeClaimTemplates do YAML do conjunto stateful. O volumeClaimTemplates é a base para a sua PVC e pode incluir a classe de armazenamento e o tamanho ou IOPS de seu File Storage for Classic que você deseja provisionar. No entanto, se você desejar incluir rótulos nos volumeClaimTemplates, os Kubernetes não incluirão esses rótulos ao criar o PVC. Em vez disso, deve-se incluir os rótulos diretamente no conjunto stateful.

Não é possível implementar dois conjuntos stateful ao mesmo tempo. Se você tentar criar um conjunto stateful antes que um diferente seja totalmente implementado, a implementação do conjunto stateful poderá levar a resultados inesperados.

Como posso criar meu conjunto com estado em uma zona específica?
Em um cluster com várias zonas, é possível especificar a zona e a região na qual você deseja criar seu conjunto stateful nas seções spec.selector.matchLabels e spec.template.metadata.labels do YAML do conjunto stateful. Como alternativa, é possível incluir esses rótulos em uma classe de armazenamento customizada e usar essa classe de armazenamento na seção volumeClaimTemplates de seu conjunto stateful.
Posso atrasar a vinculação de um PV ao meu pod com estado até que o pod esteja pronto?
Sim, é possível criar sua própria classe de armazenamento para o seu PVC que inclui o campo volumeBindingMode: WaitForFirstConsumer
Quais opções eu tenho para adicionar File Storage for Classic a um conjunto com estado?
Para criar automaticamente seu PVC ao criar o conjunto stateful, use o fornecimento dinâmico. Também é possível optar por pré-provisionar os PVCs ou usar PVCs existentes com o conjunto stateful.

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

Mudando o tamanho e o IOPS de seu dispositivo de armazenamento existente

Se você desejar aumentar a capacidade de armazenamento ou o desempenho, será possível modificar seu volume existente.

Para perguntas sobre faturamento e para localizar as etapas de como usar o console do IBM Cloud para modificar seu armazenamento, veja Expandir capacidade de compartilhamento de arquivo.

  1. Liste os PVCs em seu cluster e anote o nome do PV associado na coluna VOLUME.

    kubectl get pvc
    

    Saída de exemplo

    NAME             STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
    myvol            Bound     pvc-01ac123a-123b-12c3-abcd-0a1234cb12d3   20Gi       RWX            ibmc-file-bronze    147d
    
  2. Recupere o StorageType, o volumeId e o server do File Storage for Classic físico que está associado à sua PVC listando os detalhes do PV que a sua PVC está vinculada. Substitua <pv_name> pelo nome do PV recuperado na etapa anterior. O tipo de armazenamento, o ID do volume e o nome do servidor são mostrados na seção Labels de sua saída da CLI.

    kubectl describe pv <pv_name>
    

    Saída de exemplo

    Name:            pvc-4b62c704-5f77-11e8-8a75-b229c11ba64a
    Labels:          CapacityGb=20
                    Datacenter=dal10
                    Iops=2
                    StorageType=ENDURANCE
                    Username=IBM02SEV1543159_6
                    billingType=hourly
                    failure-domain.beta.kubernetes.io/region=us-south
                    failure-domain.beta.kubernetes.io/zone=dal10
                    path=IBM01SEV1234567_8ab12t
                    server=fsf-dal1001g-fz.adn.networklayer.com
                    volumeId=12345678
    ...
    
  3. Modifique o tamanho ou o IOPS de seu volume em sua conta de infraestrutura da IBM Cloud.

    Exemplo de armazenamento de desempenho.

    ibmcloud sl file volume-modify <volume_ID> --new-size <size> --new-iops <iops>
    

    Exemplo de armazenamento de resistência.

    ibmcloud sl file volume-modify <volume_ID> --new-size <size> --new-tier <iops>
    
    volume_ID
    Insira o ID do volume recuperado anteriormente.
    new-size
    Insira o novo tamanho em gigabytes (Gi) para seu volume. Para obter tamanhos válidos, consulte Decidindo sobre a configuração do File Storage for Classic. O tamanho inserido deve ser maior ou igual ao tamanho atual de seu volume. Se você não especificar um novo tamanho, o tamanho atual do volume será usado.
    new-iops
    Somente para armazenamento de desempenho. Insira o novo número de IOPS que você deseja. Para o IOPS válido, consulte Decidindo sobre a configuração do File Storage for Classic. Se você não especificar o IOPS, o IOPS atual será usado. Se a razão IOPS/GB original para o volume for menor que 0,3, a nova razão IOPS/GB deverá ser menor que 0,3. Se a razão IOPS/GB original para o volume for maior ou igual a 0,3, a nova razão IOPS/GB para o volume deverá ser maior ou igual a 0,3.
    new-tier
    Somente para armazenamento do Endurance. Insira o novo número de IOPS por GB que você deseja. Para o IOPS válido, consulte Decidindo sobre a configuração do File Storage for Classic. Se você não especificar o IOPS, o IOPS atual será usado. Se a razão IOPS/GB original para o volume for menor que 0,25, a nova razão IOPS/GB deverá ser menor que 0,25. Se a razão IOPS/GB original para o volume for maior ou igual a 0,25, a nova razão IOPS/GB para o volume deverá ser maior ou igual a 0,25.

    Saída de exemplo

    Order 31020713 was placed successfully!.
    > Storage as a Service
    
    > 40 GBs
    
    > 2 IOPS per GB
    
    > 20 GB Storage Space (Snapshot Space)
    
    You might run 'ibmcloud sl file volume-list --order 12345667' to find this file volume after it is ready.
    
  4. Se você mudou o tamanho de seu volume e usa o volume em um pod, efetue login em seu pod para verificar o novo tamanho. Liste todos os pods que usam PVC. Os pods são retornados no formato: <pod_name>: <pvc_name>.

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

    kubectl exec -it <pod_name> bash
    
  6. Mostre as estatísticas de uso do disco e localize o caminho do servidor para seu volume que você recuperou anteriormente.

    df -h
    

    Saída de exemplo

    Filesystem                                                      Size  Used Avail Use% Mounted on
    overlay                                                          99G  4.8G   89G   6% /
    tmpfs                                                            64M     0   64M   0% /dev
    tmpfs                                                           7.9G     0  7.9G   0% /sys/fs/cgroup
    fsf-dal1001g-fz.adn.networklayer.com:/IBM01SEV1234567_6/data01   40G     0   40G   0% /myvol
    

Embora o tamanho e o IOPS de seu armazenamento físico tenham sido mudados, esses valores não serão refletidos em seu PV ou PVC. Se você descrever seu PV ou PVC, o tamanho antigo e o IOPS continuarão a ser exibidos. Você tem a opção de atualizar manualmente o tamanho e o IOPS em seu PV usando o comando kubectl patch pv. No entanto, esse comando não pode ser usado para mudar o tamanho ou IOPS na PVC. Para evitar que tenham tamanhos diferentes e IOPS em sua PVC e PV, deixe o sua PVC e PV no estado em que se encontram.

Mudando a versão do NFS padrão

A versão do File Storage for Classic determina o protocolo que é usado para se comunicar com o servidor IBM Cloud File Storage for Classic. Por padrão, todas as instâncias do File Storage for Classic são configuradas com a NFS versão 4. Será possível mudar o PV existente para uma versão de NFS mais antiga se o app exigir uma versão específica para funcionar adequadamente.

Para alterar a versão NFS padrão, você pode criar uma nova classe de armazenamento para prover dinamicamente File Storage for Classic em seu cluster, ou optar por alterar um PV existente que esteja montado em seu pod.

Para aplicar as atualizações de segurança mais recentes e obter um desempenho melhor, use a versão de NFS padrão e não mude para uma versão de NFS mais antiga.

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
    

Diminuindo a capacidade do plug-in padrão do File Storage for Classic

Por padrão, seus clusters clássicos incluem o plug-in File Storage for Classic. Se não precisar usar o File Storage for Classic no cluster, você poderá conservar os recursos de cluster reduzindo a escala dos componentes de plug-in e observador. Posteriormente, será possível escalar de volta até uma réplica se você precisar do File Storage for Classic. Não é possível mudar outras configurações ou remover completamente a implementação. Como o plug-in ainda está instalado, ele é atualizado junto com as atualizações da versão do cluster mesmo se você diminuiu a capacidade do plug-in.

Antes de Iniciar:

Para diminuir a capacidade do plug-in do File Storage for Classic:

  1. Diminua a capacidade do plug-in do File Storage for Classic e implementações do observador para 0 réplicas.

    kubectl scale deployment -n kube-system --replicas=0 ibm-file-plugin
    
    kubectl scale deployment -n kube-system --replicas=0 ibm-storage-watcher
    

    Se você precisar do File Storage for Classic posteriormente, será possível aumentar a escala do plug-in novamente com os comandos a seguir. kubectl scale deployment -n kube-system --replicas=1 ibm-file-plugin && kubectl scale deployment -n kube-system --replicas=1 ibm-storage-watcher

  2. Opcional: Confirme que o plug-in é escalado para baixo. A redução de escala é bem-sucedida quando os pods são removidos e permanecem removidos, mesmo após o estado principal ser alterado, como, por exemplo, por uma atualização de cluster.

    1. Confirme se os pods foram removidos.

      kubectl get pods -n kube-system -l 'app in (ibm-file-plugin, ibm-storage-watcher)'
      

      Saída de exemplo

      No resources found.
      
    2. Atualize o cluster mestre.

      ibmcloud ks cluster refresh -c <cluster_name_or_ID>
      
    3. Aguarde alguns minutos para que a atualização seja concluída e, em seguida, repita a subetapa 2.a para verificar se os pods foram removidos. Se os pods estiverem reagendados, as mudanças feitas no arquivo de configuração do plug-in do File Storage for Classic não terão sido salvas adequadamente. Certifique-se de que seu cluster execute a versão correta do Kubernetes e tente novamente.

Fazendo backup e restaurando dados

O File Storage for Classic é provisionado para o mesmo local que os nós do trabalhador em seu cluster. O armazenamento é hospedado em servidores em cluster pela IBM para fornecer disponibilidade no caso de um servidor ficar inativo. No entanto, o File Storage for Classic não será submetido a backup automaticamente e poderá ser inacessível se o local inteiro falhar. Para proteger seus dados contra perda ou danos, será possível configurar backups periódicos que poderão ser usados para restaurar seus dados quando necessário.

Revise as opções de backup e restauração a seguir para o seu File Storage for Classic.

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

Referência de classe de armazenamento

Bronze
Características Configuração
Nome ibmc-file-bronze
ibmc-file-retain-bronze
ibmc-file-bronze-gid
Tipo Armazenamento de resistência
Sistema de arquivos NFS
IOPS por gigabyte 2
Intervalo de tamanho em gigabytes 20-12.000 Gi
Disco rígido SSD
Política de recuperação ibmc-file-bronze: Excluir
ibmc-file-retain-bronze: Reter
ibmc-file-bronze-gid: Excluir
ID do grupo suplementar O ID do grupo suplementar 65531 é configurado automaticamente quando você usa a classe de armazenamento ibmc-file-bronze-gid para permitir que usuários não raiz acessem a instância do File Storage. Para obter mais informações sobre como usar essa classe de armazenamento ou configurar IDs de grupo customizados, consulte Armazenamento de arquivo: a inclusão do acesso de usuário não raiz no armazenamento persistente falha.
faturamento Por hora
Precificação Informações de precificação
Prata
Características Configuração
Nome ibmc-file-silver
ibmc-file-retain-silver
ibmc-file-silver-gid
Tipo Armazenamento de resistência
Sistema de arquivos NFS
IOPS por gigabyte 4
Intervalo de tamanho em gigabytes 20-12.000 Gi
Disco rígido SSD
Política de recuperação ibmc-file-silver: Excluir
ibmc-file-retain-silver: Reter
ibmc-file-silver-gid: Excluir
ID do grupo suplementar O ID do grupo suplementar 65531 é configurado automaticamente quando você usa a classe de armazenamento ibmc-file-bronze-gid para permitir que usuários não raiz acessem a instância do File Storage. Para obter mais informações sobre como usar essa classe de armazenamento ou configurar IDs de grupo customizados, consulte Armazenamento de arquivo: a inclusão do acesso de usuário não raiz no armazenamento persistente falha.
faturamento Por hora
Precificação Informações de precificação
Ouro
Características Configuração
Nome ibmc-file-gold
ibmc-file-retain-gold
ibmc-file-gold-gid
Tipo Armazenamento de resistência
Sistema de arquivos NFS
IOPS por gigabyte 22
Intervalo de tamanho em gigabytes 20-4000 Gi
Disco rígido SSD
Política de recuperação ibmc-file-gold: Excluir
ibmc-file-retain-gold: Reter
ibmc-file-gold-gid: Excluir
ID do grupo suplementar O ID do grupo suplementar 65531 é configurado automaticamente quando você usa a classe de armazenamento ibmc-file-bronze-gid para permitir que usuários não raiz acessem a instância do File Storage. Para obter mais informações sobre como usar essa classe de armazenamento ou configurar IDs de grupo customizados, consulte Armazenamento de arquivo: a inclusão do acesso de usuário não raiz no armazenamento persistente falha.
faturamento Por hora
Precificação Informações de precificação
Personalizado
Características Configuração
Nome ibmc-file-custom
ibmc-file-retain-custom
Tipo Desempenho
Sistema de arquivos NFS
IOPS e tamanho
  • 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 de tipos de disco rígido por razão: - Menor ou igual a 0,3: SATA

  • Maior que 0,3: SSD
Política de recuperação ibmc-file-custom: Excluir
ibmc-file-retain-custom: Reter
faturamento Por hora
Precificação Informações de precificação

Classes de armazenamento customizado de amostra

É possível criar uma classe de armazenamento customizada e usar a classe de armazenamento no PVC.

IBM Cloud Kubernetes Service fornece classes de armazenamento pré-definidas para prover File Storage for Classic com uma determinada camada e configuração. Às vezes você pode querer provisionar armazenamento com uma configuração diferente que não seja coberta nas classes de armazenamento predefinidas. É possível usar os exemplos neste tópico para localizar classes de armazenamento customizadas de amostra.

Para criar sua classe de armazenamento customizada, consulte Customizando uma classe de armazenamento. Em seguida, use a sua classe de armazenamento customizada em seu PVC.

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>

Removendo o armazenamento persistente de um cluster

Ao configurar o armazenamento persistente em seu cluster, você tem três componentes principais: a solicitação de volume persistente do Kubernetes (PVC) que solicita armazenamento, o volume persistente do Kubernetes (PV) que é montado em um pod e descrito no PVC e a instância de infraestrutura da IBM Cloud, como um arquivo clássico ou armazenamento de bloco. Dependendo de como você criou seu armazenamento, pode ser necessário excluir todos os três componentes separadamente.

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:

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.