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.
-
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
-
Crie o PVC em seu cluster.
kubectl apply -f pvc.yaml
-
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-odeployment.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
-
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:
-
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
-
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.
-
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.
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.
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:
- Se você tiver um firewall, permita acesso de saída para os intervalos de IP da infraestrutura do IBM Cloud das zonas em que seus clusters estão para que seja possível criar PVCs.
- Decida sobre uma classe de armazenamento predefinida ou crie uma classe de armazenamento customizada.
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:
-
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 denominadamypvc
da classe de armazenamento"ibmc-file-silver"
, faturada"monthly"
, com um tamanho em gigabyte de24Gi
.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 denominadamypvc
da classe de armazenamentoibmc-file-retain-custom
, faturada"hourly"
, com um tamanho em gigabyte de45Gi
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, comoeu-de
emhttps://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çãometadata.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çãometadata.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.
-
Crie o PVC.
kubectl apply -f mypvc.yaml
-
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
-
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
elabels.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.
-
Crie a implementação.
kubectl apply -f <local_yaml_path>
-
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.
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.
-
Liste PVs existentes.
kubectl get pv
Procure o PV que pertence ao seu armazenamento persistente. O PV está em um estado
released
. -
Obter os detalhes do PV.
kubectl describe pv <pv_name>
-
Observe o
CapacityGb
,storageClass
,failure-domain.beta.kubernetes.io/region
,failure-domain.beta.kubernetes.io/zone
,server
epath
. -
Remova o PV.
kubectl delete pv <pv_name>
-
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.
- No portal de infraestruturaIBM Cloud, clique em Armazenamento.
- Clique em File Storage for Classic e no menu Ações, selecione Autorizar host.
- Selecione Subnets.
- 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 oPrivate IP
do nó do trabalhador com a sub-rede localizada na lista suspensa. - Clique em Enviar.
- Clique no nome do File Storage for Classic.
- Observe o
Mount Point
, osize
e o campoLocation
. O campoMount Point
é exibido como<nfs_server>:<file_storage_path>
.
Criação de um volume persistente e de uma reivindicação de volume persistente
-
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.
-
Crie o PV em seu cluster.
kubectl apply -f mypv.yaml
-
Verifique se o PV é criado.
kubectl get pv
-
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
eaccessMode
. O campostorage-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: ""
-
Crie a PVC.
kubectl apply -f mypvc.yaml
-
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. OvolumeClaimTemplates
é 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 nosvolumeClaimTemplates
, 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
espec.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çãovolumeClaimTemplates
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.
-
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
-
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.
-
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 zonadal10
. 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 emdal10
.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ótulotopologykey: 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ótuloapp: nginx
. Para cada pod de conjunto stateful, dois PVCs são criados conforme definido na seçãovolumeClaimTemplates
, 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
ezone
: 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 entrehourly
oumonthly
. 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. Otopologykey: 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ótuloapp: 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 provedoribm.io/ibmc-file
para que seu conjunto stateful seja provisionado com o File Storage for Classic.
-
Crie seu conjunto stateful.
kubectl apply -f statefulset.yaml
-
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.
-
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, comonginxvol
. <statefulset_name>
- Use o nome que deseja especificar na seção
metadata.name
do conjunto stateful, comonginx_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
enginxvol-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.
-
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.
-
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
-
Verifique se o PVC existente está montado na réplica do conjunto stateful. Revise o
ClaimName
na seçãoVolumes
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.
-
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
-
Recupere o
StorageType
, ovolumeId
e oserver
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çãoLabels
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 ...
-
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.
-
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>"
-
Efetue login em seu pod.
kubectl exec -it <pod_name> bash
-
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
-
Crie uma classe de armazenamento customizada com a versão do NFS que você deseja provisionar.
-
Crie a classe de armazenamento em seu cluster.
kubectl apply -f nfsversion_storageclass.yaml
-
Verifique se a classe de armazenamento customizado foi criada.
kubectl get sc
-
Provisione o File Storage for Classic com sua classe de armazenamento customizada.
Alteração do PV existente para usar uma versão diferente NFS
-
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
-
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>"}}}'
-
Exclua o pod que usa o File Storage for Classic e recrie o pod.
-
Salve o YAML do pod em sua máquina local.
kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
-
Exclua o pod.
kubectl deleted pod <pod_name>
-
Recrie o pod.
kubectl apply -f pod.yaml
-
-
Aguarde o pod para implementar. O pod é totalmente implementado quando o status muda para
Running
.kubectl get pods
-
Efetue login em seu pod.
kubectl exec -it <pod_name> sh
-
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:
- Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.
- Certifique-se de que tenha a função de acesso de serviço Gerenciador do IAM para o cluster, para poder fazer mudanças nas implementações no namespace
kube-system
.
Para diminuir a capacidade do plug-in do File Storage for Classic:
-
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
-
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.
-
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.
-
Atualize o cluster mestre.
ibmcloud ks cluster refresh -c <cluster_name_or_ID>
-
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.
-
Efetue login na CLI
ibmcloud sl
.ibmcloud sl init
-
PVs de Lista existente em seu cluster.
kubectl get pv
-
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>
-
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>
-
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>
-
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>
-
Verifique se a captura instantânea foi criada com êxito.
ibmcloud sl file snapshot-list <volume_ID>
-
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>
-
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
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 : Excluiribmc-file-retain-bronze : Reteribmc-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 |
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 : Excluiribmc-file-retain-silver : Reteribmc-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 |
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 : Excluiribmc-file-retain-gold : Reteribmc-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 |
Características | Configuração |
---|---|
Nome | ibmc-file-custom ibmc-file-retain-custom |
Tipo | Desempenho |
Sistema de arquivos | NFS |
IOPS e tamanho |
|
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.
|
Política de recuperação | ibmc-file-custom : Excluiribmc-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 definereclaimPolicy: 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 definereclaimPolicy: 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:
-
Liste os PVCs em seu cluster e anote o
NAME
do PVC, oSTORAGECLASS
e o nome do PV que está ligado ao PVC e mostrado comoVOLUME
.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
-
Revise o
ReclaimPolicy
e obillingType
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 indicarRetain
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.
-
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
-
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>
-
Verifique se o pod foi removido.
kubectl get pods
-
Remova a PVC.
kubectl delete pvc <pvc_name>
-
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 estadoDeleting
se o PV for excluído automaticamente ou em um estadoReleased
se o PV deverá ser excluído manualmente. Nota: para PVs que são excluídos automaticamente, o status pode indicar brevementeReleased
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>
-
Se o seu PV não for excluído, remova-o manualmente.
kubectl delete pv <pv_name>
-
Verifique se o PV foi removido.
kubectl get pv
-
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
ouPerformance
. "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.
-
Remova a instância de armazenamento físico.
ibmcloud sl file volume-cancel <classic_file_id>
-
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.