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:
Identifique os
PersistentVolumeClaimePersistentVolumeproblemáticos. Os nomes doPersistentVolumeClaimproblemático e doPersistentVolumeassociado são listados no campostate reasonda operação com falha do Backup para GKE. Recomendamos documentar o nome doPersistentVolumeClaim, o namespace e o nome doPersistentVolume.Inspecione o
PersistentVolume. Para descrever oPersistentVolume, use o nomePersistentVolumeidentificado no campo "Motivo do estado" no seguinte comando:kubectl describe pv PERSISTENTVOLUME_NAMESubstitua
PERSISTENTVOLUME_NAMEpelo nome do PersistentVolume.Na saída, examine a seção
source, especificamente emcsi. Nesta seção, descrevemos oVolumeHandleque oPersistentVolumeestá 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,
VolumeHandleconté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.Use o
VolumeHandlerecebido da descrição dePersistentVolumepara identificar o nome e a zona do disco.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_IDSubstitua:
DISK_NAME: o nome do disco que você recebeu na descrição dePersistentVolume.ZONE_NAME: a zona do disco que você obteve na descrição dePersistentVolume.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_IDSubstitua:
DISK_NAME: o nome do disco que você recebeu da descrição dePersistentVolume.REGION_NAME: a região do disco que você obteve na descriçãoPersistentVolume.PROJECT_ID: o ID do projeto Google Cloud .
Se você receber uma mensagem de erro
Resource not foundouThe 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 oPersistentVolumefoi 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
PersistentVolumereferencia.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
PersistentVolumeClaimou oPersistentVolume, os dados deles ou o aplicativo não forem mais necessários, recomendamos remover a entidade desnecessária:- Exclua o
PersistentVolumeClaim: exclua oPersistentVolumeClaimusando a ferramenta de linha de comandokubectlpara executar o comandokubectl delete pvc:
kubectl delete pvc PVC_NAME -n NAMESPACESubstitua:
PVC_NAME: o nome doPersistentVolumeClaimque você quer excluir.NAMESPACE: o namespace doPersistentVolumeClaimque você quer excluir.
- Exclua o
O
PersistentVolumeainda estará presente depois que você excluir oPersistentVolumeClaim: se oPersistentVolumeReclaimPolicydoPersistentVolumeestiver definido comoDelete, oPersistentVolumeserá excluído automaticamente quando oPersistentVolumeClaimfor excluído. Se opersistentVolumeReclaimPolicyestiver definido comoRetain, será necessário excluir manualmente oPersistentVolumedepois que oPersistentVolumeClaimfor excluído. Para excluir oPersistentVolume, use a ferramenta de linha de comandokubectlpara executar o comandokubectl delete pv:kubectl delete pv PV_NAMESubstitua
PV_NAMEpelo nome doPersistentVolumeque 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:
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.
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.
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.