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

O backup do AKS (Serviço de Kubernetes do Azure) é 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 no Armazenamento em Disco do Azure baseado em driver CSI. A solução oferece a você o controle granular para escolher um namespace específico ou um cluster inteiro para fazer backup ou restauração, 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/teste e cenários de atualização de cluster.

O backup do AKS se integra ao Centro de Backup do Azure, fornecendo uma só visualização que pode ajudar 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?

Utilize a cópia de segurança AKS para fazer backup das suas cargas de trabalho e volumes persistentes AKS que são implantados em clusters 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 relacionadas ao backup e à restauração. O uso da extensão de Backup é obrigatório e 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 recebe a função de Colaborador da Conta de Armazenamento na conta de armazenamento onde os backups são armazenados em um contêiner de blob.

Para suportar clusters públicos, privados e autorizados baseados em IP, o backup AKS requer que o Acesso Confiável seja ativado entre o cluster AKS e o cofre de Backup. O Acesso Confiável permite que o cofre de backup acesse o cluster AKS devido a permissões específicas que lhe são atribuídas 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.

Observação

O backup do AKS permite que você armazene backups na Camada Operacional e na Camada do 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 na Camada do Cofre como blobs (fora do locatário) usando o backup do AKS. Os backups armazenados no Cofre também podem ser usados para restaurar dados em uma região secundária (região emparelhada do Azure).

Depois que a extensão backup for instalada e o Acesso Confiável estiver habilitado, 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 alternativo que está na mesma assinatura e região. Você pode escolher um namespace específico ou um cluster inteiro como uma configuração de backup e restauração ao configurar a operação específica.

A solução de backup habilita as operações de backup para suas fontes de dados do AKS implantadas no cluster e para os dados armazenados no volume persistente do cluster e, em seguida, armazena os backups em um contêiner de blob. É feito backup dos volumes persistentes baseados em disco como capturas instantâneas de disco em um grupo de recursos de instantâneo. Os instantâneos e o estado do cluster em um blob são combinados para formar um ponto de recuperação armazenado em seu locatário chamado Camada Operacional. Você também pode converter backups (primeiro backup bem-sucedido em um dia, semana, mês ou ano) na Camada Operacional em blobs e movê-los para um Cofre (fora do 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 CSI. Durante os backups, a solução ignora outros tipos de volume persistente, como Compartilhamento de Arquivos do Azure e blobs. Além disso, se você tiver definido regras de retenção para a camada do Cofre, os backups só poderão ser movidos para o cofre se os volumes persistentes forem de tamanho menor ou igual a 1 TB.

Configurar o backup

• Para configurar backups para clusters do AKS, primeiro crie um cofre de Backup. O cofre fornece uma exibição consolidada dos backups configurados em diferentes fontes de dados. O backup do AKS dá suporte a backups da Camada Operacional e da Camada do Cofre.

  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.
  • A configuração de redundância de armazenamento do cofre de backup (LRS/GRS) só se aplica a backups armazenados na Camada do 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.

• 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 mantidos na Camada Operacional e na Camada do Cofre de acordo com a duração de retenção definida na política de backup e são excluídos quando a duração acaba.

  Observação

  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, cada instância de backup de um cluster do AKS deve ser criada em um cofre de Backup diferente ou 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 ajudar você a gerenciar centralmente a proteção de todos os seus clusters AKS e outras cargas de trabalho com suporte de backup. O centro de backup é uma exibição única 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 ASK e no grupo de recursos de instantâneo em que os instantâneos 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 para a identidade gerenciada usando o RBAC do Azure (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 e pode ser usado para restaurar dados até que sejam retidos pela política de backup.

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 escolhendo namespaces e outras opções de filtro. Além disso, você pode fazer a restauração no cluster original do AKS (o cluster que fez backup) ou em um cluster alternativo do AKS. Você pode restaurar backups armazenados na Camada Operacional e do Cofre para um cluster na mesma assinatura e em uma assinatura diferente. Somente os backups armazenados na Camada do Cofre podem ser usados para fazer uma restauração em um cluster em uma região diferente (Região Emparelhada do Azure).

Para restaurar o backup armazenado na Camada do Cofre, você deve fornecer um local de preparo em que os dados de backup sejam hidratados. Esse local de preparo inclui um grupo de recursos e uma conta de armazenamento na mesma região e uma 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, que é então desmarcada 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 ao fazer uma operação de restauração quando ocorre um conflito de recursos (o 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.

1. Ignorar: esta opção é selecionada por padrão. Por exemplo, se você tiver feito backup de um PVC chamado pvc-azuredisk e estiver restaurando-o em um cluster de destino que tenha o PVC com o mesmo nome, a extensão de backup ignorará a restauração da declaração de volume persistente de backup (PVC). Nesses cenários, recomendamos que você exclua o recurso do cluster e faça a operação de restauração para que os itens de backup só estejam disponíveis no cluster e não sejam ignorados.

2. 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

Atualmente, o backup do AKS não excluirá e recriará 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. Ganchos são comandos configurados para executar um ou mais comandos 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 do AKS no namespace necessário, você fornece os detalhes como entrada para o fluxo configurar o backup e a 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

Em um gancho de backup, você pode configurar os comandos para executar o gancho antes do processamento de qualquer ação personalizado (pré-ganchos) ou após a conclusão de todas as ações personalizadas e o backup de todos os itens adicionais especificados pelas ações personalizadas (pós-ganchos).

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, comandos ou scripts personalizados são gravados para serem executados em contêineres de um pod do AKS.

Aqui está o modelo YAML para um recurso personalizado a ser implantado usando 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.

Observação

• Durante a restauração, a extensão de backup aguarda o contêiner aparecer e, em seguida, executa comandos exec neles, definidos nos ganchos de restauração.
• Caso você esteja executando a restauração para o mesmo namespace cujo backup foi feito, os ganchos de restauração não serão executados, pois ele procura apenas um novo contêiner que seja gerado. Isso ocorre independentemente da escolha por política de ignorar ou aplicar patch.

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

Você pode usar a funcionalidade Modificação de recursos para modificar os recursos do Kubernetes de backup durante a restauração. Para isso, especifique os patches JSON como configmap implantado 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. Crie um configmap de modificadores de recursos.

   Você precisa criar um configmap no seu namespace de preferência a partir de um arquivo YAML que tenha definido os modificadores de recursos.

   Exemplo de criação de 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 acima aplica o patch JSON a todas as Cópias de Volume Persistente na barra de namespaces e foo com o 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 armazenado em backup e não o novo namespace em que 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. Um patch subsequente é aplicado na ordem. 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. Como criar uma referência de modificador de recurso na configuração de restauração

   Ao executar uma operação de restauração, indique o nome do ConfigMap e o Namespace no qual ele está implantado como parte da configuração de restauração. Esses detalhes precisam ser indicados nas Regras do Modificador de Recursos.

   

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 de 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"
  

• Replace

  Você pode usar a operação Substituir para substituir um valor para o caminho mencionado por um alternativo. No exemplo abaixo, a operação substitui o storageClassName na declaração de volume persistente 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"
  

• Copy

  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"
  

• Test

  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 abaixo, a operação verifica se as declarações de volume persistente têm premium como StorageClassName e o substituem 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

  Esse configmap aplica o patch JSON a todas as implantações nos namespaces por padrão e ``nginxwith the name that starts withnginxdep`. O patch JSON atualiza a contagem de réplicas para 12 para 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

  Esse mapa de configurações aplicará o Patch de mesclagem JSON a todas as implantações nos namespaces padrão e nginx com o nome começando com nginxdep. O Patch de mesclagem JSON adicionará/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 Mesclagem Estratégica

  Esse mapa de configurações aplicará 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 atualizará a imagem do nginx de contêiner 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:

• Camada Operacional: a Extensão de Backup instalada no cluster do AKS primeiro usa o backup tirando instantâneos de volume por meio do Driver do CSI e armazena o estado do cluster em um contêiner de blob em seu próprio locatário. Essa camada dá suporte a RPO inferior com a duração mínima entre dois backups de quatro horas. Além disso, para volumes baseados em Disco do Azure, a Camada Operacional dá suporte a restaurações mais rápidas.

• Camada do cofre: para armazenar dados de backup por mais tempo a um custo menor do que os instantâneos, o backup do AKS dá suporte ao armazenamento de dados padrão do 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, permitindo 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 a Camada do 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 de Nuvem e selecione o Serviço de Kubernetes do Azure como carga de trabalho

• Taxa de Instantâneo: O Backup do Azure para AKS protege volume persistente baseado em disco criando instantâneos armazenados no grupo de recursos em 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, o custo de armazenamento de backup não se aplica. Para saber mais informações sobre os preços de instantâneos, confira Preços de Discos Gerenciados.

• Valor de armazenamento de backup: o Backup do Azure para AKS também oferece suporte ao armazenamento de backups na Camada do Cofre. Isso pode ser alcançado definindo regras de retenção para cofre padrão 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 Vault Tier são cobrados com uma taxa separada chamada valor de armazenamento de backup, de acordo com o total de dados armazenados (em GBs) e o tipo de redundância habilitado no Backup Vault.

Próxima etapa

Pré-requisitos para o backup do Serviço de Kubernetes do Azure