Что такое резервное копирование в службе Azure Kubernetes?

Резервное копирование службы Azure Kubernetes (AKS) — это простой облачный процесс, который можно использовать для резервного копирования и восстановления контейнерных приложений и данных, которые выполняются в кластере AKS. Можно настроить плановое резервное копирование данных состояния кластера и приложений, хранящихся на постоянных томах в хранилище дисков Azure на основе драйвера CSI. Это решение предоставляет возможность детального контроля с целью выбора резервного копирования или восстановления конкретного пространства имен или всего кластера благодаря локальному хранению резервных копий в контейнере BLOB-объектов и в виде моментальных снимков дисков. Служба резервного копирования AKS может быть использована для комплексных сценариев, включая оперативное восстановление, клонирование сред разработки и тестирования, а также сценариев обновления кластера.

Служба резервного копирования AKS интегрируется с центром резервного копирования в Azure, обеспечивая единое представление, которое позволяет управлять, отслеживать, управлять и анализировать резервные копии в любом масштабе. Резервные копии также доступны на портале Azure в разделе "Параметры " в меню службы для экземпляра AKS.

Как работает резервное копирование AKS?

Используйте резервное копирование AKS для резервного копирования рабочих нагрузок AKS и постоянных томов, развернутых в кластерах AKS. Для решения необходимо установить расширение резервного копирования в кластере AKS. Хранилище резервных копий взаимодействует с расширением для выполнения операций, связанных с резервным копированием и восстановлением. Использование расширения резервного копирования является обязательным, а расширение должно быть установлено в кластере AKS, чтобы включить резервное копирование и восстановление кластера. При настройке резервного копирования AKS, вы добавляете значения для учетной записи хранения и контейнера BLOB-объектов, в котором хранятся резервные копии.

Наряду с расширением резервного копирования в управляемой группе ресурсов кластера AKS создается удостоверение пользователя, называемое удостоверение расширения. Идентификатор расширения назначается роли "Участник учетной записи хранения" в учетной записи хранения, где резервные копии хранятся в контейнере BLOB.

Для поддержки общедоступных, частных и авторизованных кластеров на основе IP-адресов резервная копия AKS требует включения доверенного доступа между кластером AKS и хранилищем резервных копий. Доверенный доступ позволяет хранилищу резервного копирования получить доступ к кластеру AKS из-за определенных разрешений, назначенных ему для операций резервного копирования. Дополнительные сведения о доверенном доступе AKS см. в статье "Разрешить ресурсам Azure доступ к кластерам AKS с помощью доверенного доступа".

После установки расширения резервного копирования и включения доверенного доступа можно настроить запланированные резервные копии для кластеров в соответствии с политикой резервного копирования. Вы также можете восстановить резервные копии в исходном кластере или в альтернативный кластер, который находится в той же подписке и регионе. При настройке конкретной операции можно выбрать определенное пространство имен или весь кластер в качестве конфигурации резервного копирования и восстановления.

Решение для резервного копирования позволяет выполнять операции резервного копирования для источников данных AKS, развернутых в кластере, а также для данных, хранящихся в постоянном томе кластера. Затем резервные копии сохраняются в контейнере Blob. Постоянные тома на основе диска резервируются в виде моментальных снимков дисков в группе ресурсов для моментальных снимков. Моментальные снимки и состояние кластера в объекте типа blob объединяются для формирования точки восстановления, которая хранится в вашем тенанте, именуемом «Операционный уровень». Вы также можете преобразовать резервные копии (первая успешная архивация за день, неделю, месяц или год) в Операционном уровне в BLOB, а затем переместить их в Хранилище (за пределами арендатора) один раз в день.

Настроить резервное копирование

• Чтобы настроить резервные копии для кластеров AKS, сначала создайте хранилище резервных копий. Хранилище обеспечивает объединённый обзор резервных копий, настроенных для различных источников данных. Резервное копирование AKS поддерживает резервные копии операционного уровня и уровня хранения.

  Примечание.

  • Хранилище резервных копий и кластер AKS, которые вы хотите скопировать или восстановить, должны находиться в одном и том же регионе и подписке.
  • Параметр избыточности хранилища резервных копий (LRS/GRS) применяется только к резервным копиям, хранящимся на уровне хранилища. Если вы хотите использовать резервные копии для аварийного восстановления, задайте избыточность хранилища как GRS с включенным восстановлением между регионами.

• Резервное копирование AKS автоматически активирует запланированное задание резервного копирования. Задание копирует ресурсы кластера в контейнер BLOB и создает инкрементальный снимок персистентных томов на диске в соответствии с заданной частотой резервного копирования. Резервные копии сохраняются на операционном уровне и уровне хранилища в соответствии с длительностью хранения, определенной в политике резервного копирования, и удаляются после завершения длительности.

  Примечание.

  Резервное копирование AKS можно использовать для создания нескольких экземпляров резервного копирования для одного кластера AKS с помощью различных конфигураций резервного копирования для каждого экземпляра резервного копирования. Однако каждый экземпляр резервного копирования кластера AKS должен быть создан в другом хранилище резервных копий или с помощью отдельной политики резервного копирования в одном хранилище резервных копий.

Управление резервным копированием

После завершения конфигурации резервного копирования для кластера AKS в хранилище резервных копий создается экземпляр резервной копии. Экземпляр резервного копирования для кластера можно просмотреть в разделе "Резервное копирование " для экземпляра AKS на портале Azure. Вы можете выполнять любые операции, связанные с резервным копированием для экземпляра, такие как инициирование восстановления, мониторинг, остановка защиты и т. д. с помощью соответствующего экземпляра резервного копирования.

Резервное копирование AKS также интегрируется непосредственно с Центром резервного копирования, чтобы управлять защитой для всех кластеров AKS и других поддерживаемых резервными копиями рабочих нагрузок централизованно. Центр резервного копирования — это единое представление для всех ваших требований к резервному копированию, например задания мониторинга и состояние резервных копий и восстановления. Центр резервного копирования помогает обеспечить соответствие требованиям и управление, анализировать использование резервных копий и выполнять критически важные операции для резервного копирования и восстановления данных.

Резервное копирование AKS использует управляемую идентичность для доступа к другим ресурсам Azure. Чтобы настроить резервное копирование кластера AKS и восстановить из предыдущей резервной копии, управляемая идентификация хранилища резервных копий требует набора разрешений для кластера AKS и группы ресурсов моментальных снимков, в которой создаются и управляются моментальные снимки. В настоящее время кластер AKS требует набора разрешений для группы ресурсов снимка. Кроме того, расширение резервного копирования создает удостоверение пользователя и назначает набор разрешений для доступа к учетной записи хранения, где резервные копии хранятся в блобе. Разрешения управляемому удостоверению можно предоставить, используя управление доступом на основе ролей Azure (Azure RBAC). Управляемое удостоверение — это особый тип принципа службы, который можно использовать только с ресурсами Azure. Дополнительные сведения об управляемых удостоверениях.

Восстановление из резервной копии

Данные можно восстановить из любой точки во времени, для которой существует точка восстановления. Точка восстановления создается, когда экземпляр резервного копирования находится в защищенном состоянии, и может использоваться для восстановления данных, пока ее хранение предусмотрено политикой резервного копирования.

Azure Backup позволяет восстановить все элементы, которые были сохранены в резервной копии, или использовать детализированные настройки для выбора определенных элементов из резервных копий, выбирая пространства имен и другие параметры фильтрации. Кроме того, можно выполнить восстановление в исходном кластере AKS (кластере, для которого создана резервная копия) или в альтернативном кластере AKS. Резервные копии, хранящиеся в оперативном и архивном слоях, можно восстановить в кластер как в той же подписке, так и в другой. Только резервные копии, хранящиеся на уровне Vault, могут быть использованы для восстановления в кластере в другом регионе (партнёрский регион Azure).

Чтобы восстановить резервную копию, хранящуюся в Vault Tier, вы должны указать промежуточное расположение, где данные резервного копирования будут восстановлены. Это промежуточное расположение включает группу ресурсов и учетную запись хранения в том же регионе, а также подписку, служащую целевым кластером для восстановления. Во время восстановления определенные ресурсы (контейнер BLOB, диск и моментальные снимки дисков) создаются как часть инициализации, а затем удаляются после завершения операции восстановления.

Azure Backup для AKS в настоящее время поддерживает следующие два варианта при выполнении операции восстановления при столкновении ресурсов (резервный ресурс имеет то же имя, что и ресурс в целевом кластере AKS). При определении конфигурации восстановления можно выбрать один из этих вариантов.

1. Пропустить. Этот параметр выбран по умолчанию. например, если вы создали резервную копию ПВХ с именем pvc-azuredisk и восстанавливаете её в целевом кластере, где есть ПВХ с таким же именем, расширение резервного копирования пропустит восстановление претензии на постоянный том (ПВХ). В таких сценариях мы рекомендуем вам удалить ресурс из кластера, а затем выполнить операцию восстановления, чтобы элементы резервного копирования были доступны только в кластере и чтобы они не были пропущены.

2. Патч: Этот параметр позволяет модифицировать изменяемую переменную в резервной копии ресурса на ресурсе в целевом кластере. Если вы хотите обновить количество реплик в целевом кластере, можно выбрать исправление в качестве операции.

Используйте пользовательские хуки для резервного копирования и восстановления

Вы можете использовать пользовательские хуки для создания моментальных снимков томов, согласованных с приложениями, которые используются для баз данных, развернутых в виде контейнерных рабочих нагрузок.

Что такое пользовательские хуки?

Резервное копирование AKS можно использовать для выполнения пользовательских хуков в рамках операций по резервному копированию и восстановлению. Хуки — это команды, настроенные для выполнения одной или нескольких команд в pod, связанных с контейнером, во время операции резервного копирования или после восстановления. Эти хуки определяются в качестве настраиваемого ресурса и развертываются в кластере AKS, в котором вы хотите выполнить резервное копирование или восстановление. При развертывании настраиваемого ресурса в кластере AKS в необходимом пространстве имен вы предоставляете информацию в качестве входных данных для настройки процесса резервного копирования и восстановления. Расширение резервного копирования запускает перехватчики, как определено в файле YAML.

Резервное копирование в AKS имеет два типа хуков.

• Хуки резервного копирования
• Восстановление хуков

Хуки резервного копирования

В хуке резервного копирования можно настроить команды для запуска до любой обработки пользовательских действий (предхуки) или после завершения всех пользовательских действий и резервного копирования всех дополнительных элементов, указанных в пользовательских действиях (постхуки).

Например, вот шаблон YAML для развертывания пользовательского ресурса с использованием перехватчиков резервного копирования:

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

Восстановление хуков

В скрипте-перехватчике для восстановления создаются и исполняются пользовательские команды или скрипты, предназначенные для выполнения в контейнерах восстановленного модуля AKS pod.

Ниже приведен шаблон YAML для развертывания пользовательского ресурса с помощью хуков восстановления:

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

Узнайте , как использовать хуки во время резервного копирования AKS.

Внесение изменений в ресурс при восстановлении резервных копий на кластер AKS.

Вы можете использовать функцию модификации для изменений резервных копий ресурсов Kubernetes во время восстановления, указав исправления в формате JSON, которые развернуты в кластере AKS.

Создание и применение конфигурации модификатора ресурсов во время восстановления

Чтобы создать и применить изменение ресурсов, выполните следующие действия.

1. Создайте модификаторы ресурсов configmap.

   Необходимо создать один ConfigMap в предпочтительном пространстве имен из YAML файла, в котором заданы модификаторы ресурсов.

   Пример создания команды:

   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"
   

   • Приведенный выше configmap применяет исправление JSON ко всем копиям постоянного тома в пространствах имен bar и foo с именем, начинающимся с mysql и match label foo: bar. JSON-патч заменяет storageClassName на premium и удаляет метку test из резервных копий постоянного тома.
   • Здесь, пространство имен — это исходное пространство имен резервного копирования ресурса, а не новое пространство имен, в котором будет восстановлен ресурс.
   • Можно указать несколько исправлений JSON для определенного ресурса. Исправления применяются в соответствии с порядком, указанным в файле конфигурации. Исправление применяется в последующей очередности. Если для одного пути задано несколько исправлений, последнее исправление переопределяет предыдущие исправления.
   • В resourceModifierRules можно указать несколько . Правила применяются в соответствии с порядком, указанным в файле конфигурации.

2. Создание ссылки на модификатор ресурсов в конфигурации восстановления

   При выполнении операции восстановления укажите имя ConfigMap и пространство имен , где оно развертывается в рамках конфигурации восстановления. Эти сведения необходимо указать в правилах модификатора ресурсов.

   

Операции, поддерживаемые модификатором ресурсов

• Добавлять

  Операцию "Добавить " можно использовать для добавления нового блока в json ресурса. В приведенном ниже примере операция добавляет новые сведения о новом контейнере в спецификацию развертывания.

  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}]}"
  

• Убирать

  Операцию "Удалить " можно использовать для удаления ключа из json ресурса. В приведенном ниже примере операция удаляет метку с ключом test.

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

• Заменять

  Вы можете использовать операцию Заменить для замены указанного значения пути на альтернативное. В приведенном ниже примере операция заменяет storageClassName в запросе на постоянный том на premium.

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

• Копировать

  Операцию копирования можно использовать для копирования значения из одного пути, определенного в ресурсах, на другой путь.

  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"
  

• Тест

  Операцию тестирования можно использовать для проверки наличия определенного значения в ресурсе. Если значение присутствует, применяется исправление. Если значение отсутствует, исправление не применяется. В приведенном ниже примере операция проверяет, имеют ли запросы постоянного тома premium в качестве StorageClassName и заменяет его на 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"
  

• Исправление JSON

  Эта configmap применяет исправление JSON ко всем развертываниям в пространствах имен по умолчанию и `nginxwith the name that starts withnginxdep`. Исправление JSON обновляет число реплик до 12 для всех таких развертываний.

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

• Исправление слияния JSON

  Эта ConfigMap будет применять JSON Merge Patch ко всем развертываниям в неймспейсах default и nginx, с именами, начинающимися на nginxdep. Патч JSON для объединения добавит или обновит метку "app" со значением "nginx1".

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

• Strategic Merge Patch

  Эта конфигурационная карта применит Strategic Merge Patch ко всем подам в пространстве имен default с именем, начинающимся с nginx. Патч стратегического слияния обновит образ контейнера nginx на 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"
              }
            ]
          }
        }
  

Какой уровень хранилища резервных копий поддерживает резервное копирование AKS?

Azure Backup для AKS поддерживает два уровня хранилища в качестве хранилищ резервных копий:

• Операционный уровень. Расширение для резервного копирования, установленное в кластере AKS, сначала выполняет резервное копирование, создавая снимки томов через драйвер CSI и сохраняя состояние кластера в BLOB-контейнере в вашей учетной записи. Этот уровень поддерживает более низкую RPO с минимальной длительностью между двумя резервными копиями в четыре часа. Кроме того, операционный уровень для томов на базе дисков Azure поддерживает более быстрое восстановление.

• Уровень хранилища: Для длительного хранения данных резервного копирования с меньшими затратами, чем моментальные снимки, резервное копирование AKS поддерживает стандартное хранилище. В соответствии с правилами хранения, установленными в политике резервного копирования, первая успешная резервная копия (за день, неделю, месяц или год) переносится в контейнер двоичных блобов за пределы вашего тенанта. Это хранилище данных не только обеспечивает более длительное хранение, но и обеспечивает защиту от программ-шантажистов. Вы также можете переместить резервные копии, хранящиеся в хранилище, в другой регион (парный регион Azure) для восстановления, включив геоизбыточность и восстановление между регионами в хранилище резервных копий.

Общие сведения о ценах

Вы несете плату за:

• Плата за защищенный экземпляр: Azure Backup для AKS взимает плату за защищенный экземпляр за каждый пространство имен в месяц. При настройке резервного копирования для кластера AKS создается защищенный экземпляр. Каждый экземпляр имеет заданное количество пространств имен, которые резервируются в соответствии с конфигурацией резервного копирования. Дополнительные сведения о ценах на резервное копирование AKS см. в разделе "Цены на облачное резервное копирование " и выбор службы Azure Kubernetes в качестве рабочей нагрузки

• Комиссия за моментальный снимок: Azure Backup для AKS защищает постоянный том на основе диска, делая моментальные снимки, которые хранятся в группе ресурсов в вашей подписке Azure. Эти снимки подразумевают затраты на хранение. Так как моментальные снимки не копируются в хранилище резервных копий, плата за хранение резервных копий не взимается. Для получения дополнительной информации о ценах на мгновенные снимки см. раздел Цены на управляемый диск.

• Плата за хранилище резервных копий: Azure Backup для AKS также поддерживает хранение резервных копий на уровне среды хранения Vault. Это можно сделать, определив правила хранения для хранилища "Standard Vault" в политике резервного копирования, при этом одна точка восстановления в день может быть перенесена в Хранилище. Точки восстановления, хранящиеся в уровне Вэулт, облагаются отдельной платой, называемой платой за хранилище резервных копий, в зависимости от общего объема данных в гигабайтах (ГБ) и типа избыточности, включенного в Хранилище резервных копий.

Следующий шаг