Ativar o modo permissivo em um plano de backup

Autopilot Standard

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.

Se você ativar o modo permissivo, a descrição do problema ainda será fornecida no campo Motivo do status, mas o backup não falhará. É possível ativar esse comportamento se estiver ciente do problema e preparado para empregar uma solução no momento da restauração.

Este é um exemplo de mensagem de erro que pode aparecer no campo Motivo do status que sugere a ativação do modo permissivo: If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

Ative o modo permissivo:

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

Substitua:

BACKUP_PLAN: o nome do plano de backup que você quer atualizar.
PROJECT_ID: o ID do seu projeto do Google Cloud;
LOCATION: a região do Compute do recurso, por exemplo, us-central1; Consulte Sobre locais de recursos.

Para uma lista completa de opções, consulte a documentação gcloud beta container backup-restore backup-plans update.

Console

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

No Console do Google Cloud, acesse a página do Google Kubernetes Engine.

Acessar o Google Kubernetes Engine
No menu de navegação, clique em Backup para o GKE.
Clique na guia Planos de backup.
Expanda o cluster e clique no nome do plano.
Clique na guia Detalhes para editar os detalhes do plano.
Clique em Editar para editar a seção com o Modo de backup.
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 você gerencia a CRD, siga as etapas ma documentação do Kubernetes para especificar um esquema estrutural para a CRD. 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.
`PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up`	Descrição: no cluster de origem, um PVC está vinculado um PV que não é um volume de Persistent Disk. Motivo: o Backup para GKE só é compatível com backup de dados de volume do Persistent Disk. Os PVCs que não são do Persistent Disk restaurados usando a política Provisionar novos volumes e restaurar dados de volume de backup não vão restaurar dados de volume. No entanto, a política Reutilizar volumes atuais que contenham seus dados permite que os PVCs sejam reconectados ao gerenciador de volumes original. Isso é útil para tipos de volume que são utilizados com um servidor externo, como NFS.	Ativar o modo permissivo com uma compreensão das opções de restauração disponível para os volumes não relacionados ao Persistent Disk no cluster de origem. Para fazer backup de volumes do Filestore, consulte Gerenciar volumes do Filestore com o Backup para GKE. Quando o modo permissivo é ativado, o backup da configuração de PVC é feito, mas os dados de volume não são adicionados ao backup.
`PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up`	Descrição: um PVC no cluster não está vinculado a um PV. Motivo: o Backup para GKE pode fazer backup do PVC, mas não há dados de volume para fazer backup. Essa situação pode indicar configuração incorreta ou uma incompatibilidade entre o armazenamento solicitado e o disponível.	Verifique se o PVC desvinculado está em uma condição aceitável. Em caso afirmativo, ative o modo permissivo. Esteja ciente das implicações do backup do seu modelo. Quando o modo permissivo é ativado, o backup da configuração de PVC é realizado, mas não há dados de volume para fazer backup.
`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+.

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.