Ative o modo permissivo num plano de contingência

Esta página explica como ativar o modo permissivo num plano de backup.

Durante a execução da cópia de segurança, se a Cópia de segurança para o GKE detetar condições que provavelmente vão causar a falha do restauro, a própria cópia de segurança falha. O motivo da falha é fornecido no campo state_reason da cópia de segurança. Na Google Cloud consola, este campo é denominado Motivo do estado.

Acerca do modo permissivo

Quando as falhas de cópia de segurança não são aceitáveis e não é possível resolver os problemas subjacentes, pode ativar o modo permissivo. O modo permissivo garante que as cópias de segurança são concluídas com êxito, mesmo que sejam detetados recursos do GKE que possam causar falhas de restauro durante o processo de cópia de segurança. Os detalhes sobre os problemas são fornecidos no campo Motivo do estado da cópia de segurança.

Recomendamos que use esta opção apenas se compreender os problemas e puder implementar soluções alternativas durante o processo de restauro. Para ver uma lista de potenciais mensagens de erro no campo Motivo do estado da cópia de segurança com ações recomendadas, consulte o artigo Resolva falhas de cópia de segurança.

Ative o modo permissivo

Siga as instruções que se seguem 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 o seguinte:

Consola

Siga as instruções abaixo para ativar o modo permissivo na Google Cloud consola:

  1. Na Google Cloud consola, aceda à página Google Kubernetes Engine.

    Aceder ao Google Kubernetes Engine

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

  3. Clique no separador Planos de contingência.

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

  5. Clique no separador Detalhes para editar os detalhes do plano.

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

  7. Clique na caixa de verificação Modo permissivo e clique em Guardar alterações.

Terraform

Atualize o recurso google_gke_backup_backup_plan existente.

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

Substitua o seguinte:

  • NAME: o nome do google_gke_backup_backup_plan que quer atualizar.

Para mais informações, consulte gke_backup_backup_plan.

Resolva problemas de falhas de cópias de segurança

A tabela seguinte fornece explicações e ações recomendadas para várias mensagens de falha de cópia de segurança apresentadas no campo Motivo do estado da cópia de segurança.

Mensagem de falha da cópia de segurança Descrição da mensagem e motivo da falha Ação recomendada

CustomResourceDefinitions "..." have invalid schemas

Descrição: uma definição de recurso personalizado (CRD) no cluster foi originalmente aplicada como apiextensions.k8s.io/v1beta1 e não tem um esquema estrutural necessário em apiextensions.k8s.io/v1.

Motivo: a Cópia de segurança do GKE não consegue definir automaticamente o esquema estrutural. A restauração do CRD em clusters do Kubernetes v1.22 ou superior, onde apiextensions.k8s.io/v1beta1 não está disponível, faz com que a restauração falhe. Esta falha ocorre quando restaura recursos personalizados definidos pela CRD. 		Recomendamos que use as seguintes opções:
  • Se for um CRD gerido pelo GKE, pode chamar kubectl delete crd se não existirem recursos servidos pelo CRD. Se existirem recursos publicados pelo CRD, pode ativar o modo permissivo com uma compreensão do comportamento de restauro. Para ver recomendações sobre CRDs comuns, consulte a documentação.
  • Se for um CRD de terceiros, consulte a documentação relevante para migrar para apiextensions.k8s.io/v1.

Quando o modo permissivo está ativado, o CRD sem um esquema estrutural não é feito uma cópia de segurança num cluster do Kubernetes v1.22 ou superior. Para restaurar com êxito uma cópia de segurança deste tipo, tem de excluir os recursos publicados pelo CRD do restauro ou criar o CRD no cluster de destino antes de iniciar o restauro.

Failed to query API resources ...

Descrição: um serviço de API no cluster está mal configurado. Isto faz com que os pedidos ao caminho da API devolvam "Failed to query API resources." (Falha ao consultar recursos da API). O serviço subjacente pode não existir ou ainda não estar pronto.

Motivo: a Cópia de segurança do GKE não consegue fazer uma cópia de segurança de recursos publicados pela API indisponível. 		Verifique o serviço subjacente no spec.service do serviço de API para se certificar de que está pronto.

Quando o modo permissivo está ativado, não é feito uma cópia de segurança dos recursos dos grupos de APIs que não foram carregados.

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

Descrição: no Kubernetes v1.23 e anterior, as contas de serviço geram automaticamente um token suportado por um segredo. No entanto, nas versões posteriores, o Kubernetes removeu esta funcionalidade de token gerado automaticamente. A Um pod no cluster pode ter montado o volume secreto no sistema de ficheiros dos respetivos contentores.

Motivo: se a cópia de segurança para o GKE tentar restaurar uma conta de serviço juntamente com o respetivo segredo gerado automaticamente e um pod que monte o volume secreto, o restauro parece ser bem-sucedido. No entanto, o Kubernetes remove o segredo, o que faz com que o pod fique bloqueado na criação do contentor e não seja iniciado. 		Defina o campo spec.serviceAccountName no Pod. Esta ação garante que o token é montado automaticamente em /var/run/secrets/kubernetes.io/serviceaccount nos contentores. Para mais informações, consulte a documentação Configure contas de serviço para pods.

Quando o modo permissivo está ativado, o segredo é copiado de segurança, mas não pode ser montado em pods em clusters do Kubernetes v1.24 ou superior.

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

Seguem-se alguns CRDs comuns que têm problemas de cópia de segurança e as ações que recomendamos para resolver os problemas:

  • capacityrequests.internal.autoscaling.k8s.io: Este CRD foi usado temporariamente em clusters v1.21. Execute kubectl delete crd capacityrequests.internal.autoscaling.k8s.io para remover o CRD.
  • scalingpolicies.scalingpolicy.kope.io: Este CRD foi usado para controlar recursos do fluentd, mas o GKE migrou para a utilização do fluentbit. Execute kubectl delete crd scalingpolicies.scalingpolicy.kope.io para remover o CRD.
  • memberships.hub.gke.io: Execute kubectl delete crd memberships.hub.gke.io para remover o CRD se não existirem recursos de apoio. Ative o modo permissivo se existirem recursos de apoio.
  • applications.app.k8s.io: Ative o modo permissivo com uma compreensão do comportamento de restauro.