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 apoiava 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 do GKE não consegue alcançar 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 de arquitetura 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 com escopo de cluster são aplicadas antes que os serviços com namespace estejam totalmente em um 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.

    Também é possível usar 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 usando 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 usar 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 o Config Sync, o ArgoCD, o 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 automatizada pelo 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: use 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. Verifique a exclusão usando 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 usando o comando kubectl get events:

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

      Substitua NAMESPACE 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.

A seguir