Resolver problemas de erros de armazenamento no Backup para GKE

Esta página descreve os 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 resolver o problema.

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 ele referencia 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, os PersistentVolumeClaims solicitam 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 está vinculado a um PersistentVolume e a configuração do PersistentVolume's especifica um disco permanente do Compute Engine. No entanto, o disco real com o nome e o local especificados na configuração do PersistentVolume não pode ser encontrado no seu Cloud de Confiance by S3NS projeto. 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 o PersistentVolumeClaim e o PersistentVolume problemáticos. Os nomes do PersistentVolumeClaim problemático e do associado PersistentVolume estão listados no campo state reason da operação com falha do Backup para GKE. Recomendamos documentar o PersistentVolumeClaim nome, o namespace e o nome do PersistentVolume.

  2. Inspecione o PersistentVolume. Para descrever o PersistentVolume, use o nome do PersistentVolume identificado no campo de motivo do estado no comando a seguir:

    kubectl describe pv PERSISTENTVOLUME_NAME

    Substitua PERSISTENTVOLUME_NAME pelo nome do seu PersistentVolume.

  3. Na saída, examine a seção source, especificamente em csi. Essa seção descreve 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, o 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 do PersistentVolume para identificar o nome e a zona do disco.

  5. Verifique se o disco existe no seu Cloud de Confiance by S3NS projeto 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 da descrição do PersistentVolume.

    • ZONE_NAME: a zona do disco que você recebeu da descrição do PersistentVolume.

    • PROJECT_ID: o ID do Cloud de Confiance by S3NS projeto.

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

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

    • PROJECT_ID: o ID do Cloud de Confiance by S3NS projeto.

    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 engano e você quer manter os dados ou PersistentVolumeClaim, ou se o PersistentVolume foi configurado com um nome de disco incorreto, use um dos seguintes métodos para resolver o problema:

      • Restaurar o disco: se você tiver um backup do disco, restaure-o com o mesmo nome e local referenciados pelo PersistentVolume.

      • Criar um novo disco: se a restauração do disco não for uma opção, crie um novo disco com o mesmo nome e local da PersistentVolume configuração.

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

      • Excluir 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 está presente depois que você exclui o PersistentVolumeClaim: se a PersistentVolumeReclaimPolicy do PersistentVolume estiver definida 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 após a exclusão do PersistentVolumeClaim. 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.

Cloud de Confiance by S3NS

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

Erro 100010202: falha ao criar snapshot do volume

O erro 100010202 ocorre quando a criação de snapshots de discos permanentes do Compute Engine falha, resultando em uma mensagem de erro informando Snapshotting volume failed.

Uma operação de snapshot de disco permanente 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 snapshots iniciado pelo serviço de backup para GKE. Os cenários comuns que acionam isso incluem o seguinte:

  • Reparo automático de nós: os nós com falha são recriados, o que faz com que os pods sejam reagendados e os discos sejam desanexados e anexados novamente.
  • Upgrades de nós: durante os upgrades do pool de nós, os nós são normalmente consumidos e substituídos. Os pods são encerrados normalmente e reagendados nos novos nós, acionando ciclos de desanexação e anexação de discos.
  • Escalonamento automático de clusters: durante eventos de redução, se o escalonador automático de clusters remover um nó, todos os pods nesse nó com discos permanentes serão removidos, causando desanexações de discos. Se esses pods forem reagendados em outro lugar, os anexos ocorrerão nos novos nós. Durante eventos de escalonamento, novos nós não causam diretamente novas anexações, mas os pods programados neles acionam anexos iniciais.

Esse erro é temporário. O backup normalmente é bem-sucedido na próxima execução automatizada quando a conexão do disco se estabiliza. Para evitar que eventos de cluster afetem seus backups, aplique as seguintes recomendações:

  1. Ativar a Programação inteligente: configure seu plano de backup usando a Programação inteligente (uma programação baseada em RPO). Isso permite que o sistema tente novamente falhas temporárias automaticamente na janela de tempo especificada, sem afetar o RPO geral do plano de backup.

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

  3. Tentar novamente backups manuais: no caso de backups manuais ou sob demanda, tente novamente 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