O que é a cópia de segurança do Azure Kubernetes Service?

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

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 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 integra-se ao Centro de backup no Azure, para fornecer uma visão única que pode ajudá-lo a governar, 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 para 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 que são implantados em clusters AKS. A solução requer que a extensão de backup seja instalada dentro do cluster AKS. O cofre de backup se comunica com a extensão para concluir as operações de backup e restauração. O uso da extensão Backup é obrigatório. A extensão deve ser instalada dentro do cluster 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 onde os backups são armazenados.

Juntamente com a extensão de backup, uma identidade de utilizador (chamada de identidade de extensão) é criada no grupo de recursos gerido do cluster AKS. A identidade da extensão é atribuída à função Colaborador da Conta de Armazenamento na conta onde os backups são armazenados num contentor de blobs.

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

O backup do AKS permite armazenar backups na camada operacional e na camada do vault. A camada operacional é um armazenamento de dados local (os backups são armazenados no seu tenant como "snapshots"). Agora você pode mover um ponto de recuperação por dia e armazená-lo na camada do Vault como um blob (fora do seu locatário) usando o backup AKS. Os backups armazenados na camada do Vault 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ê pode 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 AKS que são implantadas no cluster. Ele também permite operações de backup para os dados armazenados no Volume Persistente para o cluster. Em seguida, armazena os backups em um contêiner de blob. O backup dos Volumes Persistentes baseados em disco é feito como instantâneos de disco em um grupo de recursos de instantâneo. Os instantâneos e o estado do cluster num blob combinam-se para formar um ponto de recuperação chamado de Nível Operacional armazenado no seu inquilino. Você também pode converter backups (o primeiro backup bem-sucedido em um dia, semana, mês ou ano) na camada operacional em blobs e, em seguida, movê-los para um cofre (fora do seu locatário) uma vez por dia.

Configurar a cópia de segurança

Para configurar backups para clusters AKS, primeiro crie um cofre de backup. O repositório oferece uma visão consolidada de todos os backups configurados através de várias fontes de dados. O backup do AKS suporta backups tanto para a camada operacional quanto para a camada do vault.

A configuração de redundância de armazenamento do cofre de backup (armazenamento com redundância local ou armazenamento com redundância geográfica) só se aplica a backups armazenados na camada do cofre. Se você quiser usar backups para recuperação de desastres, defina a redundância de armazenamento como GRS com a restauração entre regiões habilitada.

O backup do AKS aciona automaticamente uma tarefa de backup agendada. 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 mantidos na camada operacional e na camada do vault 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 termina.

Você pode usar o backup AKS para criar várias instâncias de backup para um único cluster AKS usando diferentes configurações de backup por instância de backup. No entanto, recomendamos que você crie cada instância de backup de um cluster 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

Gerir a cópia de segurança

Quando a configuração de backup para um cluster AKS é concluída, uma instância de backup é criada no cofre de backup. Você pode exibir a instância de backup para o cluster na seção Backup de uma instância AKS no portal do Azure. Você pode executar quaisquer operações relacionadas ao backup para a instância, como iniciar restaurações, monitorar, interromper a proteção e assim por diante, por meio de 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 de todos os seus clusters AKS e outras cargas de trabalho suportadas por backup. O centro de backup fornece uma visão única para todos os seus requisitos de backup, como tarefas de monitoramento e o estado de backups e restaurações. O centro de backup ajuda você a garantir conformidade e governança, analisar o uso de backup e executar operações críticas para fazer backup e restaurar dados.

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

Além disso, a extensão 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 para a 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 pode ser usado somente com recursos do Azure. Saiba mais sobre identidades gerenciadas.

Restaurar a partir de uma cópia de segurança

É possível restaurar dados a partir de qualquer ponto no tempo para o qual exista um ponto de recuperação. 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 cujo backup é feito 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 AKS original (o cluster de backup) ou em um cluster AKS alternativo. Você pode restaurar backups armazenados na Camada Operacional e na Camada do Vault para um cluster na mesma assinatura ou em uma assinatura diferente. Somente backups armazenados na camada do Vault 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 na camada do Vault, você deve fornecer um local de preparo onde os dados de backup estejam hidratados. Esse local de preparo inclui um grupo de recursos e uma conta de armazenamento dentro da mesma região e assinatura que o cluster de destino para restauração. Durante a restauração, recursos específicos (contentor de blobs, 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.

Atualmente, o Backup do Azure para AKS oferece suporte às duas opções a seguir para um cenário no qual ocorre um conflito de recursos. Um choque de recursos ocorre quando um recurso de backup tem o mesmo nome que o recurso no cluster 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) nomeada pvc-azuredisk e restaurá-la em um cluster de destino que tenha um PVC com o mesmo nome, a extensão de backup ignorará a restauração do PVC de 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 de backup estejam disponíveis apenas no cluster e não sejam ignorados.

• Patch: Esta opção permite efetuar patches na variável mutável do recurso de backup, no recurso do cluster de destino. Se quiser atualizar o número de réplicas no cluster de destino, você pode optar pela aplicação de patches como uma operação.

Usar ganchos personalizados para backup e restauração

Você pode usar ganchos personalizados para tirar instantâneos consistentes com o aplicativo de volumes que são usados para bancos de dados implantados como cargas de trabalho em contêineres.

O que são 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 a serem executados em um pod sob 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 AKS no namespace necessário, fornece os detalhes como entrada para a configuração do fluxo de backup e restauração. A extensão de Backup executa os ganchos definidos num ficheiro YAML.

O backup no AKS tem dois tipos de ganchos:

• Ganchos de backup
• Restaurar ganchos

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 personalizada (PreHooks). Você também pode executar o gancho depois que todas as ações personalizadas forem concluídas e todos os itens adicionais especificados por ações personalizadas tiverem o backup (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

Restaurar ganchos

No script de gancho de restauração, comandos personalizados ou scripts são escritos para serem executados nos contêineres de um pod AKS restaurado.

Aqui está o modelo YAML para um recurso personalizado que é 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 que o contêiner apareça e, em seguida, executa comandos exec neles, definidos nos ganchos de restauração.

Se você estiver executando a restauração para o mesmo namespace do qual foi feito backup, o gancho de restauração não será executado. Procura apenas um contentor recém-desovado. Esse resultado ocorre independentemente de se usar a política de ignorar ou correção.

Modificar recursos ao restaurar backups no cluster AKS

Você pode usar a funcionalidade de modificação de recursos para alterar os recursos de backup do Kubernetes durante a restauração, especificando patches JSON que serão implantados no cluster AKS.

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

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

1. Crie um modificador de recurso configmap.

   Você precisa criar um configmap em seu namespace preferido 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 comando anterior configmap aplica o patch JSON a todas as cópias do Volume Persistente no espaço namespaces e foo, com um nome que comece por mysql e match label foo: bar. O patch JSON substitui o storageClassName com 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 no qual o recurso será restaurado.
   • Você pode especificar vários patches JSON para um recurso específico. Os adesivos são aplicados de acordo com a ordem especificada no configmap. O próximo patch é aplicado em ordem. Se vários patches forem especificados para o mesmo caminho, o último patch substituirá os patches 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 recursos na configuração de restauração

   Ao executar 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 fornecidos em Regras do modificador de recursos.

   

Operações suportadas pelo Resource Modifier

• Adicionar

  Você pode usar a operação Add para adicionar um novo bloco ao recurso JSON. No exemplo a seguir, a operação adiciona novos detalhes de contentor à especificação através de uma implementaçã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 Remove para remover uma chave do recurso JSON. 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 para um alternativo. No exemplo a seguir, a operação substitui o storageClassName no PVC por premium.

  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 Copy 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 Test para verificar se um determinado valor está presente no recurso. Se o valor estiver presente, o patch é 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, caso seja verdade, substitui por standard.

  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

  Isso 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 as 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

  Isso 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 comando configmap aplica o patch de mesclagem estratégica a todos os pods no namespace padrão com o nome começando 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 nível de armazenamento de backup o AKS suporta?

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 AKS primeiro faz o backup tirando instantâneos dos volumes utilizando o driver CSI. Em seguida, armazena o estado do cluster num contentor de blobs no seu próprio tenant. Essa camada oferece suporte a um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) mais baixo 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 oferece suporte a restaurações mais rápidas.

• Nível do Vault: Para armazenar dados de backup por um período mais longo a um custo menor do que os snapshots, o backup do AKS suporta armazenamentos de dados padrão do vault. 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 seu locatário. Este armazenamento de dados não só permite uma 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 ativando Geo-redundancy e Cross Region Restore no Cofre de Backup.

  Nota

  Você pode armazenar os dados de backup num armazém de dados padrão do cofre através de uma Política de Backup definindo regras de retenção. Apenas um ponto de recuperação agendado por dia é movido para a camada do Vault. No entanto, você pode mover qualquer número de backups sob demanda para o cofre de acordo com a regra selecionada.

Compreender os preços

Você incorre em custos por:

• 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 AKS, uma instância protegida é criada. Cada instância tem um número específico de namespaces cujo backup é feito conforme definido na configuração de backup. Para obter mais informações sobre os preços de backup do AKS, consulte Preços para backup do Azure e selecione Serviço Kubernetes do Azure como a carga de trabalho.

• Taxa de instantâneo: o Backup do Azure para AKS protege um Volume Persistente baseado em disco tirando instantâneos armazenados no grupo de recursos em sua assinatura do Azure. Esses snapshots incorrem em custos de armazenamento de snapshots. Como os snapshots 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 preços de snapshot, consulte Preços de Discos Geridos.

• Taxa de armazenamento de backup: o Backup do Azure para AKS também oferece suporte ao armazenamento de backups no Vault Tier. Você pode armazenar backups na camada do Vault definindo regras de retenção para o padrão do vault na política de backup, com um ponto de restauração por dia qualificado para ser movido para o vault. Os pontos de restauração armazenados na camada do Cofre são sujeitos a uma taxa separada (chamada de taxa de armazenamento de backup) conforme o total de dados armazenados (em gigabytes) e o tipo de redundância habilitado no Cofre de Backup.

Conteúdo relacionado

• Pré-requisitos para o backup do Serviço Kubernetes do Azure
• Fazer backup do AKS usando o Azure PowerShell
• Restaurar o AKS usando a CLI do Azure
• Design bem arquitetado para proteção de cluster AKS