Resolver problemas de erros de armazenamento no Backup para GKE

Nesta página, descrevemos erros relacionados ao armazenamento que podem ocorrer ao usar o Backup para GKE, o que considerar ao realizar a ação e as etapas para a solução de problemas.

Erro 100010105: falha ao fazer backup do PersistentVolumeClaim. O disco referenciado pelo PersistentVolume não existe

O erro 100010105 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha porque faz referência a um disco que não existe, resultando em uma mensagem de erro informando Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

No Google Kubernetes Engine, PersistentVolumeClaims solicita armazenamento de PersistentVolumes. Um PersistentVolume, por sua vez, representa uma parte do armazenamento, geralmente um disco permanente do Compute Engine. Um erro pode ocorrer quando um PersistentVolumeClaim é vinculado a um PersistentVolume e a configuração do PersistentVolume especifica um disco permanente do Compute Engine. No entanto, o disco real com o nome e o local especificados na configuração PersistentVolume não pode ser encontrado no projeto do Google Cloud . Assim, o Backup para GKE não pode fazer backup de um disco inexistente, e ocorre uma falha.

Para resolver esse erro, siga estas instruções:

  1. Identifique os PersistentVolumeClaim e PersistentVolume problemáticos. Os nomes do PersistentVolumeClaim problemático e do PersistentVolume associado são listados no campo state reason da operação com falha do Backup para GKE. Recomendamos documentar o nome do PersistentVolumeClaim, o namespace e o nome do PersistentVolume.

  2. Inspecione o PersistentVolume. Para descrever o PersistentVolume, use o nome PersistentVolume identificado no campo "Motivo do estado" no seguinte comando:

    kubectl describe pv PERSISTENTVOLUME_NAME
    

    Substitua PERSISTENTVOLUME_NAME pelo nome do PersistentVolume.

  3. Na saída, examine a seção source, especificamente em csi. Nesta seção, descrevemos o VolumeHandle que o PersistentVolume está tentando referenciar. Exemplo:

    Source:
      Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
    PDName: my-non-existent-disk
    FSType: ext4
    Partition: 0
    ReadOnly: false
                In this example, the PD name is my-non-existent-disk.
    
        Source:
      Type:       CSI (a Container Storage Interface (CSI) volume)
      Driver:     pd.csi.storage.gke.io
      VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
    ...
    

    Neste exemplo, VolumeHandle contém o caminho completo para o disco, incluindo o nome e o local. Por exemplo, projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. Use o VolumeHandle recebido da descrição de PersistentVolume para identificar o nome e a zona do disco.

  5. Verifique se o disco existe no projeto Google Cloud usando um dos seguintes métodos:

    Disco zonal

    Se você estiver usando um disco zonal, use a Google Cloud CLI para executar o comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
        --zone=ZONE_NAME \
        --project=PROJECT_ID
    

    Substitua:

    • DISK_NAME: o nome do disco que você recebeu na descrição de PersistentVolume.

    • ZONE_NAME: a zona do disco que você obteve na descrição de PersistentVolume.

    • PROJECT_ID: o ID do projeto Google Cloud .

    Disco regional

    Se você estiver usando um disco regional, use a Google Cloud CLI para executar o comando gcloud compute disks describe:

    gcloud compute disks describe DISK_NAME \
        --region=REGION_NAME \
        --project=PROJECT_ID
    

    Substitua:

    • DISK_NAME: o nome do disco que você recebeu da descrição de PersistentVolume.

    • REGION_NAME: a região do disco que você obteve na descrição PersistentVolume.

    • PROJECT_ID: o ID do projeto Google Cloud .

    Se você receber uma mensagem de erro Resource not found ou The resource DISK_NAME was not found, o disco não existe. Use um dos métodos a seguir para resolver o problema, dependendo do cenário que melhor se adapta às suas necessidades:

    • Se o disco foi excluído ou nomeado incorretamente por acidente e você quer manter os dados ou o PersistentVolumeClaim, ou se o PersistentVolume foi configurado com um nome de disco incorreto, use um dos seguintes métodos para resolver o problema:

      • Restaure o disco: se você tiver um backup do disco, restaure-o com o mesmo nome e local que o PersistentVolume referencia.

      • Criar um novo disco: se não for possível restaurar o disco, crie um novo com o mesmo nome e local que estão na configuração de PersistentVolume.

    • Se o PersistentVolumeClaim ou o PersistentVolume, os dados deles ou o aplicativo não forem mais necessários, recomendamos remover a entidade desnecessária:

      • Exclua o PersistentVolumeClaim: exclua o PersistentVolumeClaim usando a ferramenta de linha de comando kubectl para executar o comando kubectl delete pvc:
      kubectl delete pvc PVC_NAME -n NAMESPACE
      

      Substitua:

      • PVC_NAME: o nome do PersistentVolumeClaim que você quer excluir.

      • NAMESPACE: o namespace do PersistentVolumeClaim que você quer excluir.

    • O PersistentVolume ainda estará presente depois que você excluir o PersistentVolumeClaim: se o PersistentVolumeReclaimPolicy do PersistentVolume estiver definido como Delete, o PersistentVolume será excluído automaticamente quando o PersistentVolumeClaim for excluído. Se o persistentVolumeReclaimPolicy estiver definido como Retain, será necessário excluir manualmente o PersistentVolume depois que o PersistentVolumeClaim for excluído. Para excluir o PersistentVolume, use a ferramenta de linha de comando kubectl para executar o comando kubectl delete pv:

      kubectl delete pv PV_NAME
      

      Substitua PV_NAME pelo nome do PersistentVolume que você quer excluir.

Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010202: falha ao criar o snapshot do volume

O erro 100010202 ocorre quando a criação do snapshot do disco permanente do Compute Engine falha, resultando em uma mensagem de erro que indica Snapshotting volume failed.

Uma operação de snapshot do Persistent Disk do Compute Engine falha se o estado de conexão do disco a uma instância de máquina virtual (VM) mudar durante o processo de criação de snapshot iniciado pelo serviço Backup para GKE. Alguns cenários comuns que acionam isso incluem:

  • Reparo automático de nós: os nós não íntegros são recriados, o que faz com que os pods sejam reprogramados e os discos sejam desanexados e anexados novamente.
  • Upgrades de nós: durante os upgrades do pool de nós, os nós geralmente são drenados e substituídos. Os pods são encerrados e reprogramados sem dificuldades nos novos nós, acionando ciclos de remoção e reconexão de disco.
  • Escalonamento automático de cluster: durante eventos de redução de escala, se o escalonador automático de cluster remover um nó, todos os pods nesse nó com discos permanentes serão removidos, causando desvinculações de disco. Se esses pods forem reprogramados em outro lugar, as conexões vão ocorrer nos novos nós. Durante eventos de escalonamento vertical, os novos nós não causam reconexões diretas, mas os pods agendados neles acionam conexões iniciais.

Esse erro é temporário. O backup geralmente é concluído na próxima execução automatizada quando a conexão do disco é estabilizada. Para evitar que os eventos de cluster afetem seus backups, siga estas recomendações:

  1. Ative a Programação inteligente: configure seu plano de backup usando a Programação inteligente, que é baseada no RPO. Isso permite que o sistema tente novamente de forma automática falhas temporárias dentro do período especificado sem afetar o RPO geral do plano de backup.

  2. Configurar janelas de exclusão de backup: se você estiver fazendo upgrades do pool de nós ou operações de redimensionamento do cluster, adicione uma janela de exclusão de backup às configurações de backup durante esses intervalos. Isso garante que o serviço Backup para GKE pause e evite programar snapshots enquanto o cluster estiver modificando anexos de disco.

  3. Tentar novamente backups manuais: no caso de backups manuais ou sob demanda, tente de novo a operação de backup quando o evento do cluster terminar.

Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

A seguir