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

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 espaço de nomes estarem totalmente num 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 usar 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.

  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 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 através do 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 usar 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.

  3. Resolva o problema subjacente no cluster de destino. A ação correta depende do erro específico. No exemplo, se existir um HorizontalPodAutoscaler em 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 automático 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: use 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. Valide a eliminação através do comando kubectl get:

    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 através do comando kubectl get events:

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

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

  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.

O que se segue?