Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Resolver erros de permissão no Backup para GKE

Autopilot Standard

Nesta página, descrevemos os erros de permissão que podem ocorrer ao usar o Backup para GKE, o que considerar ao realizar a ação e como resolver o erro.

Erro 100010101: falha ao fazer backup de PersistentVolumeClaim. Vinculação do IAM ausente para o projeto do locatário

O erro 100010101 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido à falta de uma vinculação do Identity and Access Management para o projeto de locatário, resultando em uma mensagem de erro que indica Failed to backup PersistentVolumeClaim - Missing IAM binding for tenant project.

O Backup para GKE cria snapshots do Persistent Disk do cluster do GKE. Os snapshots ficam no seu projeto Cloud de Confiance by S3NS , também conhecido como projeto de consumidor, e o Cloud de Confiance by S3NS os cria em um projeto de locatário que ele gerencia. O projeto de locatário existe na organização google.com, separado da sua própria organização.

O agente de serviço no projeto de locatário precisa de permissões específicas para usar a chave de criptografia gerenciada pelo cliente (CMEK) que criptografa o Persistent Disk referenciado pelo PersistentVolumeClaim do cluster. Essa permissão criptografa e descriptografa os dados do snapshot. Se o agente de serviço service-TENANT_PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com não tiver a função roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK do disco, a operação de backup vai falhar.

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

Verifique se você tem permissões suficientes do IAM para modificar as políticas do IAM na chave do Cloud Key Management Service no console do Cloud de Confiance , como roles/cloudkms.admin ou roles/owner.
Localize o agente de serviço do Compute Engine do projeto do locatário usando o valor TENANT_PROJECT_NUMBER na mensagem status reason da operação de backup com falha. Por exemplo, service-TENANT_PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com.
Localize as seguintes informações de CMEK usadas para o Persistent Disk criptografado:
- Nome da chave: o nome da sua chave de criptografia.
- Keyring: o nome do keyring em que a chave está localizada.
- Local: o local do Cloud de Confiance by S3NS onde sua chave está. Por exemplo, global ou us-central1.
Para conceder ao agente de serviço do Compute Engine do projeto de locatário o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK, execute o comando gcloud kms keys add-iam-policy-binding usando a Google Cloud CLI:
```
gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-TENANT_PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter
```
Substitua:
- KEY_NAME: o nome da chave de criptografia.
- KEY_RING: o nome do keyring;
- LOCATION: a Cloud de Confiance by S3NS localização da chave. Por exemplo, global ou us-central1.
- TENANT_PROJECT_NUMBER: o número do projeto de locatário que você recebeu da mensagem status reason da sua operação de backup com falha.
Se o comando for bem-sucedido, a saída será semelhante a esta:
```
- members:
- serviceAccount:service-987654321098@compute-system.s3ns-system.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter
```
Teste novamente a operação de backup. Se a operação ainda não for concluída, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010104: falha ao fazer backup de PersistentVolumeClaim. Violação da restrição da política da organização ao criar snapshot.

O erro 100010104 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido a uma violação de restrição da política da organização durante a criação de um snapshot, resultando em uma mensagem de erro informando Failed to backup PersistentVolumeClaim - Org policy constraint violation while creating snapshot.

O Backup para GKE cria snapshots do Persistent Disk do cluster do GKE. Os snapshots ficam no seu projeto Cloud de Confiance by S3NS , também conhecido como projeto do consumidor, e são criados em um projeto de locatário gerenciado pelo Cloud de Confiance by S3NS. O projeto do locatário existe na organização google.com, separada da sua.

A política da organização determina onde é possível criar recursos de armazenamento. O erro Constraint constraints/compute.storageResourceUseRestrictions violated significa que um recurso ou snapshot está violando a política por ter sido criado em um projeto de locatário que não faz parte da estrutura organizacional permitida. Como o projeto do locatário está na organização do Google, ele fica fora da política definida, o que causa a falha do backup.

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

Localize a política da organização que implementa a restrição constraints/compute.storageResourceUseRestrictions. Para mais informações sobre como visualizar políticas da organização usando o console do Cloud de Confiance , consulte Como visualizar políticas da organização.
Modifique a política constraints/compute.storageResourceUseRestrictions para incluir a pasta do projeto do locatário folders/77620796932 usada pelo Backup para GKE na lista de permissões.

Observação: verifique se o ID da pasta especificado foi adicionado à lista de locais permitidos para que o Backup para GKE crie snapshots nos projetos de locatário, mesmo que estejam fora da hierarquia organizacional.
Salve as mudanças na política depois de adicionar a pasta à lista de permissões.
Teste novamente a operação de backup depois que a política da organização for atualizada e propagada, o que geralmente leva alguns minutos. O backup precisa continuar sem violar as restrições de uso de recursos de armazenamento. Se a operação ainda não for concluída, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010106: falha ao fazer backup do PersistentVolumeClaim. Não há vinculação do IAM para o agente de serviço do Backup para GKE.

O erro 100010106 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido à falta de uma vinculação do Identity and Access Management para o agente de serviço do Backup para GKE, resultando em uma mensagem de erro que indica Failed to backup PVC - Missing IAM binding for Backup for GKE service agent.

O Backup para GKE exige permissões para usar a chave de criptografia gerenciada pelo cliente (CMEK) do BackupPlan para criptografar e descriptografar volumes do Persistent Disk. Quando o agente de serviço do Backup para GKE não tem a função roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK BackupPlan, as operações de backup falham.

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

Identifique o agente de serviço do Backup para GKE gerenciado pelo Google específico para seu projeto. Por exemplo, service-PROJECT_NUMBER@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com Para encontrar o número do projeto, use os seguintes métodos:
- Use o painel de projetos do Cloud de Confiance by S3NS no console do Cloud de Confiance .
- Execute o comando gcloud projects describe usando a Google Cloud CLI:
```
gcloud projects describe PROJECT_ID –format="value(projectNumber)"
```
  Substitua PROJECT_ID pelo nome exclusivo do seu projeto.
Identifique os seguintes detalhes da CMEK:
- Nome da chave: o nome da chave de criptografia.
- Keyring: o nome do keyring em que a chave está localizada.
- Local: o local Cloud de Confiance by S3NS onde a CMEK BackupPlan está localizada. Por exemplo, global ou us-central1.
Para conceder ao agente de serviço do Backup para GKE o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK, use a Google Cloud CLI para executar o comando gcloud kms keys add-iam-policy-binding:
```
gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter
```
Substitua:
- KEY_NAME: o nome da chave de criptografia.
- KEY_RING: o nome do keyring;
- LOCATION: a Cloud de Confiance by S3NS localização da chave. Por exemplo, global ou us-central1.
- PROJECT_NUMBER: o número do projeto do Cloud de Confiance by S3NS .
Verifique se você tem as permissões necessárias do Identity and Access Management na chave do Cloud Key Management Service. Por exemplo, roles/cloudkms.admin ou roles/owner.
Verifique se você tem as permissões concedidas. Na saída do comando gcloud kms keys add-iam-policy-binding anterior, procure uma entrada semelhante a esta:
```
-members:
-serviceAccount:service-123456789012@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter
```
Teste novamente a operação de backup depois de conceder as permissões necessárias. Se a operação não for concluída, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010107: falha ao fazer backup de PersistentVolumeClaim. Vinculação do IAM ausente: conta de serviço do agente (KCP)

O erro 100010107 ocorre quando você tenta realizar uma operação de backup do Backup para GKE e o agente de serviço do cluster do Google Kubernetes Engine não tem acesso à sua chave de criptografia gerenciada pelo cliente (CMEK), resultando em uma mensagem informando Failed to backup PVC - Missing IAM binding - agent service account (KCP).

O agente de serviço do cluster do Google Kubernetes Engine, geralmente no formato service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com, é essencial para que o cluster do GKE interaja com os serviços do Cloud de Confiance by S3NS. Quando o plano de backup usa uma chave de criptografia gerenciada pelo cliente (CMEK). Esse agente de serviço precisa de permissões para criptografar e descriptografar seus dados de backup usando sua CMEK. Se o plano de backup não tiver a função roles/cloudkms.cryptoKeyEncrypterDecrypter na sua CMEK, as operações de backup iniciadas no cluster vão falhar com um erro permission denied.

Para resolver esse erro, use as seguintes instruções de solução de problemas:

Verifique se você tem as permissões corretas para modificar as políticas do IAM na chave do Cloud Key Management Service. Por exemplo, cloudkms.admin ou roles/owner.
Identifique o agente de serviço do cluster do Google Kubernetes Engine. Esse agente de serviço é criado e gerenciado automaticamente pelo Cloud de Confiance by S3NS para os clusters do GKE. Por exemplo, service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com. Você precisa do número do projeto para criar a conta de serviço completa. Para encontrar o número do projeto, use um dos seguintes métodos:
- Use o painel de projetos do Cloud de Confiance by S3NS no console do Cloud de Confiance .
- Execute o comando gcloud projects describe usando a Google Cloud CLI:
```
gcloud projects describe PROJECT_ID –-format="value(projectNumber)"
```
  Substitua PROJECT_ID pelo ID do projeto.
Localize as seguintes informações de CMEK:
- Nome da chave: o nome da chave de criptografia.
- Keyring: o nome do keyring em que a chave está localizada.
- Local: o Cloud de Confiance by S3NS local onde a chave está localizada. Por exemplo, global ou us-central1.
Conceda o papel roles/cloudkms.cryptoKeyEncrypterDecrypter no nível da CMEK. O agente de serviço do Google Kubernetes Engine precisa de permissões na sua chave de criptografia. Para conceder o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na sua CMEK, use a Google Cloud CLI para executar o comando gcloud kms key add-iam-policy-binding:
```
gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter
```
Substitua:
- KEY_NAME: o nome da chave de criptografia.
- KEY_RING: o nome do keyring;
- LOCATION: a Cloud de Confiance by S3NS localização da chave. Por exemplo, global ou us-central1.
- PROJECT_NUMBER: o nome do projeto.
O resultado será o seguinte:
```
 - members:
 - serviceAccount:service-123456789012@container-engine-robot.s3ns-system.iam.gserviceaccount.com
 role: roles/cloudkms.cryptoKeyEncrypterDecrypter
 ```
```
Tente novamente a operação do Backup para GKE. Se a operação continuar falhando, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010109: falha ao fazer backup do PersistentVolumeClaim. A região de backup de destino não é permitida pela política DiskSettings.

O erro 100010109 ocorre quando a região de backup de destino não é permitida pela política de local de acesso DiskSettings.

Entender o erro

Esse erro ocorre quando o cliente tem uma política de local de acesso DiskSettings definida como SPECIFIC_REGIONS para alguns locais de disco referenciados no cluster que está sendo copiado. Como essa política de local de acesso só permite que regiões específicas sejam locais válidos para a criação de snapshots, o backup será rejeitado se o local de armazenamento de destino estiver fora dessa lista. Quando isso acontece, a criação do snapshot falha com uma mensagem semelhante a esta:

No permission to read source disk in us-central1 from target snapshot in us-east1.

Etapas da solução de problemas

Identifique as regiões de origem e de destino: analise a mensagem de erro para encontrar o local do disco de origem (por exemplo, us-central1) e a região do snapshot de destino (por exemplo, us-east1) que foi negada.
Atualize a política DiskSettings: para corrigir o problema, atualize o DiskSettings para permitir o local de armazenamento de destino para os locais de disco referenciados no cluster. Para isso, adicione a região de destino à lista de permissões de locais de acesso usando a Google Cloud CLI.
- Para um disco zonal (por exemplo, adicionar us-east1 como permitido para discos em us-central1-a):
```
gcloud beta compute disk-settings update --access-location-policy=specific-regions --add-access-locations=us-east1 --zone=us-central1-a
```
- Para um disco regional (por exemplo, adicionar us-east1 como permitido para discos em us-central1):
```
gcloud beta compute disk-settings update --access-location-policy=specific-regions --add-access-locations=us-east1 --region=us-central1
```
Teste novamente a operação de backup: depois de atualizar o DiskSettings para permitir a região de backup de destino, tente novamente a operação de backup.

Erro 100020101: falha ao fazer backup do PersistentVolumeClaim, que está vinculado a um tipo de PersistentVolume não compatível

O erro 100020101 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha porque o PersistentVolumeClaim está vinculado a um tipo de PersistentVolume não compatível. O erro resulta na seguinte mensagem de erro: PersistentVolumeClaims are bound to PersistentVolumes of unsupported types and cannot be backed up.

Esse erro ocorre quando a operação do Backup para GKE encontra um PersistentVolumeClaim vinculado a um PersistentVolume que usa um tipo de volume não compatível com o backup de dados pelo Backup para GKE. O Backup para GKE oferece suporte principalmente ao backup de dados de volumes do Persistent Disk. Se um PersistentVolumeClaim estiver vinculado a um PersistentVolume que não seja um Persistent Disk, a operação de backup vai falhar para os dados do PersistentVolumeClaim.

Para resolver esse erro, use as seguintes instruções de solução de problemas:

Liste todos os PersistentVolumeClaims e os PersistentVolumes vinculados a eles executando o comando kubectl get pvc. Revise essa lista para identificar os PersistentVolumes que têm suporte de tipos de volume não compatíveis.
```
kubectl get pvc --all-namespaces -o wide
```
Determine o tipo de volume do PersistentVolume com suporte de um tipo de volume não compatível com o Backup para GKE executando o comando kubectl describe pv:
```
kubectl describe pv PERSISTENT_VOLUME_NAME
```
Substitua:

PERSISTENT_VOLUME_NAME: o nome de PersistentVolume que tem um tipo de volume sem suporte listado como coluna VOLUME na saída da etapa anterior.

Na saída, use os campos Source e Driver para ver os detalhes do provisionador de volumes:
- Para discos permanentes compatíveis: a saída será semelhante a Source.Driver: pd.csi.storage.gke.io ou Source.Type:GCEPersistentDisk.
- Para tipos não compatíveis que estão causando o erro: a saída seria um driver de disco não permanente, por exemplo, Source.Driver:filestore.csi.storage.gke.io.
Use um dos seguintes métodos para resolver o erro:
- Migrar para um Persistent Disk permanente: recomendamos esse método para backups de dados completos. Se você precisar fazer backup dos dados reais do volume, use um Persistent Disk, o que envolve migrar os dados do tipo de volume não compatível para um novo volume CSI do Persistent Disk. Para receber ajuda com a migração de um volume de Persistent Disk, entre em contato com o Cloud Customer Care.
- Ative o modo permissivo no Backup para GKE: recomendamos esse método se o backup de dados não for necessário para volumes sem suporte. Se a migração de dados não for viável ou necessária (por exemplo, se o volume for apoiado por um serviço externo e você planeja reconectá-lo durante a operação de restauração), configure seu plano de backup do Backup para GKE para permitir que o backup prossiga no modo permissivo. Para mais informações sobre como ativar o modo permissivo, consulte Ativar o modo permissivo em um plano de backup.
Tente novamente a operação do Backup para GKE. Com base no método escolhido para resolver o erro, a operação do Backup para GKE se comporta das seguintes maneiras:
- Se você migrou para um volume de Persistent Disk, o backup será concluído para o volume, incluindo os dados dele.
- Se você ativou o modo permissivo, a operação de backup vai ser concluída, mas os dados de volumes não compatíveis não serão incluídos no backup.

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

Erro 100020104: falha ao fazer backup do PersistentVolumeClaim. O PersistentVolumeClaim não está vinculado a um PersistentVolume.

O erro 100020104 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha porque o PersistentVolumeClaim não está vinculado a um PersistentVolume. O erro resulta na seguinte mensagem de erro: Failed to backup PVC - PVC Not Bound to a Persistent Volume.

Esse erro ocorre quando a operação do Backup para GKE tenta fazer backup de um PersistentVolumeClaim que não está vinculado a um PersistentVolume. Um PersistentVolumeClaim precisa ser vinculado a um PersistentVolume antes de poder ser usado por uma carga de trabalho consumidora, como um pod, e posteriormente fazer backup com o Backup para GKE. Se o PersistentVolumeClaim permanecer no estado Pending, isso significa que um PersistentVolume adequado não está disponível ou não pode ser provisionado ou vinculado, o que leva à falha da operação de backup. Um motivo comum para um PersistentVolumeClaim permanecer sem vinculação é quando o StorageClass associado usa um modo de vinculação WaitForFirstConsumer, mas nenhum pod ou outra carga de trabalho ainda está tentando consumir o PersistentVolumeClaim.

Para resolver esse erro, use as seguintes instruções de solução de problemas:

Para verificar o status de todos os PersistentVolumeClaims no cluster e identificar o PersistentVolumeClaim não vinculado, execute o comando kubectl get pvc:
```
kubectl get pvc --all-namespaces | grep `Pending`
```
Depois de identificar o PersistentVolumeClaim que não está vinculado a um PersistentVolume, recupere informações sobre o PersistentVolumeClaim não vinculado executando o comando kubectl describe pvc:
```
kubectl describe pvc PVC_NAME -n NAMESPACE_NAME
```
Substitua:
- PVC_NAME: o nome do PersistentVolumeClaim que não foi possível fazer backup.
- NAMESPACE_NAME: o nome do namespace em que o PersistentVolumeClaim reside.
Depois que a descrição aparecer, use os campos Status e Events para determinar se o PersistentVolumeClaim está vinculado a um PersistentVolume. Se você ainda não conseguir determinar por que o PersistentVolumeClaim não está vinculado a um PersistentVolume ou não conseguir resolver o problema identificado, ative o modo permissivo no plano de backup. Para saber como ativar o modo permissivo, consulte Ativar o modo permissivo em um plano de backup.

A seguir

Leia a página de visão geral dos códigos de erro do Backup para GKE.