Resolva problemas de erros de autorização na Cópia de segurança do GKE

Autopilot Padrão

Este documento descreve os erros e os códigos correspondentes que pode encontrar quando usa a Cópia de segurança para o GKE para realizar operações de restauro. Cada secção inclui aspetos a ter em conta quando realizar ações para resolver os erros de restauro, bem como instruções sobre como resolver os erros da operação de restauro.

Erro 200010301: falha ao concluir a operação de restauro devido ao serviço de webhook de admissão indisponível

O erro 200010301 ocorre quando uma tentativa de concluir uma operação de restauro falha porque um serviço de webhook de admissão, também denominado callback HTTP, está indisponível, o que resulta na seguinte mensagem de erro. A mensagem de erro indica que o servidor da API GKE tentou contactar um webhook de admissão ao tentar restaurar um recurso, mas o serviço que suporta o webhook estava indisponível ou não foi encontrado:

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

Este erro ocorre quando um recurso do GKE ValidatingAdmissionWebhook ou MutatingAdmissionWebhook está ativo no cluster de destino, mas o servidor da API GKE não consegue alcançar o ponto final configurado no webhook. Os webhooks de admissão intercetam pedidos para o servidor da API GKE e a respetiva configuração especifica como o servidor da API GKE deve consultar os pedidos.

O clientConfig do webhook especifica o back-end que processa os pedidos de admissão, que pode ser um serviço de cluster interno ou um URL externo. A escolha entre estas duas opções depende dos requisitos operacionais e de arquitetura específicos do seu webhook. Consoante o tipo de opção, a operação de restauro pode ter falhado pelos seguintes motivos:

• Serviços no cluster: o serviço GKE e os respetivos pods de apoio não são restaurados nem estão prontos quando o servidor da API GKE tentou chamar o webhook. Isto ocorre durante as operações de restauro em que as configurações de webhook com âmbito de cluster são aplicadas antes de os serviços com âmbito de espaço de nomes estarem totalmente no estado ready.

• URLs externos: o ponto final externo está temporariamente indisponível devido a problemas de conetividade de rede entre o cluster do GKE e o ponto final externo, ou devido a problemas de resolução de DNS ou regras de firewall.

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

1. Identifique o webhook com falha mencionado na mensagem de erro. Por exemplo, failed calling webhook "...".

2. Inspecione o webhook executando o comando kubectl get validatingwebhookconfigurations:

   kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   Substitua WEBHOOK_NAME pelo nome do webhook que foi identificado na mensagem de erro.

   Também pode executar o comando kubectl get mutatingwebhookconfigurations para inspecionar o webhook:

   kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   Substitua WEBHOOK_NAME pelo nome do webhook que foi identificado na mensagem de erro.

   Nota: os webhooks estão a validar ou a alterar. Por conseguinte, consoante o tipo de webhook, apenas um destes comandos é bem-sucedido.

3. Execute os seguintes passos de resolução de problemas com base no seu tipo de configuração:

   Com base em serviços clientConfig

   Defina uma ordem de restauro personalizada modificando o recurso RestorePlan para incluir um RestoreOrder com entradas GroupKindDependency. Isto permite que os componentes que suportam o webhook, como Deployment, StatefulSet ou Service, sejam restaurados e fiquem prontos antes do ValidatingWebhookConfiguration ou MutatingWebhookConfiguration.

   Para obter instruções sobre como definir uma ordem de restauro personalizada, consulte o artigo Especifique a ordem de restauro de recursos durante o restauro.

   Esta abordagem pode falhar porque os pods do serviço não entram num estado totalmente ready, mesmo depois de o objeto Service ser criado. Outro motivo para a falha pode ser o facto de a configuração do webhook poder ter sido criada inesperadamente por outra aplicação. Em alternativa, pode efetuar uma operação de restauro em duas fases através dos seguintes passos:

   1. Crie um recurso Restore com a cópia de segurança configurando a operação de restauro com um filtro de restauro detalhado que inclua os recursos específicos necessários para o funcionamento do webhook, por exemplo, Namespaces, Deployments, StatefulSets ou Services.

      Para mais informações sobre como configurar a restauração com um filtro de restauração detalhado, consulte o artigo Ative a restauração detalhada.

   2. Crie outro recurso Restore para a operação de cópia de segurança e configure os restantes recursos que escolher.

   Baseado em URL clientConfig

   1. Valide o ponto final HTTPS externo e certifique-se de que está ativo, acessível e a funcionar corretamente.

   2. Confirme se existe conetividade de rede dos nós e do plano de controlo do cluster do GKE para o URL externo. Também pode ter de verificar as regras da firewall, por exemplo, se estiver a usar a nuvem privada virtual, no local ou um fornecedor de nuvem que aloja o webhook, as políticas de rede e a resolução de DNS.

4. Repita a operação de restauro. Se a operação continuar a falhar, contacte o apoio técnico do Google Cloud para receber assistência adicional.

Erro 200010302: falha ao concluir a operação de restauro devido ao pedido de criação de recursos recusado

O erro 200010302 ocorre quando uma tentativa de concluir uma operação de restauro falha porque um webhook de admissão nega um pedido de criação de recursos, o que resulta na seguinte mensagem de erro a indicar que não foi possível criar um recurso da sua cópia de segurança no cluster de destino porque um webhook de admissão ativo intercetou o pedido e o rejeitou com base numa política personalizada:

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

Este erro é causado pela configuração definida no cluster GKE de destino, que tem um ValidatingAdmissionWebhook ou um MutatingAdmissionWebhook que aplica regras específicas à criação e modificação de recursos, bloqueando o pedido de criação de recursos. Por exemplo, um webhook impede a criação de um recurso porque já existe um recurso relacionado, mas em conflito, no cluster. Por exemplo, um webhook pode negar a criação de uma implementação se já for gerida por um recurso da API GKE HorizontalPodAutoscaler.

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

1. Identifique o webhook que está a recusar o pedido através da mensagem de erro que ocorre quando a operação de restauro falha. Por exemplo, webhook WEBHOOK_NAME denied the request A mensagem de erro contém as seguintes informações:

   • Nome do webhook: o nome do webhook que está a recusar o pedido.

   • Motivo da recusa: o motivo específico da recusa do pedido.

2. Inspecione o webhook executando o comando kubectl get validatingwebhookconfigurations:

   kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   Substitua WEBHOOK_NAME pelo nome do webhook que identificou na mensagem de erro.

   Também pode executar o comando kubectl get mutatingwebhookconfigurations para inspecionar o webhook:

   kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   Substitua WEBHOOK_NAME pelo nome do webhook que identificou na mensagem de erro.

   Nota: os webhooks estão a validar ou a alterar. Por conseguinte, consoante o tipo de webhook, apenas um destes comandos é bem-sucedido.

3. Resolva o problema subjacente no cluster de destino. A ação correta depende do erro específico. No exemplo, se existir um HorizontalPodAutoscaler conflito, tem de eliminar o HorizontalPodAutoscaler existente no cluster de destino antes de executar o restauro para permitir a criação das cargas de trabalho de cópia de segurança e dos respetivos recursos associados.

4. Repita a operação de restauro. Se a operação de restauro continuar a falhar, contacte o apoio ao cliente do Google Cloud para receber assistência adicional.

Erro 200060202: falha ao concluir a operação de restauro devido à falta de recursos do GKE durante a validação da carga de trabalho

O erro 200060202 ocorre durante a fase de validação da carga de trabalho de uma operação de restauro quando não é possível encontrar um recurso do GKE que o Backup for GKE espera validar no cluster de destino, o que resulta na seguinte mensagem de erro:

  Workload Validation Error: [KIND] "[NAME]" not found

Por exemplo, Example: Workload Validation Error: pods "jenkins-0" not found

Este erro ocorre quando o Backup for GKE cria ou atualiza com êxito o recurso do GKE como parte do processo da operação de restauro, mas quando a fase de validação começa, um ou mais dos recursos do GKE já não estão presentes no cluster de destino porque o recurso foi eliminado após ter sido criado ou atualizado inicialmente pelo processo de restauro, mas antes de a validação da carga de trabalho do recurso do GKE poder ser concluída. Um erro como este pode ocorrer pelos seguintes motivos:

• Eliminação manual: um utilizador ou um administrador eliminou manualmente o recurso através do kubectl ou de outras Google Cloud ferramentas.

• Automatização externa: os controladores GitOps, como o Config Sync, o ArgoCD, o Flux, os scripts personalizados ou outras ferramentas de gestão de clusters, reverteram ou eliminaram o recurso para corresponder a um estado pretendido num repositório.

• Controladores do GKE: um controlador do GKE eliminou um recurso porque entra em conflito com outros recursos ou políticas, ou uma cadeia de OwnerReference leva à recolha de lixo, ou o processo de limpeza automatizado do GKE que elimina recursos dependentes quando o respetivo recurso owner é eliminado.

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

1. Identifique o recurso em falta através da mensagem de erro apresentada quando a operação de restauro não for concluída.

2. Localize o espaço de nomes ao qual o recurso pertence através de um dos seguintes métodos:

   • Registos de auditoria do GKE: examine os registos de auditoria do GKE que foram gerados quando tentou realizar a operação de restauro. Pode filtrar os registos de operações de eliminação no recurso Kind e Name. A entrada do registo de auditoria contém o espaço de nomes original.

   • Detalhes da cópia de segurança: reveja o âmbito da operação de restauro e o conteúdo da cópia de segurança. O índice de cópia de segurança mostra o espaço de nomes original do recurso. Também pode verificar se o RestorePlan contém um TransformationRule que especifica regras para restaurar o recurso no espaço de nomes que escolher.

   • Pesquisar em todos os espaços de nomes: execute o comando kubectl get para pesquisar o recurso em todos os espaços de nomes:

     kubectl get KIND --all-namespaces | grep NAME
     

     Substitua KIND e NAME pelos valores da mensagem de erro. Se o recurso ainda existir, este comando mostra o respetivo espaço de nomes.

3. Execute o comando kubectl get para verificar a eliminação:

   kubectl get KIND NAME -n [NAMESPACE]
   

   Substitua KIND e NAME pelos valores da mensagem de erro. Deve receber uma not found mensagem de erro.

4. Investigue a causa da eliminação através de um dos seguintes métodos:

   • Registos de auditoria do GKE: identificam que entidade emitiu o pedido de eliminação. Por exemplo, o utilizador, a conta de serviço ou o controlador.

   • Reveja as automatizações configuradas: se usar o GitOps ou outras ferramentas de automatização, verifique os respetivos registos e estado para ver se interferiram com os recursos restaurados.

   • Examine os eventos relacionados: verifique os eventos do GKE no espaço de nomes determinado executando o comando kubectl get events:

     kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'
     

     Substitua NAMESPACE_NAME pelo nome do espaço de nomes.

5. Resolva a causa da eliminação do recurso com base nos resultados do passo anterior. Por exemplo, pausar automatizações em conflito, corrigir configurações incorretas ou ajustar as autorizações dos utilizadores.

6. Recupere o recurso em falta através de um dos seguintes métodos:

   • Volte a aplicar os ficheiros de manifesto: se tiver o manifesto para o recurso em falta, pode voltar a aplicá-lo ao espaço de nomes correto.

   • Efetue um restauro detalhado: efetue uma operação de restauro detalhada para restaurar seletivamente apenas o recurso em falta a partir da mesma cópia de segurança, o que garante que especifica o espaço de nomes correto. Para mais informações sobre como realizar uma operação de restauro detalhada, consulte o artigo Ative o restauro detalhado.

     Nota: o erro aponta apenas para um recurso que não foi encontrado, mas pode haver mais do que um recurso que, na verdade, não existe no cluster de destino.

7. Repita a operação de restauro. Se a operação de restauro continuar a falhar, contacte o apoio ao cliente do Google Cloud para receber assistência adicional.

Erro 200060201: falha ao concluir a operação de restauro devido ao limite de tempo de validação da carga de trabalho

O erro 200060201 ocorre quando uma ou mais cargas de trabalho restauradas não ficam totalmente ready durante uma operação de restauro dentro do limite de tempo esperado após os recursos terem sido criados no cluster, o que resulta na seguinte mensagem de erro:

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

Este erro ocorre porque o Backup for GKE executa um passo de validação após a restauração das configurações de recursos do GKE para garantir que as cargas de trabalho críticas estão a funcionar corretamente. A cópia de segurança do GKE aguarda que determinadas cargas de trabalho atinjam um estado ready, mas, pelo menos, uma carga de trabalho não cumpriu o seguinte critério de prontidão dentro do período de limite de tempo atribuído:

• Para Pods: status.Phase é Running

• Para Deployments: status.ReadyReplicas é igual a spec.Replicas

• Para StatefulSets: status.ReadyReplicas é igual a spec.Replicas

• Para DaemonSets: status.NumberReady é igual a status.DesiredNumberScheduled

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

1. Identifique as cargas de trabalho que não estão num estado ready na mensagem de erro que lista as cargas de trabalho e os respetivos espaços de nomes que não entraram num estado ready.

2. Inspecione o estado da carga de trabalho e obtenha detalhes e eventos das cargas de trabalho com falhas executando o comando kubectl describe:

   kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
   kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD
   

   Substitua o seguinte:

   • WORKLOAD_TYPE: o tipo de carga de trabalho, por exemplo, Deployment, StatefulSet ou DaemonSet.

   • WORKLOAD_NAME: o nome da instância da carga de trabalho específica.

   • NAMESPACE_NAME: o espaço de nomes onde a carga de trabalho está localizada.

   • SELECTOR_FOR_WORKLOAD: o seletor de etiquetas para encontrar Pods associado à carga de trabalho. Por exemplo, app=my-app.

   Para pods nos tipos de carga de trabalho Deployments ou StatefulSets, verifique o estado dos pods individuais executando o comando kubectl describe pod:

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

   Substitua o seguinte:

   • POD_NAME: o nome do agrupamento específico.

   • NAMESPACE_NAME: o espaço de nomes onde o pod está localizado.

3. Na secção Events, analise os eventos e os registos na saída describe e localize as seguintes informações:

   • ImagePullBackOff / ErrImagePull: indica que existem problemas ao obter imagens de contentores.

   • CrashLoopBackOff: indica que os contentores estão a iniciar e a falhar.

4. Na secção Containers, analise os registos do contentor na saída describe para encontrar o nome do contentor executando o comando kubectl logs:

   kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME
   

   Substitua o seguinte:

   • POD_NAME: o nome do agrupamento específico.

   • NAMESPACE_NAME: o espaço de nomes onde o pod está localizado.

   • CONTAINER_NAME: o nome do contentor no agrupamento.

   De acordo com o resultado de describe, existem vários motivos pelos quais o pod pode não aparecer no resultado do recurso, incluindo os seguintes:

   • Falhas de sondagem de disposição: as sondagens de disposição do contentor não estão a ter êxito.

   • Problemas de recursos: existem recursos insuficientes de CPU, memória ou outros no cluster, ou os limites de quota foram atingidos.

   • Problemas com o contentor de inicialização: falhas nos contentores de inicialização que impedem o início dos contentores principais.

   • Erros de configuração: erros em ConfigMaps, Secrets ou variáveis de ambiente.

   • Problemas de rede: não é possível comunicar com os serviços necessários.Pods

5. Verifique os recursos do cluster do GKE para garantir que o cluster do GKE tem capacidade de nó, CPU e memória suficientes para executar as cargas de trabalho restauradas. Nos clusters do Autopilot, o aprovisionamento automático de nós pode demorar mais tempo. Por isso, recomendamos que verifique se existem limitações ou erros de escalabilidade de nós. Resolva os problemas subjacentes com base nas suas conclusões e resolva os problemas que impedem que as cargas de trabalho entrem num estado ready. Esta abordagem pode envolver a correção de manifestos, o ajuste de pedidos ou limites de recursos, a correção de políticas de rede ou a garantia de que os requisitos são cumpridos.

6. Depois de os problemas subjacentes serem resolvidos, aguarde que as cargas de trabalho entrem num estado ready. Não precisa de executar novamente a operação de restauro.

Se o problema persistir, contacte o apoio ao cliente do Google Cloud para receber assistência adicional.

Erro 200060102: falha ao concluir a operação de restauro devido a um erro de validação do volume

O erro 200060102 ocorre porque um ou mais recursos VolumeRestore, que gerem o processo de restauro de dados de VolumeBackup para um PersistentVolume, entraram num estado failed ou deleting durante a fase de validação de volume de uma operação de restauro. A restauração do volume falhada resulta na seguinte mensagem de erro no campo stateReason do recurso de restauro:

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

A mensagem de erro indica os nomes de recursos completos do VolumeRestore com falha, incluindo o nome e o espaço de nomes do PersistentVolumeClaim de destino. A mensagem de erro indica que o processo de restauro de dados para o PersistentVolumeClaim afetado não foi concluído com êxito quando a Cópia de segurança para o GKE iniciou recursos VolumeRestore para aprovisionar PersistentVolumes a partir de VolumeBackups e a criação do disco persistente subjacente a partir da captura de ecrã falhou. As falhas de VolumeRestore podem ocorrer pelos seguintes motivos:

• Quota insuficiente: não existe quota de disco persistente alocada suficiente no projeto ou na região, por exemplo, SSD_TOTAL_GB.

• Problemas de autorização: a conta de serviço usada pelo Backup for GKE não tem as autorizações necessárias para criar discos ou aceder a instantâneos.

• Problemas de rede: existem problemas de rede transitórios ou persistentes que interrompem o processo de criação do disco.

• Instantâneo inválido: a origem VolumeBackup ou o instantâneo do disco persistente subjacente está danificado ou inacessível.

• Restrições de recursos: outras restrições de recursos de cluster estão a dificultar o aprovisionamento de volumes.

• Erros internos: existem problemas internos no serviço Persistent Disk.

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

1. Identifique o PersistentVolumeClaims com falhas indicado na mensagem de erro, que apresenta os nomes dos recursos completos dos objetos VolumeRestore com falhas.

2. Obtenha detalhes de cada recurso VolumeRestore com falhas executando o comando gcloud beta container backup-restore volume-restores describe:

   gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
   --project=PROJECT_ID \
   --location=LOCATION \
   --restore-plan=RESTORE_PLAN_ID \
   --restore=RESTORE_ID
   

   Substitua o seguinte:

   • VOLUME_RESTORE_ID: o ID do recurso VolumeRestore com falha.

   • PROJECT_ID: o ID do seu projeto Google Cloud .

   • LOCATION: a Google Cloud localização do restauro.

   • RESTORE_PLAN_ID: o ID do plano de restauro.

   • RESTORE_ID: o ID da operação de restauro.

3. Examine os campos state e stateMessage no resultado para ver detalhes sobre a falha.

   Nota: em alguns casos, o nome e o espaço de nomes do PersistentVolumeClaim não estão na mensagem de erro da operação de restauro. Use o campo stateMessage do comando gcloud describe acima para encontrar os detalhes PersistentVolumeClaim do alvo.

4. Examine o estado do destino PersistentVolumeClaim executando o comando kubectl get pvc:

   kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml
   

   Substitua o seguinte:

   • PVC_NAME: o nome do recurso PersistentVolumeClaim

   • NAMESPACE_NAME: o espaço de nomes onde o elemento PersistentVolumeClaim está localizado.

5. Confirme se a secção status.phase da saída indica uma Pending fase. Esta fase significa que o PersistentVolumeClaim ainda não está associado a um PersistentVolume, o que é esperado se o VolumeRestore falhar.

6. Inspeccione a secção Events no resultado YAML para ver mensagens relacionadas com falhas de aprovisionamento, como ProvisioningFailed, por exemplo:

   Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).
   

   O resultado indica que existe um problema de autorização ao aceder à chave de encriptação durante a criação do disco. Para conceder compute service agent autorização relevante para aceder à chave, use as instruções descritas na documentação do Backup for GKE acerca da ativação da encriptação CMEK.

7. Reveja os eventos do GKE no espaço de nomes PersistentVolumeClaim, que fornecem mensagens de erro detalhadas do controlador PersistentVolume ou do controlador CSI, executando o comando kubectl get events:

   kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'
   

   Substitua NAMESPACE_NAME pelo espaço de nomes do PersistentVolumeClaim,

8. Identifique eventos relacionados com o nome PersistentVolumeClaim, que contém palavras-chave como FailedProvisioning ou ExternalProvisioning. Os eventos também podem conter erros do fornecedor de armazenamento, como pd.csi.storage.gke.io.

9. Examine os registos de discos persistentes verificando os registos de auditoria da nuvem e os registos de discos persistentes no Cloud Logging para ver se existem erros relacionados com operações de criação de discos na altura da falha.

10. Com base nas mensagens de erro geradas, resolva os seguintes problemas subjacentes:

    • Aumente as quotas de discos persistentes, se indicado, como (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Valide e corrija as autorizações de IAM.

    • Investigue e resolva problemas de rede.

    • Contacte o apoio ao cliente do Google Cloud para resolver problemas com a imagem instantânea ou o serviço de disco persistente.

    • O PersistentVolumeClaim permanece no estado Pending.

    • O processo de operação de restauro não volta a tentar automaticamente a VolumeRestore. Para resolver este problema, deve acionar uma operação de restauro para a carga de trabalho Deployment ou StatefulSet que usa o PersistentVolumeClaim afetado.

    • Use um restauro detalhado para restaurar seletivamente a carga de trabalho Deployment ou StatefulSet associada ao PersistentVolumeClaim com falha. Esta abordagem permite que os mecanismos padrão do GKE processem novamente o processo de criação e associação se o problema subjacente for corrigido.PersistentVolumeClaim Para mais informações sobre a restauração detalhada, consulte o artigo Ative a restauração detalhada.

Se o problema persistir ou a causa da falha VolumeRestore não for clara, contacte o apoio ao cliente do Google Cloud para receber assistência adicional.

Erro 200060101: falha ao concluir a operação de restauro devido ao limite de tempo de validação do volume

O erro 200060101 ocorre durante a fase de validação de volumes de uma operação de restauro quando a Cópia de segurança para o GKE deixa de aguardar porque, pelo menos, um recurso VolumeRestore, que gere o restauro de dados de um VolumeBackup, não atingiu um estado succeeded dentro do período de limite de tempo atribuído. Outros VolumeRestore recursos também podem estar incompletos.

A mensagem de erro no campo stateReason do recurso Restore mostra o primeiro recurso VolumeRestore encontrado que ainda não estava num estado succeeded quando o limite de tempo foi verificado. Inclui o nome PersistentVolumeClaim e o espaço de nomes do destino para esse VolumeRestore> específico, por exemplo:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]

A Cópia de segurança do GKE inicia VolumeRestore recursos para aprovisionar PersistentVolumes a partir de VolumeBackups. O erro indica que a criação do disco persistente subjacente a partir da imagem instantânea e a associação subsequente do PersistentVolumeClaim ao PersistentVolume demoraram mais tempo do que o limite de tempo calculado para o VolumeRestore citado. Outros VolumeRestores para a mesma operação de restauro também podem estar num estado não concluído.

Embora o limite de tempo tenha sido atingido na perspetiva da cópia de segurança do GKE, o processo de criação do disco subjacente para o recurso VolumeRestore mencionado e, potencialmente, os recursos VolumeRestore, pode ainda estar em curso ou ter falhado.

Para resolver este problema, siga estas instruções:

1. Identifique o nome e o espaço de nomes com tempo limite excedido na mensagem de erro, por exemplo, (PVC: PVC_NAMESPACE/PVC_NAME).PersistentVolumeClaim

2. Apresente uma lista de todos os VolumeRestores associados à operação de restauro para ver os respetivos estados atuais executando o comando gcloud beta container backup-restore volume-restores list:

   gcloud beta container backup-restore volume-restores list \
   --project=PROJECT_ID \
   --location=LOCATION \
   --restore-plan=RESTORE_PLAN_NAME \
   --restore=RESTORE_NAME
   

   Substitua o seguinte:

   • PROJECT_ID: o ID do Google Cloud projeto.

   • LOCATION: a Google Cloud localização do restauro.

   • RESTORE_PLAN_NAME: o nome do plano de restauro.

   • RESTORE_NAME: o nome da operação de restauro.

3. Localize VolumeRestores que não estejam num estado succeeded.

4. Obtenha detalhes sobre o VolumeRestore mencionado no erro e qualquer outro VolumeRestores que não esteja num estado succeeded executando o comando gcloud beta container backup-restore volume-restores describe:

   gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
   --project=PROJECT_ID \
   --location=LOCATION \
   --restore-plan=RESTORE_PLAN_NAME \
   --restore=RESTORE_NAME
   

   Substitua o seguinte:

   • VOLUME_RESTORE_ID: o ID do recurso VolumeRestore.

   • PROJECT_ID: o ID do seu projeto Google Cloud .

   • LOCATION: a Google Cloud localização do restauro.

   • RESTORE_PLAN_NAME: o nome do plano de restauro.

   • RESTORE_NAME: o nome da operação de restauro.

5. Verifique os campos state e stateMessage. O valor do campo state é provavelmente creating ou restoring. O campo stateMessage pode fornecer mais contexto e conter os detalhes do PersistentVolumeClaim alvo.

6. Examine o estado do alvo identificado PersistentVolumeClaims executando o comando kubectl get pvc:

   kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml
   

   Substitua o seguinte:

   • PVC_NAME: o nome do PersistentVolumeClaim.

   • PVC_NAMESPACE: o espaço de nomes do elemento PersistentVolumeClaim.

   O valor de PersistentVolumeClaim's status.phase é provavelmente Pending. Verifique a secção Events para corrigir os seguintes erros:

   • Waiting for first consumer to be created before binding: indica que o StorageClass tem volumeBindingMode: WaitForFirstConsumer.

     O aprovisionamento do PersistentVolume é atrasado até que seja criado e agendado um Pod que use o PersistentVolumeClaim. O problema pode estar relacionado com a Podprogramação e não com o aprovisionamento de volume propriamente dito. Por conseguinte, recomendamos que confirme o motivo pelo qual os Pods que consomem os PersistentVolumeClaim não estão a ser agendados ou não estão a ser iniciados.

   • FailedProvisioning ou erros do fornecedor de armazenamento: Por exemplo, pd.csi.storage.gke.io.

7. Reveja os eventos do GKE nos namespaces relevantes executando o comando kubectl get events:

   kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'
   

   Substitua PVC_NAMESPACE pelo espaço de nomes do PersistentVolumeClaim.

   Procure eventos relacionados com os nomes PersistentVolumeClaim, como mensagens ou erros de aprovisionamento.

8. Verifique os registos de auditoria do Cloud e os registos do disco persistente no Cloud Logging.

9. Monitorize o estado de todos os VolumeRestores nos estados creating e restoring.

   Depois de o problema ser corrigido, o estado do VolumeRestores pode transitar para os estados succeeded ou failed. Se o VolumeRestores atingir um estado succeeded, o PersistentVolumeClaims deve tornar-se Bound e as cargas de trabalho devem estar funcionais. Se qualquer VolumeRestore entrar num estado failed, tem de realizar passos de resolução de problemas para resolver o erro de validação de volume. Para mais informações, consulte o artigo Erro 200060102: falha ao concluir a operação de restauro devido a um erro de validação do volume

Se VolumeRestores permanecer nos estados creating ou restoring durante um período excessivo, contacte o apoio ao cliente do Google Cloud para receber assistência adicional.

O que se segue?

• Leia a página de vista geral dos códigos de erro da Cópia de segurança do GKE para operações de cópia de segurança falhadas.