e-backup (EOM)

Introdução

O complemento e-backup oferece backup e restauração de cluster. Ele faz backup de dados de aplicações e dados de serviço para o OBS e fornece backup de dados locais e remotos.

Restrições

• Não adicione, exclua ou modifique o cluster durante o backup/restauração. Caso contrário, o backup/restauração pode falhar ou ficar incompleto.
• Se alterar o cluster, é recomendável aguardar 15 minutos até que o cluster esteja estável e, em seguida, executar a operação de backup.
• Quando os snapshots de disco EVS são usados para backup, apenas os PVs do EVS são suportados e as restrições de snapshot se aplicam (por exemplo, a restauração entre AZs não é suportada). O preço é o mesmo dos snapshots de disco EVS.
• Quando restic é usado para backup, os dados dos PVs do EVS, SFS, SFS Turbo e OBS são copiados e carregados no repositório de backup do OBS.
• restic cria um snapshot para os dados no ponto de tempo de backup e carrega os dados, o que não afeta a leitura e a gravação de dados subsequentes. No entanto, restic não verifica o conteúdo do arquivo e a consistência do serviço. Aplicam-se restrições de restic.
• A memória ocupada pelo restic está relacionada ao tamanho dos dados de PV copiados pela primeira vez. Se o tamanho dos dados for maior que 500 GB, é recomendável usar os métodos de migração fornecidos pelos serviços de armazenamento em nuvem. Se você usar este complemento, poderá modificar as cotas de recursos do contêiner de restic consultando o guia de operação.
• Você pode usar Hooks para garantir a consistência dos dados de serviço para aplicações com estado durante o backup, por exemplo, sincronizando dados de memória para arquivos.
• Durante a restauração, você pode ajustar as configurações para se adaptar às diferenças de ambiente antes e depois da migração.
  • Uma aplicação pode ser restaurada do namespace original para outro namespace especificado. No entanto, confirme se a aplicação não é acessada por meio de um Serviço fixo durante a restauração.
  • Você pode alterar o endereço de imagem (repo) da aplicação para outro caminho de imagem. O nome e a tag da imagem permanecem inalterados durante a restauração.
  • Você pode alterar o nome da classe de armazenamento usada pela aplicação para uma nova. Observe que os recursos de armazenamento de back-end devem ser do mesmo tipo, por exemplo, de armazenamento em bloco para armazenamento em bloco.
• Aplicam-se restrições Velero e restic. Por exemplo, durante a restauração, o Serviço limpará o ClusterIP para se adaptar melhor às diferenças entre os clusters do Kubernetes de origem e de destino.

Instalar o complemento

1. Efetue logon no console do CCE. No painel de navegação, escolha Add-ons. Localize o complemento e-backup e clique em Install.
2. Na página Install Add-on, selecione o cluster, defina parâmetros e clique em Install.

   O seguinte parâmetro é suportado:

   volumeWorkerNum: número de tarefas de backup de volume simultâneas. O valor padrão é 3.

Usar o complemento

O e-backup usa buckets do OBS como local de armazenamento de backup. Antes de fazer backup dos dados, execute operações em Preparar chaves e Criar um local de armazenamento.

Os backups podem ser imediatos e agendados. As restaurações podem ser imediatos.

Preparar chaves

1. Obtenha uma chave de acesso.

   Faça logon no console do CCE, mova o cursor para o nome de usuário no canto superior direito e escolha My Credentials. No painel de navegação à esquerda, escolha Access Keys. Na página exibida, clique em Add Access Key.

2. Crie um arquivo de chave e formatá-lo em uma cadeia usando Base64.

   # Create a key file.
   $ vi credential-for-huawei-obs
   HUAWEI_CLOUD_ACCESS_KEY_ID=your_access_key
   HUAWEI_CLOUD_SECRET_ACCESS_KEY=your_secret_key
   
   # Use Base64 to format the string.
   $ base64 -w 0 credential-for-huawei-obs
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHWOBS

3. Crie um segredo.
   Crie um segredo usando o seguinte conteúdo de YAML:

   apiVersion: v1
   kind: Secret
   metadata:
     labels:
       secret.everest.io/backup: 'true'   # The secret is used by e-backup to access the backup storage location.
     name: secret-secure-opaque
     namespace: velero                  # The value must be velero. The secret must be in the same namespace as e-backup.
   type: cfe/secure-opaque
   data:
     # String obtained after the credential file is Base64-encoded.
     cloud: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHWOBS

   • O segredo deve estar no mesmo namespace do e-backup, ou seja, velero.
   • secret.data armazena o segredo para acessar o OBS. A chave deve ser cloud, e o valor é a cadeia Base64 codificada em 2. Geralmente, a cadeia codificada em Base64 exibida contém quebras de linha. Excluí-las manualmente ao escrever a cadeia em secret.data.
   • O segredo deve ser rotulado secret.everest.io/backup: true, indicando que o segredo é usado para gerenciar o local de armazenamento de backup.

Criar um local de armazenamento

Crie um objeto de recurso do Kubernetes usado pelo e-backup como local de armazenamento de backup para obter e detectar informações sobre o OBS de back-end.

apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: backup-location-001
  namespace: velero            # The object must be in the same namespace as e-backup.
spec:
  config:
    endpoint: obs.{regionname}.myhuaweicloud.com   # OBS endpoint
  credential:
    name: secret-secure-opaque   # Name of the created secret
    key: cloud                   # Key in secret.data
  objectStorage:
    bucket: tools-cce        # OBS bucket name
    prefix: for-backup       #Subpath name
  provider: huawei           # Uses the OBS service.

• O campo prefix é opcional e outros campos são obrigatórios. O valor de provider é fixado em huawei.
• Você pode obter o ponto de extremidade de Regiões e pontos de extremidade. Certifique-se de que todos os nós no cluster possam acessar o ponto de extremidade. Se o ponto de extremidade não carrega um cabeçalho de protocolo (http ou https), https é usado por padrão.
• Defina corretamente name e key na credencial. Caso contrário, o e-backup não poderá acessar o local de armazenamento.

Após a conclusão da criação, aguarde 30 segundos para verificação e sincronização do local de armazenamento de backup. Em seguida, verifique se PHASE está Available. O local está disponível somente quando o valor é Available.

$ kubectl get backupstoragelocations.velero.io backup-location-001 -n velero 
NAME                  PHASE       LAST VALIDATED   AGE   DEFAULT
backup-location-001   Available   23s              23m  

Se PHASE não estiver Available por um longo tempo, você poderá exibir os logs de e-backup para localizar a falha. Depois que o e-backup é instalado, uma carga de trabalho chamada velero é criada no namespace de velero, registrada nos logs do velero.

Backup imediato

O processo de backup começa imediatamente e pára após a conclusão. Esse modo é comumente usado para clonagem e migração.

Você pode usar o manifesto Backup abaixo e executar kubectl create para criar uma tarefa de backup.

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: backup-01
  namespace: velero
spec:
  includedNamespaces:
  - nginx
  - mysql
  labelSelector:
    matchExpressions:
    - key: direction
      operator: In
      values:
      - back
      - front
    matchLabels:
      app: nginx
      backup: velero
  runMode: Normal
  appData:
    volumes: Restic
  hooks:
    resources:
    - name: hook01
      includedNamespaces:
      - nginx
      labelSelector: {}
      pre:
      - exec:
          command:
          - /bin/sh
          - -c
          - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: container-0
          onError: Fail
          timeout: 30s
      post:
      - exec:
          command:
          - /bin/sh
          - -c
          - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: container-0
          onError: Fail
          timeout: 30s
  storageLocation: backup-location-001
  ttl: 720h0m0s

Descrição do parâmetro:

• Parâmetros de backup
  • storageLocation: (obrigatório) nome do local de armazenamento de backup onde os dados a serem copiados são armazenados.
  • ttl: duração para armazenar backups no local, após o qual os backups são excluídos. O valor deve estar no formato especificado. h, m e s indicam hora, minuto e segundo, respectivamente. Por exemplo, 24h indica um dia e 3h4m5s indica três horas, quatro minutos e cinco segundos. O valor padrão é 720h0m0s (30 dias).
• Filtragem de recursos: os seguintes parâmetros são usados como filtros. A interseção desses campos, se todos configurados, é usada para filtrar todos os recursos no cluster.
  • includedNamespaces e excludedNamespaces: se deve fazer backup de recursos em determinados namespaces. Esses dois parâmetros entram em conflito entre si. Escolha um para configurar. Por padrão, todos os namespaces são selecionados.
  • labelSelector: faz backup de recursos com rótulos específicos. O princípio de funcionamento é o mesmo do Kubernetes.
  • runMode: (obrigatório) modo de backup. As opções de valor incluem Normal (fazendo backup de aplicações e dados), AppOnly (fazendo backup de aplicações somente), DataOnly (fazendo backup de dados somente) e DryRun (sem fazer backup de aplicações e dados; apenas para verificação).
• Backup de dados do serviço: os dados de serviço gerados podem ser copiados através de snapshots do Everest (suportado apenas quando os PVs do EVS como os volumes de dados) e backups restic (que fazem backup de todos os volumes de dados, exceto os do hostPath). Esses dois modos podem ser usados juntos.
  • appData: modo de backup de dados de PV. O valor pode ser Restic ou Snapshot (não usado por padrão). O modo Snapshot entra em vigor somente quando o armazenamento suporta snapshots e o plug-in de snapshot de CSI é implementado no cluster.
• hook: os hooks são os comandos executados antes ou depois de um backup para gerenciar com precisão seus backups. Um hook é semelhante ao comando kubectl exec e se aplica apenas a pods.
  • includedNamespaces e excludedNamespaces: se deve executar um gancho em pods em determinados namespaces. Esses dois parâmetros entram em conflito entre si. Escolha um para configurar. Por padrão, todos os namespaces são selecionados.
  • labelSelector: executa um hook em pods com certos rótulos. O princípio de funcionamento é o mesmo do Kubernetes.
  • command: comando a ser executado.
  • container: nome do contêiner no qual o comando é executado. O padrão é o primeiro contêiner quando há vários contêineres no pod.
  • onError: ação a ser tomada quando o hook falha ao ser executado. O valor pode ser Continue ou Fail. Padrão para Fail.
  • Continue indica que as operações subsequentes continuam independentemente das falhas de execução do hook. Fail indica que as operações subsequentes não continuarão após uma falha de execução do hook.
  • timeout: tempo limite de execução do hook, após o qual o hook falha. Padrão para 30s.

  Falhas de hook afetam apenas pods. O backup de outros objetos, como Serviços, não é afetado.

  Os hooks não estão disponíveis globalmente. Se o pod para executar um hook não estiver selecionado como o objeto de backup, o hook não será executado. Pode-se considerar que você filtre ainda mais os objetos a serem copiados por meio de includedNamespaces ou excludedNamespaces.

Todos os itens configuráveis são descritos acima. A seguir, algumas sugestões de configuração de backup.

• Retenha backups por dia (24 horas).
• Use includeNamespace para especificar o escopo de backup porque, na maioria dos casos, as aplicações são implementados em um namespace específico. Use labelSelector para controlar objetos de backup com mais precisão. Antes disso, todos os objetos de destino devem ter rótulos correspondentes. Use includeNamespace e labelSelector juntos pode satisfazer a maioria dos cenários.
• Ao usar o Restic para fazer backup de dados de serviço, se você não estiver familiarizado com o modo OUT/IN, poderá ignorar a adição de anotações aos pods que exigem backup de volume. Em vez disso, defina defaultVolumesToRestic como true para fazer backup dos dados de serviço dos volumes de pod. O valor false indica que não há backups.
• Use hooks para controlar com precisão seus backups. Evite tarefas de longa duração. Não opere diretamente o sistema de arquivos ao executar os comandos no hook.

Backup periódico

O backup dos dados é feito periodicamente conforme configurado. Esse modo é comumente usado para recuperação de desastres.

Você pode usar o manifesto Schedule abaixo e executar o comando kubectl create para criar um cronograma. Você pode rotular o cronograma conforme necessário. Os rótulos que você adicionar no manifesto serão anexados aos backups criados pelo cronograma. Depois que um cronograma é criado em um cluster, um backup é executado imediatamente. Em seguida, os dados são copiados periodicamente, conforme especificado.

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: schedule-backup-001
  namespace: velero
spec:
  schedule: 0 */10 * * *
  template:
    runMode: Normal
    hooks: {}
    includedNamespaces:
    - nginx
    - mysql
    labelSelector:
      matchExpressions:
      - key: direction
        operator: In
        values:
        - back
        - front
      matchLabels:
        app: nginx
        backup: velero
    storageLocation: backup-location-001
    ttl: 720h0m0s

Descrição do parâmetro:

• schedule: tempo de execução de backups periódicos. O formato @every e expressões cron padrão do Linux são suportados.
  • @every NUnit: N é um inteiro positivo. As unidades s, m e h representam segundos, minutos e horas, respectivamente. Por exemplo, @every 2h30m indica que o backup é acionado a cada 2 horas e 30 minutos.
  • Expressão Cron. os cinco valores representam minutos, horas, dia do mês, mês e dia da semana, respectivamente.
• template: manifesto de backup, que é o mesmo que spec em Backup imediato.

Excluir um backup

Você pode excluir os objetos de backup e objetos relacionados (como backups, restaurações e agendamentos) de um cluster e excluir backups do local de armazenamento quando uma grande quantidade de dados de backup é gerada.

Você pode usar o manifesto DeleteBackupRequest abaixo e executar o comando kubectl create para criar uma solicitação de exclusão de backup.

apiVersion: velero.io/v1
kind: DeleteBackupRequest
metadata:
  name: backup-001-delete
  namespace: velero
spec:
  backupName: backup-001  # Name of the backup to be deleted.

Consulte o status.

$ kubectl -n velero get deletebackuprequests backup-001-delete -o yaml | grep " phase"
   phase: InProgress

• InProgress: a tarefa de exclusão está em andamento.
• Processed: a tarefa de exclusão foi processada.

• O estado Processed indica que o e-backup processou a tarefa, mas pode não concluí-la. Você pode verificar os erros no campo deletebackuprequest.status.errors. Se o e-backup processar corretamente e completamente a tarefa de exclusão, o objeto DeleteBackupRequest também será excluído.
• Não exclua manualmente o conteúdo no local de armazenamento (bucket de OBS).

Restauração imediata

Use um backup imediato como fonte de dados e restaure os dados em outro namespace ou cluster. Este modo aplica-se a todos os cenários.

Você pode usar o manifesto Restore abaixo e executar o comando kubectl create para criar uma solicitação de exclusão de backup.

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: restore-01
  namespace: velero
spec:
  backupName: backup-01
  hooks:
    resources:
    - name: restore-hook-1
      includedNamespaces:
      - mysql
      labelSelector: {}
      postHooks:
      - init:
          initContainers:
          - name: restore-hook-init1
            image: alpine:latest
            volumeMounts:
            - mountPath: /restores/pvc1-vm
              name: pvc1-vm
            command:
            - /bin/ash
            - -c
            - echo -n "FOOBARBAZ" >> /restores/pvc1-vm/foobarbaz
          - name: restore-hook-init2
            image: alpine:latest
            volumeMounts:
            - mountPath: /restores/pvc2-vm
              name: pvc2-vm
            command:
            - /bin/ash
            - -c
            - echo -n "DEADFEED" >> /restores/pvc2-vm/deadfeed
      - exec:
          execTimeout: 1m
          waitTimeout: 5m
          onError: Fail
          container: mysql
          command:
          - /bin/bash
          - '-c'
          - 'while ! mysql_isready; do sleep 1; done'
      - exec:
          container: mysql
          waitTimeout: 6m
          execTimeout: 1m
          onError: Continue
          command:
          - /bin/bash
          - '-c'
          - 'mysql < /backup/backup.sql'
  includedNamespaces:
  - nginx
  - mysql
  namespaceMapping:
    nginx: nginx-another
    mysql: mysql-another
  labelSelector: {}
  preserveNodePorts: false
  storageClassMapping:
    disk: csi-disk
    obs: csi-obs
  imageRepositoryMapping:
    quay.io/coreos:  swr.ap-southeast-1.myhuaweicloud.com/everest

Descrição do parâmetro:

• Fonte de dados

  backupName: (obrigatório) backup imediato que é usado como fonte de dados.

• Parâmetros de filtragem de recursos: semelhantes aos de Backup imediato.
• Processamento personalizado
  • namespaceMapping: restaura os dados de backup para outro namespace. O valor é um mapeamento no formato de Source: Target. O novo namespace não precisa existir no cluster de destino.
  • storageClassMapping: altera o storageClassName usado por recursos de backup como PVs e PVCs. Os tipos de storageClass devem ser os mesmos.
  • imageRepositoryMapping: altera o campo images do backup. Ele é usado para mapeamento de repositório, excluindo a alteração do nome da imagem e da tag (para evitar que a migração e a atualização sejam acopladas). Por exemplo, depois de migrar quay.io/coreos/etcd:2.5 para SWR, você pode usar swr.ap-southeast-1.myhuaweicloud.com/everest/etcd:2.5 no repositório de imagens local. O formato de configuração é o seguinte: quay.io/coreos: swr.ap-southeast-1.myhuaweicloud.com/everest
  • preserveNodePorts: se você definir esse parâmetro como false, o sistema preservará apenas as nodePorts configuradas, não as geradas automaticamente pelo Serviço.
• hooks: você pode adicionar init hooks (usados para adicionar initContainers ao pod) e exec hooks (usados para executar alguns comandos). Para obter detalhes sobre como configurar um init hook, consulte a definição de initContainers no Kubernetes. A seguir, descrevemos a configuração geral do hook e os parâmetros de um exec hook.
  • includedNamespaces e excludedNamespaces: se deve executar um gancho em pods em determinados namespaces. Esses dois parâmetros entram em conflito entre si. Escolha um para configurar. Por padrão, todos os namespaces são selecionados.
  • labelSelector: executa um hook em pods com certos rótulos. O princípio de funcionamento é o mesmo do Kubernetes.
  • command: comando a ser executado.
  • container: nome do contêiner no qual o comando é executado. O padrão é o primeiro contêiner quando há vários contêineres no pod.
  • onError: ação a ser tomada quando o hook falha ao ser executado. O valor pode ser Continue ou Fail. Padrão para Fail.
  • Continue indica que as operações subsequentes continuam independentemente das falhas de execução do hook. Fail indica que as operações subsequentes não continuarão após uma falha de execução do hook.
  • execTimeout: tempo limite de execução do hook, após o qual o hook falha. Padrão para 30s.
  • waitTimeout: período de tempo limite desde o momento em que o e-backup se prepara para executar o hook até o momento em que o contêiner começa a executar o hook. Se esse período for excedido, o hook falha. O valor padrão é 0s, indicando que não há limite de tempo limite.

• Selecione uma fonte de dados correta e verifique se o backup está no estado Completed.
• Defina os parâmetros relacionados à filtragem de recursos somente quando necessário.
• Os dados de serviço são restaurados por e-backup com base no modo de backup selecionado. Não são necessárias configurações ou operações manuais.
• Para obter detalhes sobre como usar hooks, consulte as sugestões de uso em Backup imediato. Você pode pular waitTimeout, a menos que necessário.
• É aconselhável restaurar o que foi feito backup em um novo namespace para evitar erros de configuração que possam desabilitar a aplicação restaurada.

Depois que a restauração for concluída, execute os seguintes comandos para exibir o status da restauração (status):

$ kubectl -n velero get restores restore-01 -o yaml | grep " phase"
  phase: Completed

$ kubectl -n velero get restores restore-01 -o yaml
......
status:
  ......

Descrição de status

• FailedValidation: o manifesto de restauração está configurado incorretamente. Verifique Restore.Status.ValidationErrors para encontrar a causa.
• InProgress: a restauração está em andamento.
• Completed: a restauração está concluída e não ocorre nenhum erro.
• PartiallyFailed: a restauração está concluída, mas ocorre um erro (como erro de execução de hook) durante a restauração de determinados objetos.
• Failed: a restauração falha e ocorre um erro que afeta todo o processo.

Verifique os logs, avisos e erros gerados durante a restauração.

Suponha que o nome da restauração é restore-01. Vá para o console do OBS, localize o local de armazenamento com base no nome do bucket configurado e no nome do subcaminho e vá para o diretório restores/restore-01. Os dois arquivos a seguir existem:

• restore-01-logs.gz: arquivo de log, que pode ser baixado, descompactado e visualizado.
• restore-01-results.gz: restaure o arquivo de resultados, incluindo avisos e erros.