Esta página foi traduzida pela API Cloud Translation.

Otimize a performance e o custo do armazenamento com os pools de armazenamento do Hyperdisk

Autopilot Standard

Nesta página, descrevemos como os clusters do Google Kubernetes Engine (GKE) podem agrupar e compartilhar a capacidade de armazenamento, o throughput e o IOPS entre discos usando os pools de armazenamento do Hyperdisk do GKE.

Visão geral

Os pools de armazenamento agrupam logicamente os dispositivos de armazenamento físico, permitindo segmentar os recursos. É possível provisionar Hyperdisks do Google Cloud nesses pools de armazenamento, criando essencialmente pools de armazenamento de hiperdisco. Os pools de armazenamento de hiperdisco oferecem capacidade, capacidade de processamento e IOPS pré-provisionados que os discos do cluster do GKE podem compartilhar.

É possível usar os pools de armazenamento de hiperdisco para gerenciar seus recursos de armazenamento de maneira mais eficiente e econômica. Isso permite aproveitar tecnologias de eficiência, como a desduplicação e o provisionamento fino.

Neste guia, você vai usar a zona us-east4-c para criar o pool de armazenamento balanceado por hiperdisco e outros recursos.

Considerações sobre planejamento

Considere os requisitos e as limitações a seguir antes de provisionar e consumir seu pool de armazenamento de hiperdisco.

Como criar e gerenciar pools de armazenamento

Os seguintes requisitos e limitações se aplicam:

Todas as limitações dos pools de armazenamento de hiperdisco do Compute Engine são aplicáveis.
Todas as limitações de criação de discos em um pool de armazenamento de hiperdisco se aplicam.
O tipo de pool de armazenamento de hiperdisco criado determina o tipo de discos que é possível criar no pool de armazenamento. Consulte Tipos de pools de armazenamento de hiperdisco.

Como provisionar discos de inicialização em pools de armazenamento

Os seguintes requisitos e limitações se aplicam:

Verifique se os locais de nó do cluster e os locais de nó do pool de nós correspondem exatamente às zonas do pool de armazenamento. Essa restrição não se aplica se o provisionamento automático de nós estiver ativado. O provisionamento automático de nós pode criar automaticamente pools de nós nas zonas corretas, se necessário.
Verifique se o tipo de máquina que executa seu pod oferece suporte à conexão do tipo de disco Hyperdisk Balanced. O Hyperdisk Throughput não tem suporte como disco de inicialização. Consulte a documentação de suporte ao tipo de máquina do Hyperdisk.
É possível provisionar discos de inicialização em pools de armazenamento apenas em pools de nós criados ou atualizados manualmente.
Quando os nós são criados automaticamente usando o provisionamento automático de nós, os discos de inicialização desses nós não podem ser colocados em um pool de armazenamento.

Provisionar o disco anexado em pools de armazenamento

Os seguintes requisitos e limitações se aplicam:

A versão mínima necessária do GKE para provisionar discos conectados em pools de armazenamento é 1.29.2-gke.1035000 e mais recente.
Verifique se o driver CSI do disco permanente do Compute Engine está ativado. O driver de disco permanente do Compute Engine é ativado por padrão em novos clusters do Autopilot e Standard e não pode ser desativado ou editado em clusters do Autopilot. Para ativar o driver, consulte Como ativar o driver CSI do disco permanente do Compute Engine em um cluster atual.
Verifique se o pool de armazenamento está em pelo menos um dos locais de nó do cluster e do pool de nós.
Só é possível provisionar discos conectados de capacidade de processamento de hiperdisco e hiperdisco balanceado em pools de armazenamento. O tipo do disco anexado precisa corresponder ao tipo do pool de armazenamento. Para mais informações, consulte Tipos de pools de armazenamento de hiperdisco.
Verifique se o tipo de máquina que executa o pod oferece suporte à conexão do tipo de disco que você está usando no pool de armazenamento. Para mais informações, consulte Suporte ao tipo de máquina do Hyperdisk.

Cota

Ao criar um pool de armazenamento de hiperdisco, é possível configurá-lo com o provisionamento padrão ou avançado para capacidade e desempenho. Se você quiser aumentar a cota de capacidade, capacidade de processamento ou IOPS, solicite uma cota maior para o filtro de cota relevante.

Para mais informações, consulte Conferir as cotas do seu projeto e Solicitar uma cota maior.

Use os seguintes filtros de cota para pools de armazenamento balanceado do Hyperdisk:

HDB-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: para aumentar a capacidade com o provisionamento de capacidade avançada.
HDB-STORAGE-POOL-TOTAL-ADVANCED-IOPS-per-project-region: para aumentar as IOPS com o provisionamento de desempenho avançado.
HDB-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: para aumentar a capacidade de processamento com o provisionamento de desempenho avançado.
HDB-TOTAL-GB-per-project-region: para aumentar a capacidade com o provisionamento de capacidade padrão.
HDB-TOTAL-IOPS-per-project-region: para aumentar as IOPS com o provisionamento de desempenho padrão.
HDB-TOTAL-THROUGHPUT-per-project-region: para aumentar a capacidade de processamento com o provisionamento de desempenho padrão.

Use os seguintes filtros de cota para os pools de armazenamento de capacidade de processamento do hiperdisco:

HDT-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: para aumentar a capacidade com o provisionamento de capacidade avançada.
HDT-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: para aumentar a capacidade de processamento com o provisionamento de desempenho avançado.
HDT-TOTAL-GB-per-project-region: para aumentar a capacidade com o provisionamento de capacidade padrão.
HDT-TOTAL-THROUGHPUT-per-project-region: para aumentar a capacidade de processamento com o provisionamento de desempenho padrão.

Por exemplo, se você quiser aumentar a capacidade total dos pools de armazenamento equilibrado do Hyperdisk com provisionamento de capacidade avançado, por projeto e região, solicite uma cota maior para o seguinte filtro:

hdb-storage-pool-total-advanced-capacity-per-project-region

Preços

Consulte Preços dos pools de armazenamento do Hyperdisk para mais detalhes.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da gcloud CLI, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Confira as regiões e zonas com suporte para criar o pool de armazenamento balanceado do Hyperdisk.

Criar um pool de armazenamento de hiperdisco

Crie um pool de armazenamento de hiperdisco antes de provisionar discos de inicialização ou discos anexados nesse pool de armazenamento. Para mais informações, consulte Criar pools de armazenamento do Hyperdisk.

Crie pools de armazenamento em uma das zonas com suporte.

Por exemplo, use o comando a seguir para criar um pool de armazenamento equilibrado de hiperdisco com capacidade e desempenho avançados e provisionar 10 TB de capacidade, 10.000 IOPS/s e 1.024 MBps de capacidade de processamento na zona us-east4-c:

export PROJECT_ID=PROJECT_ID
export ZONE=us-east4-c
gcloud compute storage-pools create pool-$ZONE \
    --provisioned-capacity=10tb --storage-pool-type=hyperdisk-balanced \
    --zone=$ZONE --project=$PROJECT_ID --capacity-provisioning-type=advanced \
    --performance-provisioning-type=advanced --provisioned-iops=10000 \
    --provisioned-throughput=1024

Substitua PROJECT_ID pelo ID do projeto da sua Google Cloud conta.

Inspecionar zonas do pool de armazenamento

Para clusters do Autopilot e clusters padrão com provisionamento automático de nós ativado, é possível criar um pool de armazenamento em qualquer zona na região do cluster. Se não houver um pool de nós na zona em que você criou o pool de armazenamento, os pods vão permanecer no estado Pending até que o escalonador automático de clusters do GKE possa provisionar um novo pool de nós nessa zona.
Para clusters padrão sem provisionamento automático de nós, crie pools de armazenamento nas zonas de nó padrão do cluster, já que os pools de armazenamento são recursos zonais. É possível definir as zonas de nó do cluster usando a flag --node-locations.
- Para clusters zonais, se você não especificar o --node-locations, todos os nós serão criados na zona principal do cluster.
- Para clusters regionais, se você não especificar o --node-locations, o GKE vai distribuir seus nós de worker em três zonas escolhidas aleatoriamente na região.

Para inspecionar as zonas de nó padrão de um cluster, execute o seguinte comando:

gcloud container clusters describe CLUSTER_NAME  | yq '.locations'

Substitua CLUSTER_NAME pelo nome do cluster que você criaria ao provisionar um disco de inicialização ou um disco anexado.

Provisionar um disco de inicialização do GKE em um pool de armazenamento de hiperdisco

É possível provisionar um disco de inicialização do GKE em um pool de armazenamento de hiperdisco ao fazer qualquer uma das seguintes ações:

Ao criar um novo cluster do GKE
Ao criar um novo pool de nós
Ao atualizar um pool de nós

Ao criar um cluster

Para criar um cluster do GKE com discos de inicialização provisionados em um pool de armazenamento, use o comando a seguir:

gcloud container clusters create CLUSTER_NAME \
    --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
    --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
    --zone=ZONE

Substitua:

CLUSTER_NAME: forneça um nome exclusivo para o cluster que você está criando.
DISK_TYPE: defina como hyperdisk-balanced.. Se esse campo for deixado em branco, o tipo de disco será definido como Hyperdisk Balanced.
STORAGE_POOL,[...]: uma lista separada por vírgulas dos caminhos de recursos do grupo de armazenamento (por exemplo, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) em que os discos de inicialização do cluster serão provisionados. Verifique se as zonas nos caminhos de recursos do pool de armazenamento correspondem às zonas em --node-locations.
ZONE,[...]: uma lista separada por vírgulas de zonas em que a pegada do nó precisa ser replicada. Para clusters regionais, é possível especificar regiões. Todas as zonas precisam estar na mesma região do cluster, especificada pelas flags -location, --zone ou --region.
MACHINE_TYPE: o tipo de máquina compatível que você quer usar para os nós.
ZONE: a zona em que você quer criar o cluster. Use a flag —region para criar um cluster regional.

Ao criar um pool de nós

Para criar um pool de nós do GKE com discos de inicialização provisionados em um pool de armazenamento, use o seguinte comando:

gcloud container node-pools create NODE_POOL_NAME \
    --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
    --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
    --zone=ZONE --cluster=CLUSTER_NAME

Substitua:

NODE_POOL_NAME: forneça um nome exclusivo para o pool de nós que você está criando.
DISK_TYPE: defina como hyperdisk-balanced.. Se esse campo for deixado em branco, o tipo de disco será definido como Hyperdisk Balanced.
STORAGE_POOL,[...]: uma lista separada por vírgulas dos caminhos de recursos do grupo de armazenamento (por exemplo, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) em que os discos de inicialização do cluster serão provisionados. Verifique se as zonas nos caminhos de recursos do pool de armazenamento correspondem aos valores em --node-locations.
ZONE,[...]: uma lista separada por vírgulas de zonas em que a pegada do nó precisa ser replicada. Todas as zonas precisam estar na mesma região do cluster, especificada pelas flags -location, --zone ou --region.
MACHINE_TYPE: o tipo de máquina compatível que você quer usar para os nós.
ZONE: a zona em que você quer criar o pool de nós.
CLUSTER_NAME: um cluster em que você está criando o pool de nós.

Ao atualizar um pool de nós

É possível usar um comando update para adicionar ou substituir pools de armazenamento em um pool de nós. Esse comando não pode ser usado para remover pools de armazenamento de um pool de nós.

Para atualizar um pool de nós do GKE para que os discos de inicialização sejam provisionados em um pool de armazenamento, use o comando abaixo.

gcloud container node-pools update NODE_POOL_NAME \
  --storage-pools=STORAGE_POOL,[...] \
  --zone=ZONE --cluster=CLUSTER_NAME

NODE_POOL_NAME: o nome de um pool de nós existente que você quer atualizar para usar um pool de armazenamento.
STORAGE_POOL,[...]: uma lista separada por vírgulas de caminhos de recursos de pool de armazenamento (por exemplo, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c). Verifique se as zonas nos caminhos de recursos do pool de armazenamento correspondem à zona do pool de nós que você está atualizando.
ZONE: a zona em que o pool de nós está localizado.
CLUSTER_NAME: o nome do cluster do GKE ao qual esse pool de nós pertence.

Essa mudança requer a recriação dos nós, o que pode causar interrupções nas cargas de trabalho em execução. Para saber mais sobre essa mudança específica, encontre a linha correspondente na tabela mudanças manuais que recriam os nós usando uma estratégia de upgrade de nós sem respeitar as políticas de manutenção. Para saber mais sobre as atualizações de nós, consulte Planejar interrupções de atualização de nós.

Provisionar um disco anexado ao GKE em um pool de armazenamento de hiperdisco

Nesta seção, você vai aprender a fazer o seguinte:

Você cria um novo cluster do GKE com discos anexados provisionados em um pool de armazenamento.
Crie um StorageClass para provisionar dinamicamente um PersistentVolume (PV) quando um pod o solicitar por meio de um PersistentVolumeClaim (PVC). Para que um PV consuma os recursos compartilhados do pool de armazenamento, especifique o pool de armazenamento usando o parâmetro storage-pools no StorageClass. O StorageClass é usado em um PVC para provisionar o volume do Hyperdisk Balanced que será usado pelo pod.
Crie um PVC para solicitar um PV, parte do armazenamento do Hyperdisk, para um pod do cluster do GKE. Isso permite que você se beneficie dos recursos compartilhados do pool de armazenamento.
Crie uma implantação que use um PVC para garantir que o aplicativo tenha acesso ao armazenamento permanente mesmo após a reinicialização e reprogramação do pod.

Criar um cluster do GKE

Antes de começar, leia as considerações para provisionar um disco conectado.

Piloto automático

Para criar um cluster do Autopilot usando a gcloud CLI, consulte Criar um cluster do Autopilot.

Exemplo:

gcloud container clusters create-auto CLUSTER_NAME --region=REGION

Substitua:

CLUSTER_NAME: forneça um nome exclusivo para o cluster que você está criando.
REGION: a região em que você está criando o cluster.

Para selecionar um tipo de máquina compatível, especifique o cloud.google.com/compute-class: Performance nodeSelector ao criar uma implantação. Para uma lista de séries de máquinas do Compute Engine disponíveis com a classe de computação de desempenho, consulte Séries de máquinas compatíveis.

Padrão

Para criar um cluster zonal padrão usando a CLI gcloud, consulte Como criar um cluster zonal.

Para criar um cluster regional padrão usando a CLI gcloud, consulte Como criar um cluster regional.

Exemplo:

gcloud container clusters create CLUSTER_NAME --zone=ZONE --project=PROJECT_ID --machine-type=MACHINE_TYPE --disk-type="DISK_TYPE"

Substitua:

CLUSTER_NAME: forneça um nome exclusivo para o cluster que você está criando.
ZONE: a zona em que você está criando o cluster. Use a flag —region para criar um cluster regional.
PROJECT_ID: o ID do projeto da Google Cloud conta.
MACHINE_TYPE: o tipo de máquina compatível que você quer usar para os nós.
DISK_TYPE: defina como hyperdisk-balanced.. Se esse campo for deixado em branco, o tipo de disco será definido como Hyperdisk Balanced.

Criar um StorageClass

No Kubernetes, para indicar que você quer que o PV seja criado em um pool de armazenamento, use um StorageClass. Para saber mais, consulte Classes de armazenamento.

Para criar um novo StorageClass com o nível de capacidade ou IOPS desejado:

Use pd.csi.storage.gke.io no campo do provisionador.
Especifique o tipo de armazenamento do Hyperdisk equilibrado.
Especifique o parâmetro storage-pools com o valor como uma lista de pools de armazenamento específicos que você quer usar. Cada pool de armazenamento na lista precisa ser especificado no formato: projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME.
Opcionalmente, especifique os parâmetros de performance provisioned-throughput-on-create e provisioned-iops-on-create..

Cada tipo de Hyperdisk tem valores padrão para o desempenho determinado pelo tamanho inicial do disco provisionado. Ao criar um StorageClass, é possível especificar os parâmetros a seguir, dependendo do tipo de Hyperdisk. Se você omitir esses parâmetros, o GKE vai usar os padrões do tipo de disco com base em capacidade.

Parâmetro	Tipo de Hyperdisk	Uso
`provisioned-throughput-on-create`	Hyperdisk equilibrado, capacidade de processamento do Hyperdisk	Expresse o valor da capacidade de processamento em MiBps usando o qualificador "Mi". Por exemplo, se a capacidade necessária for de 250 MiBps, especifique `"250Mi"` ao criar o StorageClass.
`provisioned-iops-on-create`	Hyperdisk balanceado, IOPS do Hyperdisk	O valor de IOPS precisa ser expresso sem qualificadores. Por exemplo, se você precisar de 7.000 IOPS, especifique `"7000"` ao criar o StorageClass.

Para orientações sobre os valores permitidos para capacidade ou IOPS, consulte Planejar o nível de desempenho do volume do Hyperdisk.

Use o manifesto a seguir para criar e aplicar um StorageClass chamado storage-pools-sc para provisionar dinamicamente um PV no pool de armazenamento projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c:

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storage-pools-sc
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced
  provisioned-throughput-on-create: "140Mi"
  provisioned-iops-on-create: "3000"
  storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c
EOF

Ao usar o volumeBindingMode: WaitForFirstConsumer neste StorageClass, a vinculação e o provisionamento de um PVC são adiados até que um pod usando o PVC seja criado. Essa abordagem garante que o PV não seja provisionado prematuramente e que haja correspondência de zona entre o PV e o pod que o consome. Se as zonas não corresponderem, o pod vai permanecer no estado Pending.

Criar um PersistentVolumeClaim (PVC)

Crie um PVC que faça referência ao StorageClass storage-pools-sc que você criou.

Use o manifesto a seguir para criar um PVC chamado my-pvc, com 2048 GiB como a capacidade de armazenamento desejada para o volume do Hyperdisk Balanced:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: storage-pools-sc
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2048Gi
EOF

Criar uma implantação que use o PVC

Prática recomendada:

Ao usar pods com PersistentVolumes, use um controlador de carga de trabalho, como uma implantação ou um StatefulSet.

Para garantir que os pods possam ser programados em um pool de nós com uma série de máquinas que ofereça suporte ao Hyperdisk Balanceado, configure uma implantação com o seletor de nós cloud.google.com/machine-family. Para mais informações, consulte Suporte a tipos de máquina para hiperdiscos. Você usa a série de máquinas c3 na seguinte implantação de exemplo.

Crie e aplique o manifesto abaixo para configurar um pod para implantar um servidor da Web Postgres usando o PVC criado na seção anterior:

Piloto automático

Em clusters do Autopilot, especifique o cloud.google.com/compute-class: Performance nodeSelector para provisionar um volume do Hyperdisk Balanceado. Para mais informações, consulte Solicitar um nó dedicado para um pod.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
        cloud.google.com/compute-class: Performance
      containers:
      - name: postgres
        image: postgres:14-alpine
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc
EOF

Padrão

Em clusters padrão sem o provisionamento automático de nós ativado, verifique se um pool de nós com a série de máquinas especificada está ativo antes de criar a implantação. Caso contrário, a programação do pod falha.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
      containers:
      - name: postgres
        image: postgres:14-alpine
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc
EOF

Confirme se a implantação foi criada:

  kubectl get deployment

Pode levar alguns minutos para que as instâncias do Hyperdisk concluam o provisionamento e mostrem um status READY.

Confirmar se o disco anexado está provisionado

Verifique se o PVC chamado my-pvc foi vinculado a um PV:

kubectl get pvc my-pvc

O resultado será assim:


NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
my-pvc        Bound    pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6   2Ti        RWO            storage-pools-sc   2m24s

Verifique se o volume foi provisionado conforme especificado no StorageClass e no PVC:

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

O resultado será assim:

NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048

Fazer snapshots e restaurar discos conectados em pools de armazenamento

Não é permitido mover discos para dentro ou fora de um pool de armazenamento. Para mover um disco para dentro ou fora de um pool de armazenamento, recrie o disco com base em um snapshot. Para mais informações, consulte Alterar o tipo de disco.

Nesta seção, você vai aprender a fazer o seguinte:

Você grava um arquivo de teste no disco provisionado no pod.
Crie um snapshot de volume e exclua o arquivo de teste desse disco.
Restaure o snapshot em um novo disco no mesmo pool de armazenamento, recuperando os dados excluídos.

Criar um arquivo de teste

Para criar e verificar um arquivo de teste:

Consiga o nome do pod da implantação do Postgres:

kubectl get pods -l app=postgres

O resultado será assim:

NAME                         READY   STATUS    RESTARTS   AGE
postgres-78fc84c9ff-77vx6   1/1     Running   0          44s

Crie um arquivo de teste hello.txt no pod:

kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'echo "Hello World!" > /usr/share/data/hello.txt'

Verifique se o arquivo de teste foi criado:

kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!

Criar um snapshot de volume e excluir o arquivo de teste

Para criar e verificar um snapshot:

Crie um VolumeSnapshotClass que especifique como o snapshot dos seus volumes deve ser feito e gerenciado:

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapshotclass
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
EOF

Crie um VolumeSnapshot e faça o snapshot do volume vinculado ao PersistentVolumeClaim my-pvc:

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: my-snapshotclass
  source:
    persistentVolumeClaimName: my-pvc
EOF

Verifique se o conteúdo do snapshot do volume foi criado:

kubectl get volumesnapshotcontents

O resultado será assim:

NAME                                               READYTOUSE   RESTORESIZE     DELETIONPOLICY   DRIVER                  VOLUMESNAPSHOTCLASS   VOLUMESNAPSHOT   VOLUMESNAPSHOTNAMESPACE   AGE
snapcontent-e778fde2-5f1c-4a42-a43d-7f9d41d093da   false        2199023255552   Delete           pd.csi.storage.gke.io   my-snapshotclass      my-snapshot      default                   33s

Confirme se o snapshot está pronto para uso:

kubectl get volumesnapshot \
  -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'

O resultado será assim:

NAME          READY
my-snapshot   true

Exclua o arquivo de teste original hello.txt que foi criado no pod postgres-78fc84c9ff-77vx6:

kubectl exec postgres-78fc84c9ff-77vx6 \
    -- sh -c 'rm /usr/share/data/hello.txt'

Restaurar o snapshot do volume

Para restaurar o snapshot e os dados do volume, siga estas etapas:

Crie um novo PVC que restaure dados de um snapshot e garanta que o novo volume seja provisionado no mesmo pool de armazenamento (storage-pools-sc) que o volume original. Aplique o seguinte manifesto:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-restore
spec:
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: storage-pools-sc
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2048Gi
EOF

Atualize a implantação postgres para que ela use o PVC restaurado recém criado. Aplique o seguinte manifesto:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      nodeSelector:
        cloud.google.com/machine-family: c3
      containers:
      - name: postgres
        image: google/cloud-sdk:slim
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/data/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: pvc-restore
EOF

Receba o nome do pod recém-criado que faz parte da implantação postgres:

kubectl get pods -l app=postgres

O resultado será assim:

NAME                         READY   STATUS        RESTARTS   AGE
postgres-59f89cfd8c-42qtj   1/1     Running       0          40s

Verifique se o arquivo hello.txt, que foi excluído anteriormente, agora existe no novo pod (postgres-59f89cfd8c-42qtj) após a restauração do volume do snapshot:
```
kubectl exec postgres-59f89cfd8c-42qtj \
 -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!
```
Isso valida que o processo de snapshot e restauração foi concluído e que os dados do snapshot foram restaurados para o novo PV acessível ao pod.

Confirme se o volume criado com base no snapshot está localizado no seu pool de armazenamento:

kubectl get pvc pvc-restore

O resultado será assim:

NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
pvc-restore   Bound    pvc-b287c387-bc51-4100-a00e-b5241d411c82   2Ti        RWO            storage-pools-sc   2m24s

Verifique se o novo volume foi provisionado conforme especificado no StorageClass e no PVC:

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

A saída é semelhante à seguinte, em que você pode conferir o novo volume pvc-b287c387-bc51-4100-a00e-b5241d411c82 provisionado no mesmo pool de armazenamento.


NAME                                      STATUS  PROVISIONED_IOPS  PROVISIONED_THROUGHPUT  SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  READY   3000              140                     2048
pvc-b287c387-bc51-4100-a00e-b5241d411c82  READY   3000              140                     2048

Isso garante que o volume restaurado se beneficie dos recursos e recursos compartilhados do pool.

Migrar volumes para um pool de armazenamento

Use o snapshot e a restauração para migrar volumes que estão fora de um pool de armazenamento para um pool de armazenamento.

Verifique se as seguintes condições são atendidas:

O novo pvc-restore do PVC faz referência a um StorageClass que especifica o parâmetro storage-pools, apontando para o pool de armazenamento para o qual você quer mover o volume.
O PV de origem que está sendo criado precisa estar associado a um PVC com um StorageClass que não especifica o parâmetro storage-pools.

Depois de restaurar de um snapshot para um novo volume, é possível excluir o PVC e o PV de origem.

Limpar

Para evitar cobranças na sua conta Google Cloud , exclua os recursos de armazenamento criados neste guia. Primeiro, exclua todos os discos do pool de armazenamento e, depois, exclua o pool de armazenamento.

Excluir o disco de inicialização

Ao excluir um nó (reduzindo o pool de nós) ou um pool de nós inteiro, os discos de inicialização associados são excluídos automaticamente. Também é possível excluir o cluster para excluir automaticamente os discos de inicialização de todos os pools de nós nele.

Confira mais informações:

Excluir o disco anexado

Para excluir o disco anexado provisionado em um pool de armazenamento de hiperdisco:

Exclua o pod que usa o PVC:
```
kubectl delete deployments postgres
```
Exclua o PVC que usa o StorageClass do pool de armazenamento do Hyperdisk.
```
kubectl delete pvc my-pvc
```
Confirme se o PVC pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 foi excluído:
```
gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
```

Excluir o pool de armazenamento de hiperdisco

Exclua o pool de armazenamento de hiperdisco com o seguinte comando:

gcloud compute storage-pools delete pool-us-east4-c --zone=us-east4-c --project=my-project

A seguir

Consulte Solução de problemas de armazenamento no GKE.
Leia mais sobre o driver CSI do disco permanente no GitHub.