Compartilhar via

O que é o backup do Serviço de Kubernetes do Azure?

O backup do AKS (Serviço de Kubernetes do Azure) é um processo simples e nativo de nuvem que você pode usar para fazer backup e restaurar aplicativos e dados em contêineres executados no cluster do AKS. Você pode configurar backups agendados para o estado do cluster e dados de aplicativos armazenados em Volumes Persistentes do Kubernetes em Armazenamento em Disco do Azure baseado no driver da Interface de Armazenamento de Contêiner (CSI).

A solução oferece controle granular. Você pode fazer backup ou restaurar um namespace específico ou um cluster inteiro armazenando backups localmente em um contêiner de blob e como instantâneos de disco. Você pode usar o backup do AKS para cenários de ponta a ponta, incluindo recuperação operacional, clonagem de ambientes de desenvolvedor ou teste e cenários de atualização de cluster.

O backup do AKS se integra ao Centro de Backup no Azure, para fornecer uma única exibição que pode ajudá-lo a controlar, monitorar, operar e analisar backups em escala. Seus backups também estão disponíveis no portal do Azure em Configurações no menu de serviço de uma instância do AKS.

Como funciona o backup do AKS?

Você pode usar o backup do AKS para fazer backup de suas cargas de trabalho do AKS e volumes persistentes implantados em clusters do AKS. A solução requer que a extensão Backup seja instalada dentro do cluster AKS. O cofre de Backup se comunica com a extensão para concluir operações de backup e restauração. O uso da extensão backup é obrigatório. A extensão deve ser instalada dentro do cluster do AKS para habilitar o backup e a restauração para o cluster. Ao configurar o backup do AKS, você adiciona valores para uma conta de armazenamento e um contêiner de blob em que os backups são armazenados.

Juntamente com a extensão de Backup, uma identidade de utilizador (chamada identidade de extensão) é criada no grupo de recursos gerenciados do cluster AKS. A identidade da extensão é atribuída à função Colaborador da Conta de Armazenamento na conta de armazenamento em que os backups são armazenados em um contêiner de blob.

Para dar suporte a clusters públicos, privados e autorizados baseados em IP, o backup do AKS requer que você habilite o recurso de Acesso Confiável entre o cluster do AKS e o cofre de Backup. O Acesso Confiável permite que o cofre de Backup acesse o cluster do AKS porque permissões específicas são atribuídas a ele para operações de backup. Para obter mais informações sobre o Acesso Confiável do AKS, confira Habilitar recursos do Azure para acessar clusters do AKS usando o Acesso Confiável.

O backup do AKS permite armazenar backups tanto no Nível Operacional quanto no Nível de Cofre. A Camada Operacional é um armazenamento de dados local (os backups são armazenados em seu locatário como instantâneos). Agora você pode mover um ponto de recuperação por dia e armazená-lo no Nível de Cofre como um blob (fora do seu locatário) usando o backup do AKS. Os backups armazenados no Nível de Cofre também podem ser usados para restaurar dados em uma região secundária (região emparelhada do Azure).

Depois de instalar a extensão de Backup e habilitar o Acesso Confiável, você poderá configurar backups agendados para os clusters de acordo com sua política de backup. Você também pode restaurar os backups para o cluster original ou para um cluster diferente na mesma assinatura e região. Ao configurar a operação específica, você pode escolher um namespace específico ou um cluster inteiro como uma configuração de backup e restauração.

O backup do AKS permite operações de backup para suas fontes de dados do AKS implantadas no cluster. Ele também habilita operações de backup para os dados armazenados no Volume Persistente para o cluster. Em seguida, ele armazena os backups em um contêiner de blob. Os Volumes Persistentes baseados em disco são copiados como instantâneos de disco em um grupo de recursos de instantâneos. Os instantâneos e o estado do cluster em um blob se combinam para formar um ponto de recuperação chamado Nível Operacional armazenado no seu locatário. Você também pode converter backups (o primeiro backup bem-sucedido do dia, semana, mês ou ano) no Nível Operacional em blobs e movê-los para um cofre (fora do seu locatário) uma vez por dia.

Observação

Atualmente, o Backup do Azure dá suporte apenas a Volumes Persistentes no Armazenamento de Disco do Azure baseado em driver do CSI. Durante os backups, a solução ignora outros tipos de volumes persistentes, como compartilhamentos de Arquivos do Azure e blobs. Além disso, se você definir regras de retenção para o Nível de Cofre, os backups só poderão ser movidos para o cofre se os Volumes Persistentes forem menores ou iguais a 1 TB.

Configurar o backup

Para configurar backups para clusters do AKS, primeiro crie um cofre de Backup. O cofre oferece uma visão consolidada dos backups configurados em diferentes fontes de dados. O backup do AKS dá suporte a backups tanto para o Nível Operacional quanto para o Nível de Cofre.

A configuração de redundância de armazenamento do cofre de Backup (armazenamento com redundância local ou GRS) só se aplica a backups armazenados no Nível de Cofre. Se você quiser usar backups para recuperação de desastre, defina a redundância de armazenamento como GRS com a Restauração Entre Regiões habilitada.

Observação

O cofre de Backup e o cluster do AKS que você quer copiar ou restaurar precisam estar na mesma região e assinatura.

O backup do AKS dispara automaticamente um trabalho de backup agendado. O trabalho copia os recursos do cluster para um contêiner de blob e cria um instantâneo incremental dos Volumes Persistentes baseados em disco de acordo com a frequência de backup. Os backups são retidos no Nível Operacional e no Nível de Cofre de acordo com a duração de retenção definida na política de backup. Os backups são excluídos quando a duração acaba.

Você pode usar o backup do AKS para criar várias instâncias de backup para um único cluster do AKS usando diferentes configurações de backup de acordo com a instância de backup. No entanto, recomendamos que você crie cada instância de backup de um cluster do AKS de uma das duas maneiras a seguir:

  • Em um cofre de Backup diferente
  • Usando uma política de backup separada no mesmo cofre de Backup

Gerenciar backups

Quando a configuração de backup de um cluster do AKS é concluída, uma instância de backup é criada no cofre de Backup. Você pode exibir a instância de backup do cluster na seção Backup de uma instância do AKS no portal do Azure. Você pode executar qualquer operação relacionada ao backup para a instância, como iniciar restaurações, monitorar, interromper a proteção e assim por diante, por meio da sua instância de backup correspondente.

O backup do AKS também se integra diretamente ao Centro de Backup para ajudá-lo a gerenciar centralmente a proteção para todos os clusters do AKS e outras cargas de trabalho com suporte de backup. O centro de backup fornece uma única exibição para todos os seus requisitos de backup, como trabalhos de monitoramento e o estado de backups e restaurações. O centro de backup ajuda a garantir a conformidade e a governança, analisar o uso do backup e executar operações críticas para fazer backup e restaurar dados.

O backup do AKS usa a identidade gerenciada para acessar outros recursos do Azure. Para configurar o backup de um cluster do AKS e restaurar de um backup anterior, a identidade gerenciada do cofre de Backup requer um conjunto de permissões no cluster do AKS. Ele também requer um conjunto de permissões no grupo de recursos de snapshots onde os snapshots são criados e gerenciados. Atualmente, o cluster do AKS requer um conjunto de permissões no grupo de recursos do instantâneo.

Além disso, a extensão de Backup cria uma Identidade de usuário e atribui um conjunto de permissões para acessar a conta de armazenamento onde os backups são armazenados em um blob. Você pode conceder permissões à identidade gerenciada usando o controle de acesso baseado em função do Azure. Uma identidade gerenciada é um tipo especial de princípio de serviço que só pode ser usado com recursos do Azure. Saiba mais sobre identidades gerenciadas.

Restaurar de um backup

Você pode restaurar dados de qualquer ponto no tempo para o qual um ponto de recuperação existe. Um ponto de recuperação é criado quando uma instância de backup está em um estado protegido. Ele pode ser usado para restaurar dados até que a política de backup retenha os dados.

O Backup do Azure oferece a opção de restaurar todos os itens que têm backup ou usar controles granulares para selecionar itens específicos dos backups usando namespaces e outras opções de filtro. Além disso, você pode fazer a restauração no cluster original do AKS (o cluster de backup) ou em um cluster alternativo do AKS. Você pode restaurar backups armazenados no Nível Operacional e no Nível de Cofre para um cluster na mesma assinatura ou em uma assinatura diferente. Somente os backups armazenados no Nível de Cofre podem ser usados para fazer uma restauração em um cluster em uma região diferente (região emparelhada do Azure).

Para restaurar um backup armazenado no Nível de Cofre, você deve fornecer um local de preparo onde os dados de backup são hidratados. Essa localização de preparo inclui um grupo de recursos e uma conta de armazenamento na mesma região e assinatura que o cluster de destino para restauração. Durante a restauração, recursos específicos (contêiner de blob, disco e instantâneos de disco) são criados como parte da hidratação. Eles são limpos após a conclusão da operação de restauração.

No momento, o Backup do Azure para AKS dá suporte às duas opções a seguir para um cenário em que ocorre um conflito de recursos. Um conflito de recursos ocorre quando um recurso de backup tem o mesmo nome do recurso no cluster do AKS de destino. Você pode escolher uma dessas opções ao definir a configuração de restauração.

  • Ignorar: esta opção é selecionada por padrão. Por exemplo, se você fizer backup de uma Declaração de Volume Persistente (PVC) chamada pvc-azuredisk e restaurá-la em um cluster de destino que tenha uma PVC com o mesmo nome, a extensão de backup ignorará a restauração da PVC com backup. Nesses cenários, recomendamos que você exclua o recurso do cluster. Em seguida, faça a operação de restauração para que os itens com backup estejam disponíveis apenas no cluster e não sejam ignorados.

  • Patch: essa opção permite a variável mutável de aplicação de patch no recurso de backup no recurso no cluster de destino. Se você quiser atualizar o número de réplicas no cluster de destino, poderá optar pela aplicação de patch como uma operação.

Observação

No momento, o backup do AKS não excluirá e recriará os recursos no cluster de destino se eles já existirem. Se você tentar restaurar Volumes Persistentes no local original, exclua os Volumes Persistentes existentes e faça a operação de restauração.

Usar ganchos personalizados para backup e restauração

Você pode usar ganchos personalizados para obter instantâneos consistentes de aplicativos de volumes usados ​​para bancos de dados implantados como cargas de trabalho em contêineres.

O que são os ganchos personalizados?

Você pode usar o backup do AKS para executar ganchos personalizados como parte de uma operação de backup e restauração. Os ganchos são configurados para executar um ou mais comandos em um pod dentro de um contêiner durante uma operação de backup ou após a restauração.

Você define esses ganchos como um recurso personalizado e os implanta no cluster AKS do qual deseja fazer backup ou restaurar. Quando o recurso personalizado é implantado no cluster do AKS no namespace necessário, você fornece os detalhes como entrada para o fluxo de configuração de backup e restauração. A extensão Backup executa os ganchos conforme definido em um arquivo YAML.

Observação

Os ganchos não são executados em um shell nos contêineres.

O backup no AKS tem dois tipos de ganchos:

  • Ganchos de backup
  • Ganchos de restauração

Ganchos de backup

Ao usar um gancho de backup, você pode configurar os comandos para executar o gancho antes de qualquer processamento de ação personalizado (PreHooks). Você também pode executar o gancho após todas as ações personalizadas serem concluídas e quaisquer itens adicionais especificados por ações personalizadas serem copiados (PostHooks).

Por exemplo, aqui está o modelo YAML para um recurso personalizado a ser implantado usando ganchos de backup:

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
  # BackupHook CR Name and Namespace
  name: bkphookname0
  namespace: default
spec:
  # BackupHook is a list of hooks to execute before and after backing up a resource.
  backupHook:
    # BackupHook Name. This is the name of the hook that will be executed during backup.
    # compulsory
  - name: hook1
    # Namespaces where this hook will be executed.
    includedNamespaces: 
    - hrweb
    excludedNamespaces:
    labelSelector:
    # PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
    preHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute.
          command:
            - /bin/uname
            - -a
          # OnError specifies how Velero should behave if it encounters an error executing this hook  
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          timeout: 10s
      - exec:
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: webcontainer
          onError: Continue
    # PostHooks is a list of BackupResourceHooks to execute after backing up an item.
    postHooks:
      - exec:
          container: webcontainer
          command:
            - /bin/uname
            - -a
          onError: Continue
          timeout: 10s

Ganchos de restauração

No script do gancho de restauração, os comandos ou scripts personalizados são gravados para serem executados em contêineres de um pod do AKS.

Veja o modelo YAML para um recurso personalizado implantado por meio de ganchos de restauração:

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
  name: restorehookname0
  namespace: default
spec:
  # RestoreHook is a list of hooks to execute after restoring a resource.
  restoreHook:
    # Name is the name of this hook.
  - name: myhook-1  
    # Restored Namespaces where this hook will be executed.
    includedNamespaces: 
    excludedNamespaces:
    labelSelector:
    # PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
    postHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute from within a container after a pod has been restored.
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          # OnError specifies how Velero should behave if it encounters an error executing this hook
          # default value is Continue
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          execTimeout: 30s
          # WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
          waitTimeout: 5m

Saiba como usar ganchos durante o backup do AKS.

Durante a restauração, a extensão de backup aguarda a inicialização do contêiner e, em seguida, executa comandos exec neles, definidos nos ganchos de restauração.

Se você estiver executando a restauração no mesmo namespace em que o backup foi realizado, o gancho de recuperação não será executado. Ele só procura um contêiner recém-gerado. Esse resultado ocorre independentemente de você usar a política de ignorar ou corrigir.

Modificar o recurso durante a restauração de backups para o cluster do AKS

Você pode usar o recurso de Modificação de Recursos para modificar os recursos do Kubernetes com backup durante a restauração especificando patches JSON como configmap implantados no cluster do AKS.

Criar e aplicar um configmap do modificador de recursos durante a restauração

Para criar e aplicar a modificação de recursos, siga estas etapas:

  1. Criar um modificador de recurso configmap.

    Você precisa criar um configmap em seu namespace preferencial a partir de um arquivo YAML que definiu modificadores de recursos.

    Exemplo para criar um comando:

    version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: "^mysql.*$"
    namespaces:
    - bar
    - foo
    labelSelector:
        matchLabels:
          foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"
  - operation: remove
    path: "/metadata/labels/test"
    • O configmap anterior aplica o patch JSON a todas as cópias do Volume Persistente na barra namespaces e foo com um nome que começa com mysql e match label foo: bar. O patch JSON substitui o storageClassName por premium e remove o rótulo test das cópias de Volume Persistente.
    • Aqui, o namespace é o namespace original do recurso que foi feito backup, e não o novo namespace para o qual o recurso será restaurado.
    • Você pode especificar vários patches JSON para um recurso específico. Os patches são aplicados de acordo com a ordem especificada no configmap. O próximo patch é aplicado na ordem correta. Se forem especificados vários patches para o mesmo caminho, o último patch substituirá os anteriores.
    • Você pode especificar vários resourceModifierRules no configmap. As regras são aplicadas de acordo com a ordem especificada no configmap.

  2. Criar uma referência de modificador de recurso na configuração de restauração

    Ao realizar uma operação de restauração, forneça o ConfigMap name e o namespace onde ele é implantado como parte da configuração de restauração. Esses detalhes precisam ser indicados nas Regras do Modificador de Recursos.

    Captura de tela que mostra o local para fornecer detalhes do recurso.

Operações com suporte do Modificador de Recursos

  • Adicionar

    Você pode usar a operação Adicionar para adicionar um novo bloco ao JSON do recurso. No exemplo a seguir, a operação adiciona novos detalhes do contêiner à especificação com uma implantação.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
    # Dealing with complex values by escaping the yaml
  - operation: add
    path: "/spec/template/spec/containers/0"
    value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"

  • Remover

    Você pode usar a operação Remover para remover uma chave do JSON do recurso. No exemplo a seguir, a operação remove o rótulo com test como chave.

    version: v1
resourceModifierRules:
- conditions:
      groupResource: persistentvolumeclaims
      resourceNameRegex: "^mysql.*$"
      namespaces:
      - bar
      - foo
      labelSelector:
        matchLabels:
            foo: bar
  patches:
  - operation: remove
    path: "/metadata/labels/test"

  • Substituir

    Você pode usar a operação Substituir para substituir um valor para o caminho mencionado por um alternativo. No exemplo a seguir, a operação substitui storageClassName por premium no PVC.

    version: v1
resourceModifierRules:
- conditions:
     groupResource: persistentvolumeclaims
     resourceNameRegex: "^mysql.*$"
     namespaces:
     - bar
     - foo
     labelSelector:
        matchLabels:
           foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"

  • Copiar

    Você pode usar a operação Copiar para copiar um valor de um caminho dos recursos definidos para outro caminho.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
  - operation: copy
    from: "/spec/template/spec/containers/0"
    path: "/spec/template/spec/containers/1"

  • Teste

    Você pode usar a operação Teste para verificar se há um valor específico presente no recurso. Se o valor estiver presente, o patch será aplicado. Se o valor não estiver presente, o patch não será aplicado. No exemplo a seguir, a operação verifica se os PVCs têm premium como StorageClassName e substitui por standard, se verdadeiro.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: ".*"
    namespaces:
    - bar
    - foo
  patches:
  - operation: test
    path: "/spec/storageClassName"
    value: "premium"
  - operation: replace
    path: "/spec/storageClassName"
    value: "standard"

  • Patch JSON

    Este configmap aplica o patch JSON a todas as implantações nos namespaces por padrão e nginx com o nome que começa com nginxdep. O patch JSON atualiza a contagem de réplicas para 12 em todas essas implantações.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"

  • Patch de mesclagem JSON

    Este configmap aplica o patch de mesclagem JSON a todas as implantações nos namespaces padrão e nginx com o nome que começa com nginxdep. O patch de mesclagem JSON adicionará ou atualizará o rótulo app com o valor nginx1.

    version: v1
resourceModifierRules:
  - conditions:
      groupResource: deployments.apps
      resourceNameRegex: "^nginxdep.*$"
      namespaces:
        - default
        - nginx
    mergePatches:
      - patchData: |
          {
            "metadata" : {
              "labels" : {
                "app" : "nginx1"
              }
            }
          }

  • Patch de fusão estratégica

    Este configmap aplica o patch de mesclagem estratégica a todos os pods no namespace padrão com o nome que começa com nginx. O patch de mesclagem estratégica atualiza a imagem do contêiner nginx para mcr.microsoft.com/cbl-mariner/base/nginx:1.22.

    version: v1
resourceModifierRules:
- conditions:
    groupResource: pods
    resourceNameRegex: "^nginx.*$"
    namespaces:
    - default
  strategicPatches:
  - patchData: |
      {
        "spec": {
          "containers": [
            {
              "name": "nginx",
              "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22"
            }
          ]
        }
      }

Qual camada de armazenamento de backup dá suporte ao backup do AKS?

O Backup do Azure para AKS dá suporte a duas camadas de armazenamento como armazenamentos de dados de backup:

  • Nível Operacional: a extensão de Backup instalada no cluster do AKS primeiro faz o backup tirando instantâneos de volume por meio do driver CSI. Em seguida, armazena o estado do cluster em um contêiner blob no seu próprio locatário. Essa camada dá suporte a um RPO (objetivo de ponto de recuperação) inferior com a duração mínima de quatro horas entre dois backups. Além disso, para volumes baseados em disco do Azure, a Camada Operacional dá suporte a restaurações mais rápidas.

  • Nível do Cofre: para armazenar dados de backup por uma duração mais longa a um custo menor que os instantâneos, o backup do AKS dá suporte a armazenamentos de dados padrão de cofre. De acordo com as regras de retenção definidas na política de backup, o primeiro backup bem-sucedido (de um dia, semana, mês ou ano) é movido para um contêiner de blob fora do locatário. Esse armazenamento de dados não só permite retenção mais longa, mas também fornece proteção contra ransomware. Você também pode mover backups armazenados no cofre para outra região (região emparelhada do Azure) para recuperação habilitando Redundância geográfica e Restauração Entre Regiões no cofre de Backup.

    Observação

    Você pode armazenar os dados de backup em um repositório de dados padrão do cofre por meio da Política de Backup definindo regras de retenção. Apenas um ponto de recuperação agendado por dia é movido para o Nível de Cofre. No entanto, você pode mover qualquer número de backups sob demanda para o cofre de acordo com a regra selecionada.

Entender os preços

Você incorre em encargos para:

  • Taxa de instância protegida: o Backup do Azure para AKS cobra uma taxa de instância protegida por namespace por mês. Quando você configura o backup para um cluster do AKS, uma instância protegida é criada. Cada instância tem um número específico de namespaces que têm backup conforme definido na configuração de backup. Para obter mais informações sobre os preços de backup do AKS, consulte Preços do backup do Azure e selecione o Serviço de Kubernetes do Azure como a carga de trabalho.

  • Valor do instantâneo: o Backup do Azure para AKS protege um Volume Persistente baseado em disco tirando instantâneos que são armazenados no grupo de recursos da sua assinatura do Azure. Esses instantâneos incorrem em encargos de armazenamento de instantâneos. Como os instantâneos não são copiados para o cofre de Backup, os custos de armazenamento de backup não se aplicam. Para obter mais informações sobre o preço do instantâneo, confira preços de Discos Gerenciados.

  • Valor de armazenamento de backup: o Backup do Azure para AKS também dá suporte ao armazenamento de backups no Nível do Cofre. Você pode armazenar backups no Nível de Cofre definindo regras de retenção para o padrão de cofre na política de backup, com um ponto de restauração por dia qualificado para ser movido para o cofre. Os pontos de restauração armazenados no Nível de Cofre são cobrados por um valor separado (chamados de valor de armazenamento de Backup) de acordo com o total de dados armazenados (em gigabytes) e o tipo de redundância habilitado no cofre de Backup.

Conteúdo relacionado