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 do PersistentVolumeClaim. Falta uma vinculação do IAM para o projeto de locatário

O erro 100010101 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido a uma vinculação do Identity and Access Management ausente para o projeto do locatário, resultando em uma mensagem de erro que declara 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 residem no seu Cloud de Confiance by S3NS projeto, também conhecido como projeto de consumidor, e Cloud de Confiance by S3NS os cria em um projeto de locatário gerenciado por ele. O projeto de locatário existe na organização google.com, separada da sua.

O agente de serviço no projeto de locatário exige 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 o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK do disco, a operação de backup falhará.

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

Verifique se você tem permissões do IAM suficientes para modificar políticas do IAM na chave do Cloud Key Management Service no Cloud de Confiance console, 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 da CMEK usadas para o Persistent Disk criptografado:
- Nome da chave: o nome da chave de criptografia.
- Keyring: o nome do keyring em que a chave reside.
- Local: o Cloud de Confiance by S3NS local em que a chave está localizada. Por exemplo, global ou us-central1.
Para conceder ao agente de serviço do Compute Engine do projeto do 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: o Cloud de Confiance by S3NS local da chave. Por exemplo, global ou us-central1.
- TENANT_PROJECT_NUMBER: o número do projeto do locatário que você recebeu da mensagem status reason da 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 bem-sucedida, entre em contato com o Cloud Customer Care para receber mais ajuda.

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

O erro 100010104 ocorre quando uma tentativa de fazer backup de um PersistentVolumeClaim falha devido a uma violação da restrição da política da organização durante a criação do snapshot, resultando em uma mensagem de erro que declara 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 residem no seu Cloud de Confiance by S3NS projeto, também conhecido como projeto de consumidor, e são criados em um projeto de locatário que é gerenciado por Cloud de Confiance by S3NS. O projeto de locatário existe na organização google.com, separada da sua.

A política da organização determina onde você pode criar recursos de armazenamento. O erro Constraint constraints/compute.storageResourceUseRestrictions violated significa que um recurso ou snapshot está violando a política ao ser criado em um projeto de locatário que não faz parte da estrutura organizacional permitida. Como o projeto de locatário está na organização do Google, ele fica fora da política definida, o que leva à 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 Cloud de Confiance console, consulte Como visualizar políticas da organização.
Modifique a política constraints/compute.storageResourceUseRestrictions para incluir a pasta do projeto de locatário folders/77620796932 usada pelo Backup para GKE na lista de permissões.

Observação: verifique se o ID da pasta especificada foi adicionado à lista de locais permitidos para permitir que o Backup para GKE crie snapshots nos projetos do locatário, mesmo que estejam fora da hierarquia organizacional.
Salve as alterações 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 vai continuar sem violar as restrições de uso de recursos de armazenamento. Se a operação ainda não for bem-sucedida, entre em contato com o Cloud Customer Care para receber mais ajuda.

Erro 100010106: falha ao fazer backup do PersistentVolumeClaim. Falta uma 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 a uma vinculação do Identity and Access Management ausente para o agente de serviço do Backup para GKE, resultando em uma mensagem de erro que declara 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 de discos permanentes. Quando o agente de serviço do Backup para GKE não tem o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK do 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. É possível encontrar o número do projeto usando os seguintes métodos:
- Use o Cloud de Confiance by S3NS painel do projeto no Cloud de Confiance console.
- 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 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 reside.
- Local: o Cloud de Confiance by S3NS local em que a BackupPlan CMEK 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: o Cloud de Confiance by S3NS local da chave. Por exemplo, global ou us-central1.
- PROJECT_NUMBER: o número do seu Cloud de Confiance by S3NS projeto.
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 do PersistentVolumeClaim. Falta uma vinculação do IAM. 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 à chave de criptografia gerenciada pelo cliente (CMEK), resultando em uma mensagem que declara Failed to backup PVC - Missing IAM binding - agent service account (KCP).

O agente de serviço do cluster do Google Kubernetes Engine, normalmente no formato de service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com, é essencial para que o cluster do GKE interaja com Cloud de Confiance by S3NS serviços. 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 os dados de backup usando a CMEK. Se o plano de backup não tiver o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na CMEK, as operações de backup iniciadas no cluster vão falhar com um erro permission denied.

Para resolver esse erro, siga estas 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 para seus clusters do GKE . Cloud de Confiance by S3NS Por exemplo, service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com. Você precisa do número do projeto para montar a conta de serviço completa. É possível encontrar o número do projeto usando um dos seguintes métodos:
- Use o Cloud de Confiance by S3NS painel do projeto no Cloud de Confiance console.
- 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 da CMEK:
- Nome da chave: o nome da chave de criptografia.
- Keyring: o nome do keyring em que a chave reside.
- Local: o Cloud de Confiance by S3NS local em que 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 chave de criptografia. Para conceder o papel roles/cloudkms.cryptoKeyEncrypterDecrypter na 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: o Cloud de Confiance by S3NS local da chave. Por exemplo, global ou us-central1.
- PROJECT_NUMBER: o nome do projeto.
O resultado será assim:
```
 - 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ão sendo armazenados em backup. Como essa política de local de acesso permite apenas que regiões específicas sejam locais de criação de snapshot válidos, o backup é 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: revise a mensagem de erro para encontrar o local do disco de origem (por exemplo, us-central1) e a região de snapshot de destino (por exemplo, us-east1) que foi negada.
Atualize a política DiskSettings: para corrigir o problema, você deve atualizar o DiskSettings para permitir o local de armazenamento de destino para os locais de disco referenciados no cluster. Para fazer 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. O PersistentVolumeClaim 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 não compatível PersistentVolume. 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 de Persistent Disk. Se um PersistentVolumeClaim estiver vinculado a um PersistentVolume que não seja um Persistent Disk, a operação de backup falhará para os dados do PersistentVolumeClaim.

Para resolver esse erro, siga estas 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 são apoiados por tipos de volume não compatíveis.
```
kubectl get pvc --all-namespaces -o wide
```
Determine o tipo de volume do PersistentVolume que é apoiado por 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 não compatível listado como coluna VOLUME na saída da etapa anterior.

Na saída, use os campos Source e Driver para receber detalhes do provisionador de volume:
- Para discos permanentes compatíveis: a saída é 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 de volume reais, use um Persistent Disk, que envolve a migração dos dados do tipo de volume não compatível para um novo volume CSI de disco permanente. Para receber ajuda com a migração de um volume de Persistent Disk, entre em contato com o Cloud Customer Care.
- Ativar o modo permissivo no Backup para GKE: recomendamos esse método se o backup de dados não for necessário para volumes não compatíveis. 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 anexá-lo novamente durante a operação de restauração, configure o plano de backup do Backup para GKE para permitir que o backup continue 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á bem-sucedido para o volume, incluindo os dados.
- Se você ativou o modo permissivo, a operação de backup será bem-sucedida, mas os dados de volumes não compatíveis não serão armazenados em 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 pelo Backup para GKE. Se o PersistentVolumeClaim permanecer em um 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 não vinculado é 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, siga estas 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 kubectl get pvc comando:
```
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 fez 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 seu plano de backup. Para mais informações sobre 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.