Container Service for Kubernetes:FAQ sobre o backup center

Por que o console exibe "The working component is abnormal" ou "Failed to fetch current data"?

O componente do backup center não foi instalado corretamente. Verifique os itens a seguir:

• Verifique se o cluster possui nós. O backup center não pode ser implantado em um cluster sem nós.

• Se o cluster utiliza FlexVolume, mude para CSI (Container Storage Interface) primeiro. Consulte The migrate-controller component in a FlexVolume cluster cannot start.

• Caso utilize kubectl, confirme se as configurações YAML estão corretas. Consulte Usar kubectl para fazer backup e restaurar aplicações.

• Para clusters dedicados ACK e clusters registrados, confirme se as permissões necessárias foram concedidas. Consulte Cluster dedicado ACK e Cluster registrado.

• Verifique se os deployments csdr-controller e csdr-velero no namespace csdr falharam devido a recursos insuficientes ou restrições de agendamento e resolva quaisquer problemas.

Por que o console exibe "The name has been used. Change the name and try again"?

Ao excluir uma tarefa, o sistema cria um recurso deleterequest no cluster e executa uma série de operações de exclusão — não apenas a exclusão do recurso de backup em si. Se a exclusão falhar ou for interrompida, alguns recursos podem permanecer no cluster com o mesmo nome, causando esse erro.

Execute o comando a seguir para excluir o recurso conflitante. Por exemplo, se o erro for deleterequests.csdr.alibabacloud.com "xxxxx-dbr" already exists:

kubectl -n csdr delete deleterequests xxxxx-dbr

Em seguida, crie a tarefa com um novo nome.

Por que não consigo selecionar um backup existente ao restaurar entre clusters?

Uma possível causa é o backup vault não ter sido inicializado no cluster de destino. Na página Create Restoration Task, localize Backup Vaults e clique em Initialize Backup Vault. Após a conclusão da inicialização, selecione o backup e restaure.

Se a inicialização falhar, o recurso backuplocation no cluster de destino apresentará o status Unavailable. Execute o comando a seguir para verificar:

kubectl get -n csdr backuplocation <backuplocation-name>

Saída esperada:

NAME                    PHASE       LAST VALIDATED   AGE
<backuplocation-name>   Available   3m36s            38m

Se o status for Unavailable, consulte Why does my job fail with "VaultError: xxx"?

Caso o status do backup vault esteja normal, confirme no console do cluster de origem se a tarefa de backup apresenta o status Completed. Tarefas de backup com falha ou em andamento não podem ser selecionadas para restauração entre clusters.

Por que o console exibe "The service role required by the current component has not been authorized" (AddonRoleNotAuthorized)?

A partir da versão 1.8.0 do migrate-controller, a lógica de autenticação de recursos cloud para clusters gerenciados ACK foi atualizada. Na primeira instalação ou atualização para esta versão, a conta Alibaba Cloud deve concluir a autorização.

• Se estiver conectado com uma conta Alibaba Cloud, clique em Authorize.

• Se estiver conectado como usuário RAM, clique em Copy Authorization Link e envie-o ao titular da conta Alibaba Cloud para autorização.

Por que o console exibe "The current account has not been granted the cluster RBAC permissions required for this operation" (APISERVER.403)?

O console interage com o servidor de API para enviar e monitorar tarefas de backup e restauração. Os conjuntos de permissões padrão para engenheiros de O&M e desenvolvedores não incluem algumas permissões exigidas pelo backup center.

Conceda as seguintes permissões de ClusterRole aos operadores do backup center. Para instruções, consulte Restrict resource operations in a cluster by using custom RBAC.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: csdr-console
rules:
  - apiGroups: ["csdr.alibabacloud.com","velero.io"]
    resources: ['*']
    verbs: ["get","create","delete","update","patch","watch","list","deletecollection"]
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get","list"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get","list"]

Por que o componente do backup center falha ao atualizar ou desinstalar, e o namespace csdr permanece em Terminating?

O backup center encerrou de forma anormal, deixando tarefas no estado InProgress. O campo finalizers nessas tarefas está bloqueando a exclusão de recursos.

Execute o comando a seguir para identificar o que está bloqueando o namespace:

kubectl describe ns csdr

Confirme que as tarefas travadas não são mais necessárias e exclua seus finalizers. Após a exclusão do namespace csdr:

• Para atualizações, reinstale o componente migrate-controller.

• Para desinstalações, o componente já foi removido.

Por que minha tarefa falha com "internal error"?

O componente ou um service cloud subjacente encontrou uma exceção inesperada. Por exemplo, o service cloud pode não estar disponível na região atual.

Se o erro for HBR backup/restore internal error, verifique o console do Cloud Backup para confirmar se o recurso de backup de contêineres está disponível em sua região.

Por que minha tarefa falha com "create cluster resources timeout"?

Durante uma conversão de StorageClass ou restauração, o backup center cria pods temporários, persistent volume claims (PVCs) e persistent volumes (PVs). Se esses recursos permanecerem indisponíveis por muito tempo, ocorrerá este erro de timeout.

1. Identifique o recurso travado:

   kubectl -n csdr describe <applicationbackup/converttosnapshot/applicationrestore> <task-name>

   Por exemplo, uma saída como wait for created tmp pvc default/demo-pvc-for-convert202311151045 for convertion bound time out indica que o PVC demo-pvc-for-convert202311151045 no namespace default não está sendo vinculado.

2. Verifique o status do PVC para encontrar a causa raiz:

   kubectl -n default describe pvc demo-pvc-for-convert202311151045

As causas comuns incluem:

• Recursos insuficientes no cluster ou nos nós.

• O cluster de restauração não possui a classe de armazenamento necessária. Utilize o recurso de conversão de StorageClass para selecionar uma classe de armazenamento disponível antes de restaurar.

• O armazenamento subjacente da classe de armazenamento está indisponível — por exemplo, o tipo de disco especificado não é suportado na zona atual.

• O Container Network File System (CNFS) associado a alibabacloud-cnfs-nas está anormal. Consulte Method 3: Use an existing NAS file system.

• Uma classe de armazenamento com volumeBindingMode: Immediate foi selecionada em um cluster multizona.

Para orientações sobre solução de problemas de armazenamento, consulte Troubleshoot storage issues.

Por que minha tarefa falha com "addon status is abnormal"?

Os componentes no namespace csdr estão anormais. Verifique o status deles:

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

Para etapas de resolução, consulte Why is my job stuck in InProgress?

Por que minha tarefa falha com "VaultError: xxx"?

Este erro indica que o backup vault não consegue acessar o bucket do Object Storage Service (OSS). Siga as verificações abaixo em ordem.

1. Verifique se o bucket OSS existe.

Faça login no console do OSS e confirme se o bucket associado ao backup vault existe. Caso contrário, crie um novo bucket e associe-o novamente. Consulte Criar buckets.

2. Verifique as permissões de acesso ao OSS.

As etapas necessárias dependem do tipo de cluster:

• Clusters ACK Pro: Nenhuma configuração de permissão OSS é necessária se o nome do bucket OSS começar com cnfs-oss-.

• Clusters dedicados ACK e clusters registrados: Configure as permissões OSS conforme descrito em Install migrate-controller and configure permissions.

• Clusters gerenciados ACK: Se o componente foi instalado ou atualizado para v1.8.0 ou posterior fora do console, execute o comando a seguir para verificar se as permissões OSS estão configuradas:

  kubectl get secret -n kube-system | grep addon.aliyuncsmanagedbackuprestorerole.token

  Saída esperada:

  addon.aliyuncsmanagedbackuprestorerole.token          Opaque                      1      62d

  Se a saída corresponder, as permissões estão configuradas. Caso contrário, conceda permissões usando um dos métodos a seguir:

  • Siga as instruções para clusters dedicados ACK e clusters registrados. Consulte Install migrate-controller and configure permissions.

  • Clique em Authorize para autorizar sua conta Alibaba Cloud. Você só precisa fazer isso uma vez por conta.

3. Verifique a configuração de rede.

kubectl get backuplocation <backuplocation-name> -n csdr -o yaml | grep network

• network: internal — o vault acessa o OSS pela rede interna.

• network: public — o vault acessa o OSS pela Internet. Se isso causar timeout, verifique se o cluster tem acesso à Internet. Consulte Enable Internet access for an existing ACK cluster.

O backup vault deve usar acesso por rede pública nestes cenários:

• O cluster e o bucket OSS estão em regiões diferentes.

• O cluster é um cluster ACK Edge.

• O cluster é um cluster registrado que não está conectado a uma VPC via Cloud Enterprise Network (CEN), Express Connect ou VPN — ou não há rota configurada para o bloco CIDR interno do OSS da região. Nesse caso, configure uma rota para o bloco CIDR interno do OSS da região.

  • Para informações sobre conexão de data center on-premises a uma VPC, consulte Combine multiple connection methods to build an enterprise-class hybrid cloud.

  • Para o mapeamento entre endpoints internos do OSS e blocos CIDR VIP, consulte Access OSS via endpoints and bucket domains.

Para mudar para acesso por rede pública, execute:

kubectl patch -n csdr backuplocation/<backuplocation-name> --type='json' -p \
  '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'
kubectl patch -n csdr backupstoragelocation/<backuplocation-name> --type='json' -p \
  '[{"op":"add","path":"/spec/config","value":{"network":"public","region":"<region-id>"}}]'

Substitua <region-id> pela região do bucket OSS, como cn-hangzhou.

Por que minha tarefa falha com "HBRError: check HBR vault error"?

O Cloud Backup não está ativado ou não possui as permissões necessárias.

1. Ative o service Cloud Backup. Consulte Ativar Cloud Backup.

2. Para clusters em China (Ulanqab), China (Heyuan) ou China (Guangzhou), autorize também o Cloud Backup a acessar o API Gateway após a ativação. Consulte (Optional) Step 3: Grant Cloud Backup permission to use API Gateway.

3. Para clusters dedicados ACK e clusters registrados, verifique se as permissões RAM (Resource Access Management) do Cloud Backup foram concedidas. Consulte Install migrate-controller and configure permissions.

Por que minha tarefa falha com "HBRError: ... code: 400, Illegal request. Please modify the parameters"?

O repositório ack-backup-data do Cloud Backup na região foi excluído.

Ao criar um backup em uma região pela primeira vez, o backup center cria automaticamente um repositório ack-backup-data para armazenar backups. Se esse repositório for excluído, as tarefas subsequentes falharão com este erro.

1. Em todos os clusters que utilizam o backup center na região afetada, limpe os registros do backup vault:

   kubectl -ncsdr delete backuplocation --all
   kubectl -ncsdr delete backupstoragelocation --all

2. Retorne ao cluster e crie um novo backup. O componente criará automaticamente um novo repositório ack-backup-data e o associará ao backup vault.

Por que minha tarefa falha com "hbr task finished with unexpected status: FAILED, errMsg ClientNotExist"?

O cliente do Cloud Backup (o DaemonSet hbr-client) em um nó do namespace csdr não está executando corretamente.

1. Verifique se há pods hbr-client anormais:

   kubectl -n csdr get pod -lapp=hbr-client

2. Se algum pod estiver em estado anormal, verifique se a causa é insuficiência de endereços ip, memória ou cpu para pods. Para pods em estado CrashLoopBackOff, visualize os logs:

   kubectl -n csdr logs -p <hbr-client-pod-name>

   Se os logs contiverem SDKError: StatusCode: 403, Code: MagpieBridgeSlrNotExist, siga (Optional) Step 3: Grant API Gateway permissions to Cloud Backup para conceder as permissões necessárias.

3. Para outros erros de SDK, use o código de erro EC para solucionar problemas. Consulte Self-help troubleshooting by using error codes.

Por que minha tarefa está travada em InProgress?

kubectl get pod -n csdr
kubectl describe pod <pod-name> -n csdr

kubectl get volumesnapshot -n <backup-namespace>

Por que meu backup falha com "backup already exists in OSS bucket"?

Já existe um backup com o mesmo nome no bucket OSS associado ao backup vault. Recrie o backup vault com um novo nome.

Um backup pode estar invisível no cluster atual por vários motivos: pertence a uma tarefa em andamento ou com falha (que não são sincronizadas entre clusters), foi excluído em um cluster diferente (o arquivo é marcado, mas não removido do OSS) ou o cluster atual não está associado ao vault que o armazenou.

Por que meu backup falha com "get target namespace failed"?

Isso geralmente ocorre em tarefas de backup agendadas. A seleção de namespace é inválida:

• Se você selecionou Include, todos os namespaces selecionados foram excluídos.

• Se você selecionou Exclude, o cluster não possui namespaces além dos excluídos.

Atualize o plano de backup para corrigir a seleção de namespace.

Por que meu backup falha com "velero backup process timeout"?

Duas causas comuns:

Classe de armazenamento do bucket OSS: Se a classe de armazenamento do bucket for Archive, Cold Archive ou Deep Cold Archive, o backup center não consegue atualizar arquivos de metadados (arquivos arquivados devem ser restaurados primeiro). Altere a classe de armazenamento do bucket para Standard. Para manter os dados de backup na classe Archive, configure uma regra de ciclo de vida para converter automaticamente a classe de armazenamento e descongele os dados arquivados antes das operações de restauração. Consulte Converter classes de armazenamento.

Timeout de subtarefa: O timeout padrão para subtarefas de backup é de 60 minutos (migrate-controller 1.7.7 e posterior). Se seu cluster tiver muitos recursos ou o servidor de API apresentar alta latência, aumente esse valor no ConfigMap csdr-config:

kubectl edit -n csdr cm csdr-config

Adicione velero_timeout_minutes à seção applicationBackup. Por exemplo, para definir um timeout de 100 minutos:

apiVersion: v1
data:
  applicationBackup: |
    ...
    velero_timeout_minutes: 100

Reinicie o controlador para que a alteração tenha efeito:

kubectl -n csdr delete pod -l control-plane=csdr-controller

Por que meu backup falha com "HBR backup request failed"?

Três causas possíveis:

Plug-in de armazenamento incompatível: Se seu cluster usa um plug-in de armazenamento CSI não-Alibaba Cloud, ou o PV não é um tipo de volume Kubernetes padrão (como NFS ou LocalVolume), abra um ticket para assistência.

Volume em modo Block: O Cloud Backup não suporta volumes cujo VolumeMode seja Block. Se seu cluster usa CSI, snapshots de disco são usados para backup de dados por padrão, e snapshots de disco suportam volumes no modo Block. Se o tipo de plug-in de armazenamento estiver incorreto, mude para CSI, reinstale o componente de backup e execute o backup novamente.

Problema no cliente Cloud Backup: Para volumes de sistema de arquivos (OSS, NAS, CPFS ou local), o cliente Cloud Backup pode ter atingido timeout ou falhado. Para investigar:

1. Faça login no console do Cloud Backup.

2. Acesse Backup > Container Backup e clique na aba Backup Jobs.

3. Selecione a região na barra de navegação superior.

4. Selecione Job Name na lista suspensa à frente da caixa de pesquisa e pesquise por <backup-name>-hbr para visualizar o status da tarefa e o motivo da falha. Consulte Fazer backup de clusters ACK.

Para consultar uma tarefa de conversão de StorageClass ou backup, pesquise pelo nome do backup.

Por que meu backup falha com "hbr task finished with unexpected status: FAILED, errMsg SOURCE_NOT_EXIST"?

Para CSI de terceiros ou tipos de armazenamento autogerenciados (NFS, Ceph):

O backup center usa o caminho de montagem de volume padrão do Kubernetes como caminho de backup de dados. Para CSI padrão, o caminho padrão é /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~csi/<pv-name>/mount. Se o caminho raiz do kubelet em seu cluster foi alterado, o Cloud Backup pode não encontrar os dados.

Faça login no nó onde o volume está montado e solucione o problema:

1. Encontre o caminho raiz do kubelet:

   ps -elf | grep kubelet

   Interprete a saída da seguinte forma:

   • Se o comando de inicialização incluir --root-dir, esse valor é o caminho raiz do kubelet.

   • Se o comando de inicialização incluir --config, verifique o campo root-dir no arquivo de configuração.

   • Se nenhum dos parâmetros estiver presente, verifique /etc/systemd/system/kubelet.service em busca de uma referência EnvironmentFile e, em seguida, verifique ROOT_DIR nesse arquivo.

   • Se nada disso for encontrado, o caminho raiz do kubelet é o padrão /var/lib/kubelet.

2. Verifique se o caminho raiz é um link simbólico:

   ls -al <root-dir>

   Se a saída mostrar algo como kubelet -> /var/lib/container/kubelet, o caminho raiz real é /var/lib/container/kubelet.

3. Confirme se os dados do volume de destino existem sob o caminho raiz em <root-dir>/pods/<pod-uid>/volumes.

4. Defina a variável de ambiente KUBELET_ROOT_PATH no deployment csdr/csdr-controller para o caminho raiz real do kubelet.

Para armazenamento HostPath:

HostPath não cria um caminho de montagem sob o caminho raiz do kubelet. O componente de backup não consegue ler dados do caminho do nó por padrão. Abra um ticket para assistência.

Por que meu backup falha com "check backup files in OSS bucket failed", "upload backup files to OSS bucket failed" ou "download backup files from OSS bucket failed"?

O servidor OSS retornou um erro durante uma operação de arquivo no bucket do backup vault. Três causas possíveis:

Permissões KMS ausentes: Se você habilitou criptografia no lado do servidor com uma chave mestra de cliente (CMK) do Key Management Service (KMS) no bucket OSS, o backup center precisa de permissões adicionais. Consulte O backup center suporta criptografia KMS para o bucket OSS associado?.

Permissões OSS incompletas: Para clusters dedicados ACK e clusters registrados, verifique a política de permissões do usuário RAM usado durante a instalação do componente. Consulte Etapa 1: Configurar permissões.

Credenciais de autenticação revogadas: Para clusters dedicados ACK e clusters registrados, confirme se as credenciais de autenticação do usuário RAM ainda são válidas. Se foram revogadas, obtenha novas credenciais, atualize o Secret alibaba-addon-secret no namespace csdr e reinicie o componente:

kubectl -nkube-system delete pod -lapp=migrate-controller

Por que meu backup mostra PartiallyFailed com "PROCESS velero partially completed"?

Alguns recursos do cluster falharam no backup. Execute o comando a seguir para ver quais recursos falharam e por quê:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name>

Verifique os campos Errors e Warnings na saída e corrija os problemas. Para logs adicionais:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero backup logs <backup-name>

Por que meu backup mostra PartiallyFailed com "PROCESS hbr partially completed"?

O Cloud Backup falhou ao fazer backup de alguns volumes de sistema de arquivos (OSS, NAS, CPFS ou volumes locais). Isso pode ocorrer porque:

• O plug-in de armazenamento usado por alguns volumes não é suportado.

• Arquivos foram excluídos durante o backup, causando falha de consistência.

Para investigar, abra a aba Backup Jobs do console do Cloud Backup, selecione a região correta, selecione Job Name na lista suspensa à frente da caixa de pesquisa e pesquise por <backup-name>-hbr. Revise o status da tarefa e o motivo da falha. Consulte Fazer backup de clusters ACK.

Por que minha conversão de StorageClass falha com "storageclass xxx not exists"?

A classe de armazenamento de destino selecionada para conversão não existe no cluster atual.

1. Redefina a tarefa de conversão de StorageClass:

   cat << EOF | kubectl apply -f -
   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: DeleteRequest
   metadata:
     name: reset-convert
     namespace: csdr
   spec:
     deleteObjectName: "<backup-name>"
     deleteObjectType: "Convert"
   EOF

2. Crie a classe de armazenamento necessária no cluster.

3. Execute a tarefa de restauração novamente com a conversão de StorageClass configurada.

Por que minha conversão de StorageClass falha com "only support convert to storageclass with CSI diskplugin or nasplugin provisioner"?

A conversão de StorageClass suporta apenas tipos de volumes de disco e NAS CSI da Alibaba Cloud como destinos. Para outros requisitos, abra um ticket.

Se estiver usando um service de armazenamento que suporta acesso à rede pública (como OSS), crie um PV e PVC provisionados estaticamente e restaure a aplicação sem conversão de StorageClass. Consulte Usar um volume provisionado estaticamente ossfs 1,0.

Por que minha conversão de StorageClass falha com "current cluster is multi-zoned"?

Em um cluster multizona, se você converter para uma StorageClass do tipo disco cujo volumeBindingMode seja Immediate, o CSI cria o PV em uma zona fixa. Os pods não podem ser agendados em uma zona diferente, ficando em estado Pending.

1. Redefina a tarefa de conversão de StorageClass (use o mesmo comando acima).

2. Selecione a classe de armazenamento correta:

   • Console: Selecione alicloud-disk, que usa a classe de armazenamento alicloud-disk-topology-alltype por padrão.

   • Linha de comando: Use alicloud-disk-topology-alltype. Alternativamente, defina volumeBindingMode como WaitForFirstConsumer para garantir que o PV seja criado na mesma zona do pod.

3. Execute a tarefa de restauração novamente.

Por que minha restauração falha com "multi-node writing is only supported for block volume"?

A aplicação a ser restaurada possui um volume cujo AccessMode é ReadWriteMany ou ReadOnlyMany. Ao restaurar para armazenamento de disco da Alibaba Cloud (que não suporta múltiplas montagens por padrão), o CSI valida a configuração AccessModes dos volumes de disco durante a montagem e bloqueia a operação. Isso impede que o disco seja montado por outro nó durante a montagem, o que causaria desanexação forçada do disco.

Isso ocorre em três cenários:

• Versão antiga do CSI ou FlexVolume no cluster de backup: Versões anteriores do CSI não verificavam AccessModes durante a montagem. O volume falha quando restaurado em um cluster com uma versão mais recente do CSI. A partir da v1.8.4, o componente de backup converte automaticamente os AccessModes de volumes de disco para ReadWriteOnce. Atualize o componente e restaure novamente.

• Classe de armazenamento ausente no cluster de restauração: O volume é associado a um volume de disco da Alibaba Cloud por padrão. Restaurar automaticamente a classe de armazenamento pode causar inacessibilidade ou sobrescrita de dados. Crie uma classe de armazenamento com o mesmo nome no cluster de restauração antes de restaurar, ou use a conversão de StorageClass para especificar o destino.

• Conversão manual de StorageClass para disco: Adicione o parâmetro convertToAccessModes para converter AccessModes para ReadWriteOnce. Consulte convertToAccessModes.

Por que minha restauração falha com "only disk type PVs support cross-region restore in current version"?

A restauração entre regiões é suportada apenas para volumes de disco (migrate-controller 1.7.7 e posterior). Para outros tipos de armazenamento que suportam acesso à Internet (como OSS), crie um PV e PVC provisionados estaticamente e restaure a aplicação. Consulte Usar um volume provisionado estaticamente ossfs 1,0.

Por que minha restauração falha com "ECS snapshot cross region request failed"?

A restauração entre regiões para volumes de disco requer permissões de snapshot de disco ECS, que não são concedidas por padrão para todos os tipos de cluster.

Para clusters dedicados ACK e clusters registrados conectados a Kubernetes autogerenciado implantado em instâncias ECS, conceda permissões de snapshot de disco ECS. Consulte Cluster registrado.

Por que minha restauração falha com "accessMode of PVC xxx is xxx"?

O volume de disco sendo restaurado tem um AccessMode de ReadOnlyMany ou ReadWriteMany. O CSI aplica as seguintes regras:

• Apenas volumes com multiAttach habilitado podem ser montados em múltiplas instâncias.

• Volumes com VolumeMode: Filesystem (ext4 ou xfs) só podem ser montados em múltiplas instâncias no modo somente leitura.

Duas abordagens recomendadas:

• Se estiver convertendo um volume de montagem múltipla (como OSS ou NAS) para armazenamento de disco, crie uma nova tarefa de restauração e selecione alibabacloud-cnfs-nas como destino para conversão de StorageClass. Isso usa um volume NAS gerenciado por CNFS, que suporta múltiplas montagens. Consulte Usar CNFS para gerenciar sistemas de arquivos NAS (recomendado).

• Se o PV de disco do backup não atender aos requisitos atuais do CSI (backup feito quando a versão do CSI era inferior e a detecção de AccessMode não era aplicada), migre suas cargas de trabalho para usar volumes de disco provisionados dinamicamente para evitar desanexação forçada de disco durante o agendamento.

Meu status de restauração é Completed, mas alguns recursos estão ausentes. Por quê?

O status Completed não garante que todos os recursos foram restaurados. Verifique cada causa possível:

O recurso não teve backup. Execute o comando a seguir para inspecionar o backup:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe backup <backup-name> --details

Recursos no nível de cluster de pods executando em namespaces não selecionados para backup não têm backup por padrão. Para configuração de backup no nível de cluster, consulte Backup no nível de cluster.

O recurso foi excluído durante a restauração. Verifique se o namespace, tipo de recurso ou outros filtros na tarefa de restauração excluíram o recurso e execute a restauração novamente.

A subtarefa de restauração falhou parcialmente. Execute o comando a seguir para identificar falhas:

kubectl -n csdr exec -it $(kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1) -- ./velero describe restore <restore-name>

Corrija os problemas nos campos Errors e Warnings.

O recurso foi reciclado após a criação. Verifique os logs de auditoria do recurso para determinar se ele foi excluído após ser criado, devido a ownerReferences ou lógica de negócios.

O componente migrate-controller em um cluster FlexVolume não inicia

O componente migrate-controller não suporta clusters FlexVolume. Migre para CSI antes de usar o backup center:

• Migrar de FlexVolume para CSI usando o componente csi-compatible-controller

• Migrar FlexVolume sem cluster de armazenamento para CSI

• Migrar volumes NAS provisionados estaticamente de FlexVolume para CSI

• Migrar volumes OSS provisionados estaticamente de FlexVolume para CSI

• Para outros casos, entre em contato conosco no grupo DingTalk (ID: 35532895).

Para fazer backup de aplicações em um cluster FlexVolume e restaurá-las em um cluster CSI durante a migração, consulte Usar o backup center para migrar aplicações em um cluster Kubernetes que executa uma versão mais antiga.

Posso modificar um backup vault?

Não. Para fazer alterações, exclua o backup vault atual e crie um novo com um nome diferente.

Como um backup vault é um recurso compartilhado que pode estar em uso ativo a qualquer momento, modificar seus parâmetros arrisca a inacessibilidade dos dados durante backups ou restaurações em andamento. Você também não pode criar um novo vault com o mesmo nome de um excluído.

Posso usar um bucket OSS cujo nome não esteja no formato cnfs-oss-*?

Para clusters que não sejam clusters dedicados ACK e clusters registrados, o backup center tem acesso de leitura/gravação a buckets OSS nomeados no formato cnfs-oss-* por padrão. Usar um bucket com nome diferente requer configuração adicional. Para evitar que backups sobrescrevam dados existentes em um bucket, crie um bucket OSS dedicado nomeado no formato cnfs-oss-* para o backup center.

1. Configure permissões OSS para o componente. Consulte Cluster dedicado ACK.

2. Reinicie o componente de service de backup:

   kubectl -n csdr delete pod -l control-plane=csdr-controller
   kubectl -n csdr delete pod -l component=csdr

Após criar um vault com um nome de bucket não padrão, aguarde a conclusão da verificação de conectividade (aproximadamente cinco minutos) antes de iniciar operações de backup ou restauração. Verifique o status do vault:

kubectl -n csdr get backuplocation

Saída esperada:

NAME                    PHASE       LAST VALIDATED   AGE
a-test-backuplocation   Available   7s               6d1h

Como especifico a programação de backup ao criar um plano de backup?

A programação de backup suporta dois formatos:

• Expressão Cron: Por exemplo, 1 4 * * * executa um backup às 04:01 todos os dias.

• Intervalo: Por exemplo, 6h30m executa um backup a cada 6 horas e 30 minutos.

Referência de formato Cron:

 *  *  *  *  *
 |  |  |  |  |
 |  |  |  |  ·----- day of week (0 - 6, Sun to Sat)
 |  |  |  ·-------- month (1 - 12)
 |  |  .----------- day of month (1 - 31)
 |  ·-------------- hour (0 - 23)
 ·----------------- minute (0 - 59)

Exemplo: 0 2 15 * 1 executa um backup às 02:00 no dia 15 de cada mês.

Quais alterações uma tarefa de restauração faz nos recursos YAML do backup?

As tarefas de restauração fazem os seguintes ajustes automáticos:

Tamanho do volume de disco: Se um volume de disco for menor que 20 GiB, o tamanho é aumentado para 20 GiB.

Serviços: Restaurados com base no tipo de Service:

• Serviços NodePort: As portas de service são mantidas por padrão durante a restauração entre clusters.

• Serviços LoadBalancer:

  • Quando ExternalTrafficPolicy é Local, HealthCheckNodePort usa uma porta aleatória. Para manter a porta original, defina spec.preserveNodePorts: true na tarefa de restauração.

  • Se o Service usa uma instância Server Load Balancer (SLB) existente do cluster de backup, o Service restaurado usa a mesma instância SLB, mas desativa seus listeners. Configure os listeners no console SLB.

  • Se a instância SLB é gerenciada pelo Cloud Controller Manager (CCM) no cluster de backup, o CCM cria uma nova instância SLB. Consulte Considerações para configurar um Service LoadBalancer.

Como visualizo os recursos em um backup?

Backups de aplicações do cluster:

Execute em um cluster que tenha os arquivos de backup sincronizados:

kubectl -n csdr get pod -l component=csdr | tail -n 1 | cut -d ' ' -f1
kubectl -n csdr exec -it csdr-velero-xxx -c velero -- ./velero describe backup <backup-name> --details

Ou use o console ACK: acesse seu cluster > Operations > Application Backup > Backup Records e clique em um registro de backup.

Backups de volumes de disco:

No console ECS, acesse Storage & Snapshots > Snapshots e consulte snapshots por ID do disco.

Backups de volumes não-disco:

No console do Cloud Backup, acesse Backup > Container Backup e selecione a região. A aba Clusters lista os clusters com backup e seus PVCs. A aba Backup Jobs mostra o status das tarefas.

Se Client Status estiver anormal, o Cloud Backup não está executando corretamente no cluster ACK. Acesse a página DaemonSets no console ACK para solucionar problemas.

Posso fazer backup de uma versão mais antiga do Kubernetes e restaurar em uma versão mais nova?

Sim. Por padrão, todas as versões de API suportadas por um recurso têm backup. Por exemplo, um Deployment no Kubernetes 1.16 suporta extensions/v1beta1, apps/v1beta1, apps/v1beta2 e apps/v1. Todas as quatro versões são armazenadas no backup vault, independentemente de qual versão foi usada para criá-lo. O recurso KubernetesConvert lida com a conversão de versão da API durante a restauração.

Ao restaurar, a versão da API recomendada pelo cluster de restauração é usada. Por exemplo, restaurar para Kubernetes 1.28 usa apps/v1 para Deployments.

O tráfego é alternado automaticamente para instâncias SLB durante a restauração?

Não. Após a restauração, os listeners do SLB são desativados ou uma nova instância SLB é criada (dependendo da configuração original). O tráfego não é alternado automaticamente.

Se você usa outros mecanismos de descoberta de service e deseja controlar quando o tráfego é alternado, exclua recursos Service durante o backup e implante-os manualmente quando estiver pronto para alternar.

Por que os recursos em csdr, ack-csi-fuse, kube-system, kube-public e kube-node-lease não têm backup por padrão?

• csdr: Este é o namespace próprio do backup center. Fazer backup dele diretamente faria com que os componentes falhassem no cluster de restauração. A sincronização de backup é tratada automaticamente — você não precisa migrar backups manualmente.

• ack-csi-fuse: Este namespace executa pods de cliente FUSE mantidos pelo CSI. O CSI no novo cluster sincroniza automaticamente esses clientes durante a restauração de armazenamento.

• kube-system, kube-public, kube-node-lease: Estes são namespaces de sistema do Kubernetes. Devido a diferenças em parâmetros e configurações de cluster, a restauração desses namespaces entre clusters não é suportada. Fazer backup direto de componentes do sistema kube-system em um novo cluster pode causar mau funcionamento. Antes de executar uma tarefa de restauração, instale e configure componentes de sistema no cluster de restauração manualmente — por exemplo, o componente de pull de imagens sem senha do Container Registry (acr-configuration) e o componente ALB Ingress (ALBConfig).

O backup center usa snapshots de disco ECS para volumes de disco? Qual é o tipo de snapshot padrão?

O backup center usa snapshots de disco ECS por padrão nos seguintes cenários:

• O cluster é um cluster gerenciado ou dedicado ACK.

• O cluster executa Kubernetes 1.18 ou posterior e usa CSI 1.18 ou posterior.

Em outros cenários, o Cloud Backup é usado para backup de dados de disco.

Os snapshots de disco ECS criados pelo backup center têm o recurso de acesso instantâneo habilitado por padrão. O período de validade do snapshot corresponde ao período de validade especificado na configuração de backup. A partir de 12 de outubro de 2023, 11:00, a Alibaba Cloud não cobra mais por armazenamento ou operações de acesso instantâneo de snapshot em nenhuma região. Consulte Usar o recurso de acesso instantâneo.

Por que o período de validade do snapshot de disco ECS é diferente do que especifiquei na configuração de backup?

A configuração do período de validade depende do componente csi-provisioner. Se o csi-provisioner for anterior à versão 1.20.6, os VolumeSnapshots são criados sem as configurações de período de validade ou acesso instantâneo — portanto, a configuração de backup não afeta os snapshots de disco.

Atualize o csi-provisioner para 1.20.6 ou posterior para garantir que o período de validade seja aplicado corretamente.

Se a atualização não for possível, configure um período de validade padrão de snapshot:

1. Atualize o migrate-controller para v1.7.10 ou posterior.

2. Verifique se existe um VolumeSnapshotClass com a configuração de retenção de 30 dias:

   kubectl get volumesnapshotclass csdr-disk-snapshot-with-default-ttl

3. Se não existir, ou se existir mas retentionDays não estiver definido como 30, aplique o seguinte:

   apiVersion: snapshot.storage.k8s.io/v1
   deletionPolicy: Retain
   driver: diskplugin.csi.alibabacloud.com
   kind: VolumeSnapshotClass
   metadata:
     name: csdr-disk-snapshot-with-default-ttl
   parameters:
     retentionDays: "30"

Todos os backups de volumes de disco no cluster criarão snapshots com o período de retenção definido em retentionDays.

O que é backup de dados de volume e quando preciso dele?

O que faz: O backup de dados de volume copia dados de volume para armazenamento em nuvem usando snapshots de disco ECS ou Cloud Backup. Quando você restaura a aplicação, um novo disco ou sistema de arquivos NAS é criado a partir dessa cópia. A aplicação restaurada e a aplicação original têm dados independentes — alterações em uma não afetam a outra.

Se você não precisa de uma cópia de dados ou de uma source de dados compartilhada, pode pular o backup de dados de volume. Os arquivos YAML de PVC e PV ainda são incluídos no backup da aplicação por padrão. Garanta que os recursos PVC e PV não estejam na lista de exclusão de backup para que, durante a restauração, os volumes sejam implantados no novo cluster a partir de seu YAML original.

Quando usar:

• Recuperação de desastres ou registros de dados versionados são necessários.

• A aplicação usa volumes de disco (discos básicos só podem ser montados em um único nó).

• Backup e restauração entre regiões são necessários (a maioria dos tipos de armazenamento, exceto OSS, não suporta acesso entre regiões).

• Isolamento de dados entre as aplicações original e restaurada é necessário.

• Os plug-ins de armazenamento ou versões diferem significativamente entre os clusters de backup e restauração, tornando a restauração direta de YAML impraticável.

Riscos de não fazer backup de volumes para aplicações stateful:

• Volumes com política de recuperação Delete : O CSI cria um novo PV vazio durante a restauração. Volumes provisionados estaticamente sem uma classe de armazenamento correspondente permanecem em Pending até que você crie manualmente um PV ou classe de armazenamento.

• Volumes com política de recuperação Retain : Os recursos são restaurados na ordem PV-primeiro. Para armazenamento de montagem múltipla (NAS, OSS), o sistema de arquivos ou bucket original é reutilizado. Para discos, há risco de desanexação forçada de disco.

Para verificar a política de recuperação de seus volumes:

kubectl get pv -o=custom-columns=CLAIM:.spec.claimRef.name,NAMESPACE:.spec.claimRef.namespace,NAME:.metadata.name,RECLAIMPOLICY:.spec.persistentVolumeReclaimPolicy

Como seleciono nós para backups de sistema de arquivos na proteção de dados?

Por padrão, as tarefas do Cloud Backup podem ser executadas em qualquer nó, exceto nós virtuais. Apenas uma tarefa de backup de volume é executada em um nó por vez.

Três políticas de agendamento de nós estão disponíveis:

Para rotular um nó:

# Exclude a node
kubectl label node <node-name> csdr.alibabacloud.com/agent-excluded="true"

# Include a node (for the include policy)
kubectl label node <node-name> csdr.alibabacloud.com/agent-included="true"

Para alterar a política, edite o ConfigMap csdr-config:

kubectl -n csdr edit cm csdr-config

Adicione node_schedule_policy à seção applicationBackup:

apiVersion: v1
data:
  applicationBackup: |
    backup_max_worker_num: 15
    restore_max_worker_num: 5
    delete_max_worker_num: 30
    schedule_max_worker_num: 20
    convert_max_worker_num: 15
    node_schedule_policy: include  # Valid values: include, exclude, prefer
  pvBackup: |
    batch_snapshot_max_num: 20
    enable_ecs_snapshot: "true"
kind: ConfigMap

Reinicie o controlador para que a alteração tenha efeito:

kubectl -n csdr delete pod -lapp=csdr-controller

Quais são as diferenças entre backup de aplicação e proteção de dados?

O backup de aplicação faz backup de cargas de trabalho Kubernetes — incluindo aplicações, Services e arquivos de configuração em namespaces. Opcionalmente, inclua dados de volume para volumes montados. Use o backup de aplicação para migrar aplicações entre clusters ou restaurar aplicações para recuperação de desastres.

O backup de aplicação não faz backup de volumes que não estão montados em pods. Para fazer backup de todos os volumes, crie tarefas de backup de proteção de dados.

A proteção de dados faz backup de volumes de armazenamento — PVCs e PVs — independentemente das cargas de trabalho da aplicação. Use a proteção de dados para restaurar um PVC excluído como uma operação independente, ou para implementar replicação de dados e recuperação de desastres na camada de armazenamento.

Como excluo persistent volumes específicos do backup e recuperação?

Alguns volumes, como armazenamento de logs ou armazenamento de alta disponibilidade (OSS), não precisam de backup. Aqui está um fluxo de trabalho para fazer backup de um namespace que contém o Volume A (sem necessidade de backup) e o Volume B (backup necessário):

Fluxo de backup:

1. Use proteção de dados para fazer backup do Volume B — isso faz backup tanto do YAML quanto dos dados.

2. Use backup de aplicação para selecionar o namespace com Volume Backup definido como Disable. Isso faz backup dos arquivos YAML tanto do Volume A quanto do Volume B sem copiar dados.

   Se você não quiser que o Volume A seja restaurado no cluster de destino, adicione pvc, pv a Excluded Resources na configuração avançada.

Fluxo de restauração:

1. Restaure o backup de proteção de dados no cluster de destino. Isso restaura o YAML e os dados do Volume B.

2. Restaure o backup de aplicação no cluster de destino. Isso restaura o YAML do Volume A e todos os outros recursos da aplicação. O CSI então cria uma nova source de armazenamento ou reutiliza a existente com base na política de recuperação do Volume A.

Após a conclusão de ambas as restaurações, a aplicação, o Volume A e o Volume B (com seus dados) estarão todos em execução no cluster de destino.

O backup center suporta criptografia KMS para o bucket OSS associado?

O backup center suporta criptografia no lado do servidor para buckets OSS. Habilite-a no console OSS. Consulte Criptografia no lado do servidor.

Se você usar uma CMK gerenciada pelo KMS (bring your own key, ou BYOK) com um ID CMK especificado, conceda permissões ao backup center para acessar o KMS:

1. Crie uma política de permissão personalizada:

   {
     "Version": "1",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "kms:List*",
           "kms:DescribeKey",
           "kms:GenerateDataKey",
           "kms:Decrypt"
         ],
         "Resource": [
           "acs:kms:*:141661496593****:*"
         ]
       }
     ]
   }

   Isso concede acesso a todas as chaves KMS sob a conta Alibaba Cloud. Para controle de recursos mais granular, consulte Informações de autorização.

2. Anexe a política:

   • Para clusters dedicados ACK e clusters registrados: anexe-a ao usuário RAM usado durante a instalação. Consulte Conceder permissões a um usuário RAM.

   • Para outros clusters: anexe-a à função AliyunCSManagedBackupRestoreRole. Consulte Conceder permissões a uma função RAM.

Se você usar uma chave KMS gerenciada pelo OSS ou uma chave totalmente gerenciada pelo OSS, nenhuma permissão adicional é necessária.

Como altero as imagens de contêiner usadas durante a restauração?

Alterar o endereço do registro de imagens:

Para implantações em nuvem híbrida ou migrações de on-premises para nuvem, use o campo imageRegistryMapping para remapear endereços de registro de imagens. Por exemplo, para alterar docker.io/library/ para registry.cn-beijing.aliyuncs.com/my-registry/:

docker.io/library/: registry.cn-beijing.aliyuncs.com/my-registry/

Alterar o repositório ou versão da imagem:

Crie um ConfigMap no namespace csdr antes de executar a restauração:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <configuration-name>
  namespace: csdr
  labels:
    velero.io/plugin-config: ""
    velero.io/change-image-name: RestoreItemAction
data:
  "case1": "app1:v1,app2:v2"
  # Change only the repository: "case1": "app1,app2"
  # Change only the version: "case1": "v1:v2"
  # Change a specific registry image: "case1": "docker.io/library/app1:v1,registry.cn-beijing.aliyuncs.com/my-registry/app2:v2"

Para múltiplas alterações, adicione case2, case3 e assim por diante ao campo data. Após criar o ConfigMap, execute a tarefa de restauração com o campo imageRegistryMapping deixado em branco.

Essas alterações se aplicam a todas as tarefas de restauração no cluster. Use padrões específicos (como limitar a um registro específico) para evitar alterações não intencionais. Exclua o ConfigMap quando não for mais necessário.

Como ajusto os recursos disponíveis para os subcomponentes no namespace csdr?

A configuração padrão de recursos do csdr-controller é:

resources:
  limits:
    cpu: "1"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

A configuração padrão de recursos do csdr-velero é:

resources:
  limits:
    cpu: "1"
    memory: 2Gi
  requests:
    cpu: 500m
    memory: 128Mi

As configurações de Deployment do csdr-controller e csdr-velero, incluindo seus recursos, são gerenciadas pelo componente migrate-controller no namespace kube-system. Editá-los diretamente resulta em reversão. Para alterar a configuração de recursos, adicione os seguintes parâmetros aos args do contêiner migrate-controller:

name: migrate-controller
args:
  - --velero-pod-cpu-limit=500m
  - --velero-pod-mem-limit=512Mi
  - --velero-pod-cpu-request=250m
  - --velero-pod-mem-request=256Mi
  - --csdr-pod-cpu-limit=500m
  - --csdr-pod-mem-limit=512Mi
  - --csdr-pod-cpu-request=250m
  - --csdr-pod-mem-request=256Mi

Cada parâmetro é opcional. Parâmetros omitidos mantêm seus valores padrão. Certifique-se de que cada limite seja maior ou igual à solicitação correspondente.

Em clusters grandes, reduzir velero-pod-mem-limit pode fazer com que o csdr-velero fique sem memória durante a inicialização e restauração. Considere configurar o parâmetro disable-informer-cache em vez disso. Consulte Why is my job stuck in InProgress?