Resolver erros de permissão no Backup para GKE

Este documento descreve os erros e os códigos correspondentes que podem ocorrer ao usar o Backup para GKE para realizar operações de restauração. Cada seção inclui considerações sobre como realizar ações para resolver os erros de restauração e instruções sobre como resolver os erros da operação de restauração.

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

O erro 200010301 ocorre quando uma tentativa de concluir uma operação de restauração falha porque um serviço de webhook de admissão, também chamado de callback HTTP, está indisponível, o que resulta na seguinte mensagem de erro. A mensagem de erro indica que o servidor da API do GKE tentou entrar em contato com um webhook de admissão ao tentar restaurar um recurso, mas o serviço que apoia 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.

Esse 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 acessar o endpoint configurado no webhook. Os webhooks de admissão interceptam solicitações ao servidor da API do GKE, e a configuração deles especifica como o servidor da API do GKE precisa consultar as solicitações.

O clientConfig do webhook especifica o back-end que processa as solicitações de admissão, que pode ser um serviço de cluster interno ou um URL externo. A escolha entre essas duas opções depende dos requisitos operacionais e arquitetônicos específicos do seu webhook. Dependendo do tipo de opção, a operação de restauração pode ter falhado pelos seguintes motivos:

  • Serviços no cluster: o serviço do GKE e os pods de suporte não são restaurados nem ficam prontos quando o servidor da API do GKE tenta chamar o webhook. Isso ocorre durante operações de restauração em que as configurações de webhook no escopo do cluster são aplicadas antes que os serviços no namespace estejam totalmente no estado ready.

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

Para resolver esse 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 identificado na mensagem de erro.

    Você 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 identificado na mensagem de erro.

  3. Siga estas etapas de solução de problemas com base no tipo de configuração:

    Baseado em serviço clientConfig

    Defina uma ordem de restauração personalizada modificando o recurso RestorePlan para incluir um RestoreOrder com entradas GroupKindDependency. Isso permite que os componentes que dão suporte ao webhook, como Deployment, StatefulSet ou Service, sejam restaurados e fiquem prontos antes do ValidatingWebhookConfiguration ou MutatingWebhookConfiguration.

    Para instruções sobre como definir uma ordem de restauração personalizada, consulte Especificar a ordem de restauração de recursos durante a restauração.

    Essa abordagem pode falhar porque os pods do serviço não entram em um estado totalmente ready, mesmo depois que o objeto Service é criado. Outro motivo para a falha é que a configuração do webhook pode ser criada inesperadamente por outro aplicativo. Como alternativa, você pode fazer uma operação de restauração em duas etapas seguindo estas etapas:

    1. Crie um recurso Restore usando o backup ao configurar a operação de restauração com um filtro refinado que inclui 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 detalhado, consulte Ativar a restauração detalhada.

    2. Crie outro recurso Restore para a operação de backup e configure o restante dos recursos escolhidos.

    clientConfig com base em URL

    1. Verifique se o endpoint HTTPS externo está ativo, acessível e funcionando corretamente.

    2. Confirme se há conectividade de rede dos nós e do plano de controle do cluster do GKE para o URL externo. Talvez seja necessário verificar as regras de firewall, por exemplo, se você estiver usando a nuvem privada virtual, no local ou um provedor de nuvem que hospede o webhook, as políticas de rede e a resolução de DNS.

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

Erro 200010302: falha ao concluir a operação de restauração devido a uma solicitação de criação de recurso negada

O erro 200010302 ocorre quando uma tentativa de concluir uma operação de restauração falha porque um webhook de admissão nega uma solicitação de criação de recurso, o que resulta na seguinte mensagem de erro indicando que um recurso do seu backup não pôde ser criado no cluster de destino porque um webhook de admissão ativo interceptou e rejeitou a solicitação com base em uma 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}

Esse erro é causado pelo conjunto de configurações no cluster de destino do GKE, que tem um ValidatingAdmissionWebhook ou MutatingAdmissionWebhook que impõe regras específicas à criação e modificação de recursos, bloqueando a solicitação de criação de recursos. Por exemplo, um webhook impede a criação de um recurso porque um recurso relacionado, mas conflitante, já existe no cluster. Por exemplo, um webhook pode negar a criação de uma implantação se ela já for gerenciada por um recurso da API HorizontalPodAutoscaler do GKE.

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

  1. Identifique o webhook que está negando a solicitação usando a mensagem de erro que ocorre quando a operação de restauração 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 nega a solicitação.

    • Motivo da recusa: o motivo específico para negar a solicitação.

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

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

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

    Também é possível executar o comando kubectl get mutatingwebhookconfigurations para inspecionar o webhook:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

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

  3. Resolva o problema subjacente no cluster de destino. A ação correta depende do erro específico. Por exemplo, se houver um conflito de HorizontalPodAutoscaler, exclua o HorizontalPodAutoscaler existente no cluster de destino antes de executar a restauração para permitir a criação das cargas de trabalho em backup e dos recursos associados.

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

Erro 200060202: falha ao concluir a operação de restauração 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 restauração quando um recurso do GKE que o Backup para GKE espera validar não é encontrado no cluster de destino, resultando na seguinte mensagem de erro:

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

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

Esse erro ocorre quando o Backup para GKE cria ou atualiza o recurso do GKE como parte do processo da operação de restauração, mas quando a etapa de validação começa, um ou mais recursos do GKE não estão mais presentes no cluster de destino porque foram excluídos após a criação ou atualização inicial pelo processo de restauração, mas antes da conclusão da validação da carga de trabalho para o recurso do GKE. Esse erro pode ocorrer pelos seguintes motivos:

  • Exclusão manual: um usuário ou administrador excluiu manualmente o recurso usando kubectl ou outras ferramentas Google Cloud .

  • Automação externa: controladores GitOps, como Config Sync, ArgoCD, Flux, scripts personalizados ou outras ferramentas de gerenciamento de cluster reverteram ou excluíram o recurso para corresponder a um estado desejado em um repositório.

  • Controladores do GKE: um controlador do GKE excluiu um recurso porque ele entra em conflito com outros recursos ou políticas, ou uma cadeia OwnerReference leva à coleta de lixo, ou o processo de limpeza automatizado do GKE que exclui recursos dependentes quando o recurso owner é excluído.

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

  1. Identifique o recurso ausente usando a mensagem de erro que aparece quando a operação de restauração não é concluída.

  2. Localize o namespace a que o recurso pertence usando um dos seguintes métodos:

    • Registros de auditoria do GKE: examine os registros de auditoria do GKE gerados quando você tentou fazer a operação de restauração. É possível filtrar registros de operações de exclusão nos recursos Kind e Name. A entrada de registro de auditoria contém o namespace original.

    • Detalhes do backup: revise o escopo da operação de restauração e o conteúdo do backup. O índice de backup mostra o namespace original do recurso. Também é possível verificar se o RestorePlan contém um TransformationRule que especifica regras para restaurar o recurso no namespace escolhido.

    • Pesquisar em namespaces: execute o comando kubectl get para pesquisar o recurso em todos os namespaces:

      kubectl get KIND --all-namespaces | grep NAME

      Substitua KIND e NAME pelos valores da mensagem de erro. Se o recurso ainda existir, esse comando vai mostrar o namespace dele.

  3. Para verificar a exclusão, execute o comando kubectl get:

    kubectl get KIND NAME -n [NAMESPACE]

    Substitua KIND e NAME pelos valores da mensagem de erro. Você vai receber uma mensagem de erro not found.

  4. Investigue a causa da exclusão usando um dos seguintes métodos:

    • Registros de auditoria do GKE: identificam qual entidade emitiu a solicitação de exclusão. Por exemplo, o usuário, a conta de serviço ou o controlador.

    • Analise as automações configuradas: se você usa o GitOps ou outras ferramentas de automação, verifique os registros e o status delas para saber se houve interferência nos recursos restaurados.

    • Examinar eventos relacionados: verifique os eventos do GKE no namespace determinado executando o comando kubectl get events:

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

      Substitua NAMESPACE_NAME pelo nome do namespace.

  5. Resolva a causa da exclusão do recurso com base nos resultados da etapa anterior. Por exemplo, pausar automações conflitantes, corrigir configurações incorretas ou ajustar as permissões de usuário.

  6. Recupere o recurso ausente usando um dos seguintes métodos:

    • Reaplicar arquivos de manifesto: se você tiver o manifesto do recurso ausente, poderá reaplicá-lo ao namespace correto.

    • Faça uma restauração detalhada: execute uma operação de restauração detalhada para restaurar seletivamente apenas o recurso ausente do mesmo backup, o que garante que você especifique o namespace correto. Para mais informações sobre como realizar uma operação de restauração refinada, consulte Ativar a restauração refinada.

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

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

O erro 200060201 ocorre quando uma ou mais cargas de trabalho restauradas não se tornam totalmente ready durante uma operação de restauração dentro do limite de tempo esperado após a criação dos recursos no cluster, resultando na seguinte mensagem de erro:

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

Esse erro ocorre porque o Backup para GKE realiza uma etapa de validação após restaurar as configurações de recursos do GKE para garantir que as cargas de trabalho críticas estejam funcionando corretamente. O Backup para GKE aguarda que determinadas cargas de trabalho atinjam um estado ready, mas pelo menos uma carga de trabalho não atendeu ao seguinte critério de prontidão dentro do período de tempo limite alocado:

  • 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 esse erro, siga estas instruções:

  1. Identifique as cargas de trabalho que não estão no estado ready na mensagem de erro que lista as cargas de trabalho e os namespaces que não entraram no estado ready.

  2. Inspecione o status da carga de trabalho e receba detalhes e eventos das cargas de trabalho com falha 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:

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

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

    • NAMESPACE_NAME: o namespace em que a carga de trabalho está localizada.

    • SELECTOR_FOR_WORKLOAD: o seletor de rótulo 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 status de pods individuais executando o comando kubectl describe pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Substitua:

    • POD_NAME: o nome do pod específico.

    • NAMESPACE_NAME: o namespace em que o pod está localizado.

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

    • ImagePullBackOff / ErrImagePull: indica que há problemas ao buscar imagens de contêiner.

    • CrashLoopBackOff: indica que os contêineres estão sendo iniciados e falhando.

  4. Na seção Containers, analise os registros de contêiner na saída describe para encontrar o nome do contêiner executando o comando kubectl logs:

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Substitua:

    • POD_NAME: o nome do pod específico.

    • NAMESPACE_NAME: o namespace em que o pod está localizado.

    • CONTAINER_NAME: o nome do contêiner dentro do pod.

    De acordo com a saída describe, há vários motivos para o pod não aparecer na saída de recursos, incluindo:

    • Falhas na sondagem de prontidão: as sondagens de prontidão do contêiner não estão sendo concluídas.

    • Problemas de recursos: não há CPU, memória ou outros recursos suficientes no cluster ou os limites de cota estão sendo atingidos.

    • Problemas com contêineres de inicialização: falhas em contêineres de inicialização que impedem a inicialização dos contêineres principais.

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

    • Problemas de rede: os Pods não conseguem se comunicar com os serviços necessários.

  5. Verifique os recursos do cluster do GKE para garantir que ele tenha capacidade de nó, CPU e memória suficientes para executar as cargas de trabalho restauradas. Nos clusters do Autopilot, o provisionamento automático de nós pode levar mais tempo. Por isso, recomendamos verificar se há limitações ou erros de escalonamento de nós. Resolva os problemas subjacentes com base nas suas descobertas e impeça que as cargas de trabalho entrem em um estado ready. Essa abordagem pode envolver a correção de manifestos, o ajuste de solicitações ou limites de recursos, a correção de políticas de rede ou a garantia de que as dependências sejam atendidas.

  6. Depois que os problemas forem resolvidos, aguarde as cargas de trabalho entrarem em um estado ready. Não é necessário executar a operação de restauração novamente.

Se o problema persistir, entre em contato com o Cloud Customer Care para receber mais ajuda.

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

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

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 lista os nomes completos dos recursos do VolumeRestore com falha, incluindo o nome e o namespace do PersistentVolumeClaim de destino. A mensagem de erro indica que o processo de restauração de dados do PersistentVolumeClaim afetado não foi concluído com êxito quando o Backup para GKE iniciou recursos VolumeRestore para provisionar PersistentVolumes de VolumeBackups, e a criação do Persistent Disk subjacente do snapshot falhou. As falhas de VolumeRestore podem ocorrer pelos seguintes motivos:

  • Cota insuficiente: não há cota de Persistent Disk alocada suficiente no projeto ou na região, por exemplo, SSD_TOTAL_GB.

  • Problemas de permissão: a conta de serviço usada pelo Backup para GKE não tem as permissões necessárias para criar discos ou acessar snapshots.

  • Problemas de rede: há problemas de rede temporários ou persistentes que interrompem o processo de criação do disco.

  • Snapshot inválido: a origem VolumeBackup ou o snapshot do Persistent Disk subjacente está corrompido ou inacessível.

  • Restrições de recursos: outras restrições de recursos do cluster estão dificultando o provisionamento de volume.

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

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

  1. Identifique o PersistentVolumeClaims com falha listado na mensagem de erro, que mostra os nomes completos dos recursos dos objetos VolumeRestore que falharam.

  2. Para conferir detalhes de cada recurso VolumeRestore com falha, execute 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:

    • VOLUME_RESTORE_ID: o ID do recurso VolumeRestore com falha.

    • PROJECT_ID: o ID do seu projeto Google Cloud .

    • LOCATION: o Google Cloud local da restauração.

    • RESTORE_PLAN_ID: o ID do plano de restauração.

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

  3. Analise os campos state e stateMessage na saída para detalhes sobre a falha.

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

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Substitua:

    • PVC_NAME: o nome do recurso PersistentVolumeClaim.

    • NAMESPACE_NAME: o namespace em que o PersistentVolumeClaim está localizado.

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

  6. Inspecione a seção Events na saída YAML em busca de mensagens relacionadas a falhas de provisionamento, 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).

    A saída indica que há um problema de permissão ao acessar a chave de criptografia durante a criação do disco. Para fornecer a permissão relevante para acessar a chave, siga as instruções descritas na documentação do Backup para GKE sobre como ativar a criptografia CMEK.compute service agent

  7. Analise os eventos do GKE no namespace PersistentVolumeClaim, que fornecem mensagens de erro detalhadas do controlador PersistentVolume ou do driver CSI, executando o comando kubectl get events:

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

    Substitua NAMESPACE_NAME pelo namespace do PersistentVolumeClaim,

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

  9. Examine os registros do disco permanente verificando os registros de auditoria do Cloud e do Persistent Disk no Cloud Logging em busca de erros relacionados às operações de criação de disco no momento da falha.

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

    • Aumente as cotas de disco permanente, se indicado, como (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • Verifique e corrija as permissões do IAM.

    • Investigue e resolva problemas de rede.

    • Entre em contato com o Cloud Customer Care para resolver problemas com o snapshot ou o serviço Persistent Disk.

    • O PersistentVolumeClaim permanece no estado Pending.

    • O processo de operação de restauração não tenta novamente o VolumeRestore automaticamente. Para resolver isso, acione uma operação de restauração para a carga de trabalho Deployment ou StatefulSet que usa o PersistentVolumeClaim afetado.

    • Use uma restauração refinada para restaurar seletivamente a carga de trabalho Deployment ou StatefulSet associada ao PersistentVolumeClaim com falha. Essa abordagem permite que os mecanismos padrão do GKE processem novamente a criação e a vinculação de PersistentVolumeClaim se o problema subjacente for corrigido. Para mais informações sobre a restauração refinada, consulte Ativar a restauração refinada.

Se o problema persistir ou a causa da falha VolumeRestore não estiver clara, entre em contato com o Cloud Customer Care para receber mais ajuda.

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

O erro 200060101 ocorre durante a fase de validação de volume de uma operação de restauração quando o Backup para GKE para de esperar porque pelo menos um recurso VolumeRestore, que gerencia a restauração de dados de um VolumeBackup, não atingiu um estado succeeded dentro do período de tempo limite alocado. Outros recursos VolumeRestore 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 no estado succeeded quando o tempo limite foi verificado. Ele inclui o nome e o namespace PersistentVolumeClaim de 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)]

O Backup para GKE inicia recursos VolumeRestore para provisionar PersistentVolumes de VolumeBackups. O erro indica que a criação do Persistent Disk subjacente do snapshot e a vinculação subsequente do PersistentVolumeClaim ao PersistentVolume levaram mais tempo do que o tempo limite calculado para o VolumeRestore citado. Outros VolumeRestores para a mesma operação de restauração também podem estar em um estado não concluído.

Mesmo que o tempo limite tenha sido atingido do ponto de vista do Backup para GKE, o processo de criação de disco para o recurso VolumeRestore mencionado e, possivelmente, para recursos VolumeRestore, ainda pode estar em andamento ou ter falhado.

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

  1. Identifique o nome e o namespace PersistentVolumeClaim com tempo esgotado na mensagem de erro, por exemplo, (PVC: PVC_NAMESPACE/PVC_NAME).

  2. Liste todos os VolumeRestores associados à operação de restauração para conferir os estados atuais deles 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:

    • PROJECT_ID: o ID do projeto Google Cloud .

    • LOCATION: o Google Cloud local da restauração.

    • RESTORE_PLAN_NAME: o nome do plano de restauração.

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

  3. Localize VolumeRestores que não estão no estado succeeded.

  4. Para conferir detalhes sobre o VolumeRestore mencionado no erro e qualquer outro VolumeRestores que não esteja no estado succeeded, execute 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:

    • VOLUME_RESTORE_ID: o ID do recurso VolumeRestore.

    • PROJECT_ID: o ID do seu projeto Google Cloud .

    • LOCATION: o Google Cloud local da restauração.

    • RESTORE_PLAN_NAME: o nome do plano de restauração.

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

  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 de destino.

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

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Substitua:

    • PVC_NAME: o nome do PersistentVolumeClaim.

    • PVC_NAMESPACE: o namespace do PersistentVolumeClaim.

    O valor do status.phase PersistentVolumeClaim's provavelmente será Pending. Verifique se há os seguintes erros na seção Events:

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

      O provisionamento do PersistentVolume é adiado até que um Pod que usa o PersistentVolumeClaim seja criado e programado. O problema pode estar no agendamento de Pod, não no provisionamento de volume em si. Portanto, recomendamos confirmar por que o Pods que consome o PersistentVolumeClaim não está sendo programado ou iniciado.

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

  7. Analise 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 namespace do PersistentVolumeClaim.

    Procure eventos relacionados aos nomes PersistentVolumeClaim, como mensagens ou erros de provisionamento.

  8. Verifique os registros de auditoria do Cloud e do Persistent Disk no Cloud Logging.

  9. Monitore o status de todos os VolumeRestores nos estados creating e restoring.

    Depois que o problema for corrigido, o status do VolumeRestores poderá passar para os estados succeeded ou failed. Se o VolumeRestores atingir um estado succeeded, o PersistentVolumeClaims vai se tornar Bound e as cargas de trabalho vão funcionar. Se algum VolumeRestore entrar em um estado failed, siga as etapas de solução de problemas para resolver o erro de validação de volume. Para mais informações, consulte Erro 200060102: falha ao concluir a operação de restauração devido a um erro de validação de volume.

Se VolumeRestores permanecer nos estados creating ou restoring por um período excessivo, entre em contato com o Cloud Customer Care para receber mais ajuda.

A seguir