Resolver problemas de erros do sistema no Backup para GKE

Nesta página, descrevemos os erros relacionados ao sistema que podem ocorrer ao usar o Backup para GKE, o que considerar ao fazer backup de recursos e as etapas para a solução de problemas.

Erro 100010108: falha ao fazer backup de PersistentVolumeClaim. Falta a CMEK do plano de backup para o disco criptografado.

O erro 100010108 ocorre ao criar backups de volume com escopo regional, e a CMEK do plano de backup é obrigatória porque o cluster do GKE faz referência a um disco criptografado.

Entender o erro

Ao criar backups de volume com escopo regional, a CMEK do plano de backup é obrigatória se o cluster do GKE fizer referência a um disco criptografado. Esse é um requisito estrito para backups de volume com escopo regional. Se o disco de origem estiver criptografado, só será possível criar o snapshot dele se uma CMEK do plano de backup for fornecida. Se o plano de backup não tiver essa configuração de CMEK, a criação do snapshot vai falhar, e você vai receber uma mensagem de erro semelhante a esta:

failed to create snapshot as disk "pvc-1" is encrypted with CMEK "projects/proj1/locations/us-east1/keyRings/keyring1/cryptoKeys/key1/cryptoKeyVersions/1", but no Backup Plan CMEK is provided. Please add CMEK to the Backup Plan.

Etapas da solução de problemas

  1. Identifique a configuração de CMEK ausente: a mensagem de erro confirma que o PVC que está sendo armazenado em backup está criptografado, mas a configuração do plano de backup não tem uma chave de criptografia.
  2. Adicionar uma CMEK ao plano de backup: atualize a configuração do plano de backup para incluir uma chave de criptografia gerenciada pelo cliente (CMEK). Essa chave será usada para criptografar os dados de backup, incluindo os backups de volume no escopo regional.
  3. Verifique se as permissões estão corretas: confira se o agente de serviço do Backup para GKE (service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com) tem o papel roles/cloudkms.cryptoKeyEncrypterDecrypter atribuído à CMEK recém-adicionada.
  4. Teste novamente a operação de backup: depois que o plano de backup for atualizado com a CMEK e as permissões forem concedidas, tente realizar a operação de backup novamente.

Erro 100020102: CustomResourceDefinition - tem um esquema inválido - versão da API v1beta1 não compatível

O erro 100020102 ocorre quando uma tentativa de fazer backup de um CustomResourceDefinition que foi originalmente aplicado como uma versão apiextensions.k8s.io/v1beta1 falha porque não tem o esquema estrutural necessário na versão da API apiextensions.k8s.io/v1. Esse erro resulta na seguinte mensagem de erro: CustomResourceDefinition - has an invalid schema. The resource was originally applied as v1beta1, which has been removed from Kubernetes 1.22+.

Esse erro ocorre porque a versão da API apiextensions.k8s.io/v1beta1 foi removida no Google Kubernetes Engine versão 1.22. Para mais informações sobre a remoção da API na versão 1.22 do GKE, consulte Remoções de API para o GKE v1.22.

Comportamento da operação de backup no modo não permissivo

No modo não permissivo ou em um plano de backup estrito, a operação de backup falha se encontrar um recurso que não pode ser armazenado em backup, como um CustomResourceDefinition criado com a API v1beta1. Esse erro ocorre porque o recurso não tem o esquema estrutural exigido pela API v1. A presença desse CustomResourceDefinition é considerada um erro crítico porque pode não ser restaurado corretamente em um cluster mais recente.

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

  1. Identifique o CustomResourceDefinition problemático executando o comando kubectl get crd:

    kubectl get crd CRD_NAME

    Substitua CRD_NAME pelo nome do CustomResourceDefinition na mensagem de erro.

  2. Na saída YAML, confirme se o CustomResourceDefinition foi convertido corretamente da API vbeta1 para a API v1 localizando as seguintes condições:

    1. spec.versions: localize a condição spec.versions analisando cada versão listada no campo spec.versions. Se algum dos spec.versions não tiver o campo schema.openAIV3Schema, o CustomResourceDefinition não terá um esquema estrutural definido para essa versão.

    2. status.conditions: localize a condição status.conditions encontrando a condição type:NonStructuralSchema. Se o status do status.conditions for true, isso confirma explicitamente que o esquema não é estrutural.

  3. Faça upgrade da versão da API CustomResourceDefinition para v1 seguindo estas etapas:

    1. Edite o CustomResourceDefinition atual para torná-lo compatível com o padrão v1 adicionando um esquema estrutural que define cada campo e o tipo dele no recurso personalizado. Para mais informações sobre como adicionar um esquema estrutural, consulte Como especificar um esquema estrutural.

    2. Aplique o manifesto v1 compatível ao cluster.

  4. Se o upgrade for concluído, tente fazer o backup novamente. Caso contrário, use um dos seguintes métodos para resolver o problema:

    • Exclua o CustomResourceDefinition executando o comando kubectl delete crd se o CustomResourceDefinition não estiver sendo usado no cluster.

      kubectl delete crd CRD_NAME

      Substitua CRD_NAME pelo nome do CustomResourceDefinitionque você quer excluir.

    • Ative o modo permissivo no plano de backup, que permite que o Backup para GKE pule o recurso, incluindo CustomResourceDefinitions na versão da API v1beta1, e continue com o restante da operação de backup. Para saber mais sobre como ativar o modo permissivo, consulte Ativar o modo permissivo em um plano de backup.

  5. Tente fazer o backup de novo. Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100020103: falha ao consultar recursos da API

O erro 100020103 ocorre quando o Backup para GKE não consegue descobrir serviços de API do Kubernetes personalizados ou agregados antes de fazer um backup, resultando em uma mensagem de erro que informa Failed to query API resources. Please check if any API service is unavailable by using 'kubectl get apiservice'. Isso acontece se um serviço de API agregado estiver mal configurado ou se os serviços e pods de suporte estiverem em mau estado ou inacessíveis. No modo não permissivo ou em um plano de backup estrito, o Backup para GKE interrompe a operação de backup se encontrar um APIService indisponível para evitar a captura de um estado de cluster incompleto ou inconsistente.

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

  1. Identifique os serviços de API indisponíveis executando o seguinte comando:

    kubectl get apiservice

    Na saída, procure serviços de API em que a coluna AVAILABLE seja False.

  2. Inspecione os detalhes do APIService com falha executando o seguinte comando:

    kubectl describe apiservice APISERVICE_NAME

    Substitua APISERVICE_NAME pelo nome do serviço de API com falha, por exemplo, v1beta1.custom.metrics.k8s.io.

    Na saída, revise o campo Service em spec.service e a seção Conditions para identificar o serviço de apoio, o namespace dele e a causa da falha (como endpoints ausentes ou uma porta de destino inacessível).

  3. Use um dos seguintes métodos para resolver o erro:

    • Restaure o serviço de apoio: verifique se o serviço de apoio tem endpoints prontos executando o seguinte comando:

      kubectl get endpoints -n NAMESPACE SERVICE_NAME

      Substitua:

      • NAMESPACE: o namespace do serviço de suporte.
      • SERVICE_NAME: o nome do serviço de apoio.

      Verifique se os pods que dão suporte ao serviço existem e estão no estado Running. Resolva as falhas de pods, de extração de imagens ou de configuração incorreta da política de rede que impedem que o tráfego chegue ao serviço de apoio.

    • Excluir um APIService órfão: se o APIService pertencer a um aplicativo, operador ou ferramenta de monitoramento que foi removida ou não está mais em uso, exclua o APIService desatualizado:

      kubectl delete apiservice APISERVICE_NAME

      Substitua APISERVICE_NAME pelo nome do serviço de API órfão.

    • Ativar o modo permissivo: se não for possível corrigir ou remover imediatamente o serviço de API indisponível, ative o modo permissivo no plano de backup. Quando o modo permissivo está ativado, o Backup para GKE continua a operação de backup. No entanto, os recursos pertencentes ao grupo de API indisponível não terão backup. Para saber como ativar o modo permissivo, consulte Ativar o modo permissivo em um plano de backup.

  4. Tente fazer o backup de novo. Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100040102: namespace não encontrado

O erro 100040102 ocorre quando uma tentativa de realizar uma operação de backup falha porque um namespace especificado no escopo do backup não pode ser encontrado no cluster. O agente do Backup para GKE não conseguiu localizar um ou mais namespaces que foram explicitamente listados no campo selectedNamespaces da configuração BackupPlan. O Backup para GKE exige que todos os namespaces especificados estejam presentes no cluster no momento em que a operação de backup é iniciada. Se o namespace não for encontrado, a seguinte mensagem de erro será exibida:

Namespace [NAMESPACE_NAME] is not found.

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

  1. Verifique se o namespace foi inserido corretamente conferindo a lista selectedNamespaces na configuração BackupPlan.

  2. Confirme se o namespace informado na mensagem de erro existe executando o comando kubectl get namespace:

    kubectl get namespace NAMESPACE_NAME

    Substitua NAMESPACE_NAME pelo nome do namespace informado na mensagem de erro.

    Se o namespace não existir, uma mensagem vai aparecer informando que ele não foi encontrado, por exemplo, Error from server (NotFound): namespaces "[NAMESPACE_NAME]" not found.

  3. Corrija o BackupPlan. Se o namespace estiver com erro de ortografia, atualize o BackupPlan com o nome correto. Se o namespace realmente não existir mais e não precisar de backup, remova-o da lista selectedNamespaces na configuração BackupPlan.

  4. Tente fazer o backup novamente depois de fazer as correções necessárias no BackupPlan e inicie um novo backup.

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

A seguir