Ativar o modo permissivo em um plano de backup

Nesta página, explicamos como ativar o modo permissivo em um plano de backup.

Durante a execução do backup, se o Backup para GKE detectar condições que provavelmente vão causar falha na restauração, o backup vai falhar. O motivo da falha é fornecido no campo state_reason do backup. No console do Google Cloud , esse campo é chamado de Motivo do status.

Sobre o modo permissivo

Quando falhas de backup não são aceitáveis e não é possível resolver os problemas subjacentes, você pode ativar o modo permissivo. O modo permissivo garante que os backups sejam concluídos com êxito, mesmo que recursos do GKE que possam causar falhas na restauração sejam detectados durante o processo de backup. Os detalhes sobre os problemas são fornecidos no campo Motivo do status do backup.

Recomendamos usar essa opção apenas se você entender os problemas e puder implementar soluções alternativas durante o processo de restauração. Para conferir uma lista de possíveis mensagens de erro no campo Motivo do status do backup com ações recomendadas, consulte Resolver problemas de falhas de backup.

Ative o modo permissivo

Use as instruções a seguir para ativar o modo permissivo:

gcloud

Para ativar o modo permissivo, execute o comando gcloud beta container backup-restore backup-plans update:

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

Substitua:

Console

Use as instruções a seguir para ativar o modo permissivo no console doGoogle Cloud :

  1. No console Google Cloud , acesse a página Google Kubernetes Engine.

    Acessar o Google Kubernetes Engine

  2. No menu de navegação, clique em Backup para o GKE.

  3. Clique na guia Planos de backup.

  4. Expanda o cluster e clique no nome do plano.

  5. Clique na guia Detalhes para editar os detalhes do plano.

  6. Clique em Editar para editar a seção com o Modo de backup.

  7. Clique na caixa de seleção Modo permissivo e em Salvar alterações.

Terraform

Atualize o recurso google_gke_backup_backup_plan atual.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

Substitua:

  • NAME: o nome do google_gke_backup_backup_plan que você queratualizar.

Para mais informações, consulte gke_backup_backup_plan.

Resolver problemas de falha no backup

Confira na tabela a seguir as explicações e ações recomendadas para várias mensagens de falha do backup exibidas no campo Motivo do status do backup.

Mensagem de falha no backup Descrição da mensagem e motivo da falha Ação recomendada

CustomResourceDefinitions "..." have invalid schemas

Descrição: uma definição de recurso personalizada (CRD, na sigla em inglês) no cluster foi aplicada originalmente como apiextensions.k8s.io/v1beta1 e não tem um esquema estrutural obrigatório no apiextensions.k8s.io/v1.

Motivo: o Backup para GKE não pode definir automaticamente o esquema estrutural. Restaurando a CRD nos clusters do Kubernetes v1.22+, em que apiextensions.k8s.io/v1beta1 não está disponível causa falha na restauração. Essa falha ocorre ao restaurar recursos personalizados definidos pela CRD. 		Recomendamos que você use as seguintes opções:
  • Se ela for uma CRD gerenciada pelo GKE, será possível chamar kubectl delete crd caso não haja recursos veiculados pela CRD. Se houver recursos veiculados pela CRD, será possível ativar o modo permissivo com uma compreensão do comportamento de restauração. Para as recomendações sobre CRDs comuns, consulte a documentação.
  • Se for uma CRD de terceiros, consulte a documentação relevante para migrar para apiextensions.k8s.io/v1.
.
Quando o modo permissivo está ativado, o backup da CRD sem um esquema estrutural não será feito em um cluster do Kubernetes v1.22+. Para restaurar esse backup, exclua os recursos veiculados pela CRD da restauração ou crie a CRD no cluster de destino antes de iniciar a restauração.

Failed to query API resources ...

Descrição: um serviço de API no cluster está configurado incorretamente. Isso faz com que as solicitações feitas ao caminho da API retornem a mensagem "Falha ao consultar recursos da API". O serviço subjacente pode não existir ou não está pronto.

Motivo: o Backup para GKE não pode fazer backup de nenhum recurso veiculado pela API indisponível. 		Verifique o serviço subjacente no console spec.service para conferir se ele está pronto.

Quando o modo permissivo está ativado, os recursos dos grupos de APIs que apresentam falha ao carregar não terão o backup realizado.

Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs

Descrição: no Kubernetes v1.23 e versões anteriores, as contas de serviço geram automaticamente um token com um secret. No entanto, em versões mais recentes, o Kubernetes removeu esse recurso de token gerado automaticamente. Um pod no cluster pode ter adicionado o volume do secret no sistema de arquivo dos contêineres.

Motivo: se o Backup para GKE tentar restaurar uma conta de serviço com o secret gerado automaticamente e um pod que adiciona o volume do secret, a restauração aparenta ter sido concluída. No entanto, O Kubernetes remove o secret, o que faz com que o pod fique preso na criação do contêiner e apresente falha ao iniciar. 		Defina o campo spec.serviceAccountName no pod. Esta ação garante que o token seja adicionado automaticamente no /var/run/secrets/kubernetes.io/serviceaccount nos contêineres. Para mais informações, consulte a documentação Configurar contas de serviço para pods .

Quando o modo permissivo está ativado, o backup do secret vai ser feito, mas não poderá ser adicionado em pods nos clusters do Kubernetes v1.24+.

Definições de recursos personalizados (CRDs) comuns com problemas e ações recomendadas

Confira algumas CRDs comuns com problemas de backup e as ações recomendadas para resolver os problemas:

  • capacityrequests.internal.autoscaling.k8s.io: Esta CRD foi usada temporariamente nos clusters v1.21. Execute kubectl delete crd capacityrequests.internal.autoscaling.k8s.io para remover a CRD.
  • scalingpolicies.scalingpolicy.kope.io: esta CRD era usada para controlar recursos fluentd, mas o GKE migrou para o fluentbit. Execute kubectl delete crd scalingpolicies.scalingpolicy.kope.io para remover a CRD.
  • memberships.hub.gke.io: execute kubectl delete crd memberships.hub.gke.io para remover o CRD, se não houver recursos de assinatura. Ativar o modo permissivo se houver recursos de assinatura.
  • applications.app.k8s.io: ativar o modo permissivo com uma compreensão do comportamento de restauração.