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

Резервное копирование Службы Azure Kubernetes (AKS) — это простой облачный процесс, который можно использовать для резервного копирования и восстановления контейнерных приложений и данных, выполняемых в кластере AKS. Вы можете настроить запланированные резервные копии для состояния кластера и данных приложения, хранящихся в постоянных томах Kubernetes, на основе драйвера CSI в хранилище Azure Disk Storage.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, вот шаблон 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.

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

Если вы выполняете восстановление в том же пространстве имен, которое было сохранено в резервной копии, то hook восстановления не выполняется. Он ищет только недавно созданный контейнер. Этот результат возникает независимо от того, используется ли политика пропуска или исправления.

Внесение изменений в ресурс при восстановлении резервных копий на кластер 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 ко всем копиям сохраняемого тома в строке namespaces и foo с именем, начинающимся с mysql и match label foo: bar. JSON-патч заменяет storageClassName на premium и удаляет метку test из копий постоянного тома.
   • namespace Здесь используется исходное пространство имен резервного копирования ресурса, а не новое пространство имен, в которое будет восстановлен ресурс.
   • Можно указать несколько исправлений JSON для определенного ресурса. Исправления применяются в соответствии с порядком, указанным в разделе configmap. Следующее исправление применяется по порядку. Если для одного пути задано несколько исправлений, последнее исправление переопределяет предыдущие исправления.
   • Можно указать несколько resourceModifierRules в элементе configmap. Правила применяются в соответствии с порядком, указанным в параметре configmap.

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

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

   

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

• Добавлять

  Операцию "Добавить " можно использовать для добавления нового блока в 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"
  

• Тест

  Операцию тестирования можно использовать для проверки наличия определенного значения в ресурсе. Если значение присутствует, применяется исправление. Если значение отсутствует, исправление не применяется. В следующем примере операция проверяет, имеют ли PVCs значение premium и заменяет его на StorageClassName, если условие истинно.

  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 ко всем развертываниям в пространствах имен по умолчанию и nginx с именем, начинающимся с nginxdep. Исправление 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"
                }
              }
            }
  

• Стратегический объединенный патч

  Это configmap применяет стратегическое исправление слияния ко всем модулям pod в пространстве имен по умолчанию с именем, начиная с 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 поддерживает хранилища данных стандарта Vault. Согласно правилам хранения, заданным в политике резервного копирования, первая успешная резервная копия (дня, недели, месяца или года) перемещается в контейнер блоб за пределы арендатора. Это хранилище данных не только обеспечивает более длительное хранение, но и обеспечивает защиту от программ-шантажистов. Резервные копии, хранящиеся в хранилище, можно также переместить в другой регион (в парном регионе Azure) для восстановления, включив Геоизбыточность и восстановление между регионами в хранилище резервных копий.

  Примечание.

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

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

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

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

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

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

Связанный контент

• Предварительные требования к резервному копированию Azure Kubernetes Service
• Резервное копирование AKS с помощью Azure PowerShell
• Восстановление AKS с помощью Azure CLI
• Хорошо спроектированный дизайн для защиты кластера AKS