Faça uma cópia de segurança do armazenamento do Filestore através de instantâneos de volumes

Esta página mostra como fazer uma cópia de segurança e restaurar o armazenamento do Filestore através de instantâneos de volumes do Kubernetes.

A criação de um instantâneo de volume do Kubernetes é equivalente à criação de uma cópia de segurança do Filestore. Para mais informações, consulte o artigo Acerca das imagens instantâneas de volumes do Kubernetes.

Requisitos

Para usar as imagens instantâneas de volume no GKE, tem de cumprir os seguintes requisitos:

  • Tem de implementar o controlador CSI do Filestore. Apenas são suportados os seguintes níveis de serviço do Filestore:

    • HDD básico com a versão 1.21 ou posterior do GKE
    • HDD básico (100 GiB a 63,9 TiB) com a versão 1.33 ou posterior do GKE
    • SSD básico com a versão 1.21 ou posterior do GKE
    • Zonal (1 TiB a 9,75 TiB) com a versão 1.31 ou posterior do GKE
    • Zonal (10 TiB a 100 TiB) com a versão 1.27 ou posterior do GKE
    • Regional com a versão 1.33.4-gke.1172000 ou posterior do GKE
    • Enterprise com a versão 1.25 ou posterior do GKE

  • Use versões 1.17 ou posteriores do plano de controlo. Para usar o controlador CSI do Filestore num VolumeSnapshot, use o número da versão do GKE aplicável ao seu nível de serviço.

  • Ter um PersistentVolumeClaim existente para usar num instantâneo. O PersistentVolume que usa para uma origem de instantâneo tem de ser gerido por um controlador CSI. Pode verificar se está a usar um controlador CSI verificando se a especificação PersistentVolume tem uma secção csi com driver: pd.csi.storage.gke.io ou filestore.csi.storage.gke.io. Se o PersistentVolume for aprovisionado dinamicamente pelo controlador CSI, conforme descrito nas secções seguintes, é gerido pelo controlador CSI.

Limitações

  • Os volumes de instantâneos têm as mesmas restrições de tamanho que os volumes normais. Por exemplo, os instantâneos do Filestore têm de ter um tamanho igual ou superior a 1 TiB para o nível de disco rígido básico.

  • O controlador CSI do Filestore não suporta o aprovisionamento dinâmico nem os fluxos de trabalho de cópia de segurança para o nível de serviço do Filestore regional:

    • Só pode fazer uma cópia de segurança de uma partilha por instância de cada vez. Isto significa que não pode criar uma cópia de segurança com várias partilhas nem restaurar uma cópia de segurança para uma instância com várias partilhas. No entanto, os pedidos de cópia de segurança de duas partilhas diferentes em duas instâncias do Filestore diferentes são executados em simultâneo.

    • Pode restaurar uma cópia de segurança de uma instância básica para a instância de origem do mesmo nível de serviço, uma instância já existente ou uma nova instância. Se escolher uma nova instância, pode escolher entre uma instância de HDD básica e uma instância de SSD básica, independentemente do nível da instância de origem.

    • Não pode restaurar instâncias zonais, regionais e empresariais para uma origem ou uma instância existente, apenas para uma nova instância. O novo nível da instância não tem de corresponder ao nível da instância de origem. Por exemplo, pode restaurar uma cópia de segurança de uma instância regional para uma instância zonal. A capacidade aprovisionada da nova instância tem de ser igual ou superior à capacidade aprovisionada da instância de origem.

    Para ver uma lista completa das limitações das funcionalidades, consulte o artigo Limitações da funcionalidade de cópia de segurança do Filestore.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.

Criar e usar um instantâneo de volume

Os exemplos neste documento mostram como realizar as seguintes tarefas:

  1. Crie um PersistentVolumeClaim e um Deployment.
  2. Adicione um ficheiro ao PersistentVolume que o Deployment usa.
  3. Crie um VolumeSnapshotClass para configurar o instantâneo.
  4. Crie um instantâneo de volume do PersistentVolume.
  5. Elimine o ficheiro de teste.
  6. Restaure o PersistentVolume para o instantâneo que criou.
  7. Verifique se o restauro funcionou.

Para usar uma análise detalhada do volume, tem de concluir os seguintes passos:

  1. Crie um objeto VolumeSnapshotClass para especificar o controlador CSI e a política de eliminação para a sua captura instantânea.
  2. Crie um objeto VolumeSnapshot para pedir um instantâneo de um PersistentVolumeClaim existente.
  3. Faça referência ao VolumeSnapshot num PersistentVolumeClaim para restaurar um volume para essa imagem instantânea ou criar um novo volume com a imagem instantânea.

Crie um PersistentVolumeClaim e um Deployment

  1. Para criar o objeto PersistentVolumeClaim, guarde o seguinte manifesto como my-pvc.yaml:

    Filestore 

     apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: my-pvc
 spec:
   storageClassName: enterprise-rwx
   accessModes:
   - ReadWriteMany
   resources:
     requests:
       storage: 1Ti

    Este exemplo cria um PVC do Filestore ao nível da empresa. Para saber mais, consulte o artigo Aceda a instâncias do Filestore com o controlador CSI do Filestore.

    Para spec.storageClassName, pode especificar qualquer classe de armazenamento que use um controlador CSI suportado.

  2. Aplique o manifesto:

    kubectl apply -f my-pvc.yaml

  3. Para criar um Deployment, guarde o seguinte manifesto como my-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: google/cloud-sdk:slim
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: sdk-volume
          mountPath: /usr/share/hello/
      volumes:
      - name: sdk-volume
        persistentVolumeClaim:
          claimName: my-pvc

  4. Aplique o manifesto:

    kubectl apply -f my-deployment.yaml

  5. Verifique o estado do Deployment:

    kubectl get deployment hello-app

    O Deployment pode demorar algum tempo a ficar pronto. Pode executar o comando anterior até ver um resultado semelhante ao seguinte:

    NAME        READY   UP-TO-DATE   AVAILABLE   AGE
hello-app   1/1     1            1           2m55s

Adicione um ficheiro de teste ao volume

  1. Indica os Pods no Deployment:

    kubectl get pods -l app=hello-app

    O resultado é semelhante ao seguinte:

    NAME                         READY   STATUS    RESTARTS   AGE
hello-app-6d7b457c7d-vl4jr   1/1     Running   0          2m56s

  2. Crie um ficheiro de teste num Pod:

    kubectl exec POD_NAME \
    -- sh -c 'echo "Hello World!" > /usr/share/hello/hello.txt'

    Substitua POD_NAME pelo nome do Pod.

  3. Verifique se o ficheiro existe:

    kubectl exec POD_NAME \
    -- sh -c 'cat /usr/share/hello/hello.txt'

    O resultado é semelhante ao seguinte:

    Hello World!

Crie um objeto VolumeSnapshotClass

Crie um objeto VolumeSnapshotClass para especificar o controlador CSI e o deletionPolicy para a sua cópia instantânea do volume. Pode fazer referência a objetos VolumeSnapshotClass quando cria objetos VolumeSnapshot.

  1. Guarde o seguinte manifesto como volumesnapshotclass.yaml.

    Filestore 

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapshotclass
driver: filestore.csi.storage.gke.io
parameters:
  type: backup
deletionPolicy: Delete

    Neste exemplo:

    • O campo driver é usado pelo controlador CSI para aprovisionar a captura de ecrã. Neste exemplo, o filestore.csi.storage.gke.io usa o controlador CSI do Filestore.
    • O campo deletionPolicy indica ao GKE o que fazer com o objeto VolumeSnapshotContent e a imagem instantânea subjacente quando o objeto VolumeSnapshot associado é eliminado. Especifique Delete para eliminar o objeto VolumeSnapshotContent e a captura de ecrã subjacente. Especifique Retain se quer manter o VolumeSnapshotContent e a imagem subjacente.

  2. Aplique o manifesto:

    kubectl apply -f volumesnapshotclass.yaml

Crie um VolumeSnapshot

Um objeto VolumeSnapshot é um pedido de uma captura de ecrã de um objeto PersistentVolumeClaim existente. Quando cria um objeto VolumeSnapshot, o GKE cria e associa-o automaticamente a um objeto VolumeSnapshotContent, que é um recurso no seu cluster, como um objeto PersistentVolume.

  1. Guarde o seguinte manifesto como volumesnapshot.yaml.

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

  2. Aplique o manifesto:

    kubectl apply -f volumesnapshot.yaml

    Depois de criar uma Volume cópia instantânea, o GKE cria um objeto VolumeSnapshotContent correspondente no cluster. Este objeto armazena a imagem instantânea e as associações de VolumeSnapshot objetos. Não interage diretamente com objetos VolumeSnapshotContents.

  3. Confirme se o GKE criou o objeto VolumeSnapshotContents:

    kubectl get volumesnapshotcontents

    O resultado é semelhante ao seguinte:

    NAME                                               AGE
snapcontent-cee5fb1f-5427-11ea-a53c-42010a1000da   55s

Depois de criar o conteúdo da captura instantânea Volume, o controlador CSI especificado no VolumeSnapshotClass cria uma captura instantânea no sistema de armazenamento correspondente. Depois de o GKE criar um instantâneo no sistema de armazenamento e o associar a um objeto VolumeSnapshot no cluster, o instantâneo está pronto a ser usado. Pode verificar o estado executando o seguinte comando:

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

Se o instantâneo estiver pronto a usar, o resultado é semelhante ao seguinte:

NAME               READY
my-snapshot        true

Elimine o ficheiro de teste

  1. Elimine o ficheiro de teste que criou:

    kubectl exec POD_NAME \
    -- sh -c 'rm /usr/share/hello/hello.txt'

  2. Verifique se o ficheiro já não existe:

    kubectl exec POD_NAME \
    -- sh -c 'cat /usr/share/hello/hello.txt'

    O resultado é semelhante ao seguinte:

    cat: /usr/share/hello/hello.txt: No such file or directory

Restaure o instantâneo de volume

Pode fazer referência a um VolumeSnapshot num PersistentVolumeClaim para aprovisionar um novo volume com dados de um volume existente.

Para fazer referência a um VolumeSnapshot num PersistentVolumeClaim, adicione o campo dataSource ao seu PersistentVolumeClaim.

Neste exemplo, faz referência ao VolumeSnapshot que criou num novo PersistentVolumeClaim e atualiza o Deployment para usar a nova reivindicação.

  1. Guarde o seguinte manifesto como pvc-restore.yaml:

    Filestore 

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-restore
spec:
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: enterprise-rwx
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Ti

  2. Aplique o manifesto:

    kubectl apply -f pvc-restore.yaml

  3. Atualize o ficheiro my-deployment.yaml para usar o novo PersistentVolumeClaim:

    ...
volumes:
- name: my-volume
  persistentVolumeClaim:
    claimName: pvc-restore

  4. Aplique o manifesto atualizado:

    kubectl apply -f my-deployment.yaml

Verifique se o instantâneo foi restaurado com êxito

  1. Obtenha o nome do novo Pod que o GKE cria para o Deployment atualizado:

     kubectl get pods -l app=hello-app

Verifique se o ficheiro de teste existe:

   kubectl exec NEW_POD_NAME \
       -- sh -c 'cat /usr/share/hello/hello.txt'

Substitua NEW_POD_NAME pelo nome do novo Pod que o GKE criou.

O resultado é semelhante ao seguinte:

   Hello World!

Importe um Snapshot pré-existente

Pode usar uma captura instantânea de volume existente criada fora do cluster atual para aprovisionar manualmente o objeto VolumeSnapshotContents. Por exemplo, pode preencher um volume no GKE com uma captura de ecrã de outro recursoCloud de Confiance criado num cluster diferente.

  1. Localize o nome do instantâneo.

    Cloud de Confiance consola

    Aceda à página Instantâneos

    CLI do Google Cloud

    Execute o seguinte comando:

    gcloud compute snapshots list

    O resultado é semelhante ao seguinte:

    NAME                                           DISK_SIZE_GB  SRC_DISK                                                     STATUS
snapshot-5e6af474-cbcc-49ed-b53f-32262959a0a0  1             us-central1-b/disks/pvc-69f80fca-bb06-4519-9e7d-b26f45c1f4aa READY

  2. Guarde o seguinte manifesto VolumeSnapshot como restored-snapshot.yaml.

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: restored-snapshot
spec:
  volumeSnapshotClassName: my-snapshotclass
  source:
    volumeSnapshotContentName: restored-snapshot-content

  3. Aplique o manifesto:

    kubectl apply -f restored-snapshot.yaml

  4. Guarde o seguinte manifesto VolumeSnapshotContent como restored-snapshot-content.yaml. Substitua o campo snapshotHandle pelo ID do projeto e o nome da captura instantânea. Ambos os elementos volumeSnapshotRef.name e volumeSnapshotRef.namespace têm de apontar para o elemento VolumeSnapshot criado anteriormente para que a associação bidirecional seja válida.

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: restored-snapshot-content
spec:
  deletionPolicy: Retain
  driver: filestore.csi.storage.gke.io
  source:
    snapshotHandle: projects/PROJECT_ID/global/snapshots/SNAPSHOT_NAME
  volumeSnapshotRef:
    kind: VolumeSnapshot
    name: restored-snapshot
    namespace: default

  5. Aplique o manifesto:

    kubectl apply -f restored-snapshot-content.yaml

  6. Guarde o seguinte manifesto PersistentVolumeClaim como restored-pvc.yaml. O controlador de armazenamento do Kubernetes encontra um VolumeSnapshot com o nome restored-snapshot e, em seguida, tenta encontrar ou criar dinamicamente um PersistentVolume como origem de dados. Em seguida, pode usar este PVC num pod para aceder aos dados restaurados.

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-pvc
spec:
  dataSource:
    name: restored-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: enterprise-rwx
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

  7. Aplique o manifesto:

    kubectl apply -f restored-pvc.yaml

  8. Guarde o seguinte manifesto Pod como restored-pod.yaml, referindo-se ao PersistentVolumeClaim. O controlador CSI aprovisiona um PersistentVolume e preenche-o a partir do instantâneo.

    apiVersion: v1
kind: Pod
metadata:
  name: restored-pod
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "3600"
    volumeMounts:
    - name: source-data
      mountPath: /demo/data
  volumes:
  - name: source-data
    persistentVolumeClaim:
      claimName: restored-pvc
      readOnly: false

  9. Aplique o manifesto:

    kubectl apply -f restored-pod.yaml

  10. Verifique se o ficheiro foi restaurado:

    kubectl exec restored-pod -- sh -c 'cat /demo/data/hello.txt'

Limpar

Para evitar incorrer em cobranças na sua Cloud de Confiance by S3NS conta pelos recursos usados nesta página, siga estes passos.

  1. Elimine o VolumeSnapshot:

    kubectl delete volumesnapshot my-snapshot

  2. Elimine o VolumeSnapshotClass:

    kubectl delete volumesnapshotclass my-snapshotclass

  3. Elimine o Deployment:

    kubectl delete deployments hello-app

  4. Elimine os PersistentVolumeClaim objetos:

    kubectl delete pvc my-pvc pvc-restore

O que se segue?