¿Qué es la copia de seguridad de Azure Kubernetes Service?

Copia de seguridad de Azure Kubernetes Service (AKS)es un proceso sencillo nativo en la nube que puede usar para realizar copias de seguridad y restaurar aplicaciones contenedorizadas y datos que se ejecutan en el clúster de AKS. Puede configurar copias de seguridad programadas para el estado del clúster y los datos de la aplicación almacenados en volúmenes persistentes en Azure Disk Storage basado en controladores CSI. La solución proporciona un control pormenorizado para elegir un espacio de nombres específico o un clúster completo para realizar copias de seguridad o restaurar almacenando copias de seguridad localmente en un contenedor de blob y como instantáneas de disco. Puede usar la copia de seguridad de AKS para escenarios de un extremo a otro, incluida la recuperación operativa, la clonación de entornos de desarrollo y pruebas y escenarios de actualización del clúster.

La copia de seguridad de AKS se integra con el Centro de copias de seguridad en Azure, lo que proporciona una vista única que puede ayudarle a controlar, supervisar, operar y analizar copias de seguridad a escala. Las copias de seguridad también están disponibles en Azure Portal en Configuración en el menú de servicios de una instancia de AKS.

¿Cómo funciona la copia de seguridad de AKS?

Use la copia de seguridad de AKS para realizar copias de seguridad de las cargas de trabajo de AKS y volúmenes persistentes que se implementan en clústeres de AKS. La solución requiere que se instale una extensión de Backupdentro del clúster de AKS. El almacén de Backup se comunica con la extensión para completar las operaciones relacionadas con la copia de seguridad y la restauración. El uso de la extensión de Backup es obligatorio, y la extensión debe estar instalada dentro del clúster AKS para habilitar la copia de seguridad y la restauración para el clúster. Al configurar la copia de seguridad de AKS, se agregan valores para una cuenta de almacenamiento y un contenedor de blobs donde se almacenan las copias de seguridad.

Junto con la extensión Backup, se crea una identidad de usuario (llamadaidentidad de extensión) en el grupo de recursos administrados del clúster de AKS. A la identidad de extensión se le asigna el rol Colaborador de la cuenta de almacenamiento asignado a ella en la cuenta de almacenamiento donde las copias de seguridad se almacenan en un contenedor de blob.

Para admitir clústeres basados en IP pública, privada y autorizada, la copia de seguridad de AKS requiere que se habilite el acceso de confianza entre el almacén de copia de seguridad y el clúster de AKS. El acceso de confianza permite que el almacén de copia de seguridad acceda al clúster de AKS debido a permisos específicos que se le asignan para las operaciones de copia de seguridad. Para más información sobre el acceso de confianza de AKS, consulte Habilitación de recursos de Azure para acceder a clústeres de AKS mediante acceso seguro.

Nota:

La copia de seguridad de AKS permite almacenar copias de seguridad en el nivel operativo y en el nivel de almacén. El nivel operativo es un almacén de datos local (las copias de seguridad se almacenan en el inquilino como instantáneas). Ahora puede mover un punto de recuperación al día y almacenarlo en el nivel de almacén como blobs (fuera del inquilino) mediante la copia de seguridad de AKS. Las copias de seguridad almacenadas en el almacén también se pueden usar para restaurar datos en una región secundaria (región emparejada de Azure).

Una vez instalada la extensión Backup y habilitado el acceso de confianza, puede configurar copias de seguridad programadas para los clústeres según la directiva de copia de seguridad. También puede restaurar las copias de seguridad en el clúster original o en un clúster alternativo que se encuentra en la misma suscripción y región. Puede elegir un espacio de nombres específico o un clúster completo como una configuración de copia de seguridad y restauración mientras configura la operación específica.

La solución de copia de seguridad habilita las operaciones de copia de seguridad para los orígenes de datos de AKS que se implementan en el clúster y para los datos que se conservan en el volumen persistente para el clúster, y después almacena las copias de seguridad en un contenedor de blobs. Los volúmenes persistentes basados en disco se realizan copias de seguridad como instantáneas de disco en un grupo de recursos de instantáneas. Las instantáneas y el estado del clúster de un blob se combinan para formar un punto de recuperación que se almacena en el inquilino denominado Nivel operativo. También puede convertir las copias de seguridad (primera copia de seguridad realizada con éxito en un día, una semana, un mes o un año) de la capa operativa en blobs, y después trasladarlas a un almacén (fuera de su inquilino) una vez al día.

Nota:

Actualmente, Azure Backup solo admite volúmenes persistentes en Azure Disk Storage basado en controladores CSI. Durante las copias de seguridad, la solución omite otros tipos de volúmenes persistentes, como recurso compartido de archivos de Azure y blobs. Además, si ha definido reglas de retención para el nivel de almacén, las copias de seguridad solo se pueden mover al almacén si los volúmenes persistentes tienen un tamaño menor o igual que 1 TB.

Configuración de la copia de seguridad

• Para configurar copias de seguridad para clústeres de AKS, cree primero un almacén de Backup. El almacén proporciona una vista consolidada de las copias de seguridad configuradas en distintos orígenes de datos. La copia de seguridad de AKS admite copias de seguridad de nivel operativo y de nivel de almacén.

  Nota:

  • El almacén de Backup y el clúster de AKS de los que desea realizar copias de seguridad o restauración deben estar en la misma región y suscripción.
  • La configuración de redundancia de almacenamiento del almacén de Backup (LRS/GRS) solo se aplica a las copias de seguridad almacenadas en el nivel de almacén. Si desea usar copias de seguridad para la recuperación ante desastres, establezca la redundancia de almacenamiento como GRS con la restauración entre regiones habilitada.

• La copia de seguridad de AKS desencadena automáticamente un trabajo de copia de seguridad programado. El trabajo copia los recursos del clúster en un contenedor de blob y crea una instantánea incremental de los volúmenes persistentes basados en disco según la frecuencia de copia de seguridad. Las copias de seguridad se conservan en el nivel operativo y en el nivel de almacén según la duración de retención definida en la directiva de copia de seguridad y se eliminan una vez superada la duración.

  Nota:

  Puede usar la copia de seguridad de AKS para crear varias instancias de copia de seguridad para un único clúster de AKS mediante diferentes configuraciones de copia de seguridad por instancia de copia de seguridad. Sin embargo, cada instancia de copia de seguridad de un clúster de AKS debe crearse en un almacén de Backup diferente o mediante una directiva de copia de seguridad independiente en el mismo almacén de Backup.

Administración de copias de seguridad

Cuando finaliza la configuración de copia de seguridad de un clúster de AKS, se crea una instancia de copia de seguridad en el almacén de Backup. Puede ver la instancia de copia de seguridad del clúster en la sección Copia de seguridad de una instancia de AKS en Azure Portal. Puede realizar cualquier operación relacionada con la copia de seguridad de la instancia, como iniciar restauraciones, supervisar, detener la protección, y así sucesivamente, a través de su instancia de copia de seguridad correspondiente.

La copia de seguridad de AKS también se integra directamente con el Centro de copia de seguridad para ayudarle a administrar la protección de todos los clústeres de AKS y otras cargas de trabajo compatibles con copia de seguridad de forma centralizada. El centro de copia de seguridad es una vista única para todos los requisitos de copia de seguridad, como los trabajos de supervisión y el estado de las copias de seguridad y restauraciones. El Centro de copia de seguridad le ayuda a garantizar el cumplimiento y la gobernanza, analizar el uso de copias de seguridad y realizar operaciones críticas para hacer una copia de seguridad y restaurar datos.

La copia de seguridad de AKS usa la identidad administrada para acceder a otros recursos de Azure. Para configurar la copia de seguridad de un clúster de AKS y restaurar desde una copia de seguridad anterior, la identidad administrada del almacén de Backup requiere un conjunto de permisos en el clúster de AKS y el grupo de recursos de instantáneas donde se crean y administran las instantáneas. Actualmente, el clúster de AKS requiere un conjunto de permisos en el grupo de recursos de instantáneas. Además, la extensión Backup crea una identidad de usuario y asigna un conjunto de permisos para acceder a la cuenta de almacenamiento donde las copias de seguridad se almacenan en un blob. Puede conceder permisos a la identidad administrada mediante el control de acceso basado en roles de Azure (Azure RBAC). Una identidad administrada es un tipo especial de principio de servicio que solo se puede usar con recursos de Azure. Más información sobre las identidades administradas.

Restaurar desde una copia de seguridad

Puede restaurar los datos de cualquier punto en el tiempo para el cual exista un punto de recuperación. Se crea un punto de recuperación cuando una instancia de copia de seguridad está en un estado protegido y se puede usar para restaurar los datos hasta que la directiva de copia de seguridad la conserva.

Azure Backup ofrece la opción de restaurar todos los elementos de los que se realiza una copia de seguridad o usar controles pormenorizados para seleccionar elementos específicos de las copias de seguridad eligiendo espacios de nombres y otras opciones de filtro. Además, puede realizar la restauración en el clúster de AKS original (el clúster del que se realiza una copia de seguridad) o en un clúster de AKS alternativo. Puede restaurar las copias de seguridad almacenadas en los niveles operativo y de almacén en un clúster de la misma suscripción y en otro diferente. Solo se pueden usar copias de seguridad almacenadas en el nivel de almacén para realizar una restauración en un clúster de una región diferente (región emparejada de Azure).

Para restaurar la copia de seguridad almacenada en el nivel de almacén, debe proporcionar una ubicación de almacenamiento provisional donde se hidratan los datos de copia de seguridad. Esta ubicación de almacenamiento provisional incluye un grupo de recursos y una cuenta de almacenamiento en ella dentro de la misma región y una suscripción como el clúster de destino para la restauración. Durante la restauración, se crean recursos específicos (contenedor de blobs, disco e instantáneas de disco) como parte de la hidratación, que después se borra una vez finalizada la operación de restauración.

Actualmente Azure Backup para AKS admite las dos opciones siguientes al realizar una operación de restauración cuando se produce un conflicto de recursos (el recurso de copia de seguridad tiene el mismo nombre que el recurso en el clúster de AKS de destino). Puede elegir una de estas opciones al definir la configuración de restauración.

1. Omitir : esta opción no está seleccionada de forma predeterminada. Por ejemplo, si ha realizado una copia de seguridad de un PVC denominado pvc-azuredisk y la va a restaurar en un clúster de destino que tenga el PVC con el mismo nombre, la extensión de copia de seguridad omite la restauración de la notificación de volumen persistente (PVC) de copia de seguridad. En estos escenarios, se recomienda eliminar el recurso del clúster y, a continuación, realizar la operación de restauración para que los elementos de copia de seguridad solo estén disponibles en el clúster y no se omitan.

2. Parche: esta opción permite aplicar revisiones a la variable mutable en el recurso de copia de seguridad del recurso del clúster de destino. Si desea actualizar el número de réplicas en el clúster de destino, puede optar por aplicar revisiones como una operación.

Nota:

Actualmente, la copia de seguridad de AKS no elimina ni vuelve a crear recursos en el clúster de destino si ya existen. Si intenta restaurar volúmenes persistentes en la ubicación original, elimine los volúmenes persistentes existentes y, a continuación, realice la operación de restauración.

Enlaces personalizados para copias de seguridad y restauración

Puede usar enlaces personalizados para tomar instantáneas coherentes con la aplicación de volúmenes que se usan para las bases de datos implementadas como cargas de trabajo en contenedor.

¿Qué son los enlaces personalizados?

Puede usar la copia de seguridad de AKS para ejecutar enlaces personalizados como parte de una operación de copia de seguridad y restauración. Los enlaces son comandos configurados para ejecutar uno o más comandos en un pod bajo un contenedor durante una operación de copia de seguridad o después de una restauración. Estos enlaces se definen como un recurso personalizado y se implementan en el clúster de AKS que desea realizar copias de seguridad o restaurar. Cuando el recurso personalizado se implementa en el clúster de AKS en el espacio de nombres necesario, proporcione los detalles como entrada para que el flujo configure la copia de seguridad y la restauración. La extensión Backup ejecuta los enlaces tal como se define en un archivo YAML.

Nota:

Los enlaces no se ejecutan en un shell en los contenedores.

La copia de seguridad en AKS tiene dos tipos de enlaces:

• Enlaces de Backup
• Restaurar enlaces

Enlaces de Backup

En un enlace de copia de seguridad, puede configurar los comandos para ejecutar el enlace antes de cualquier procesamiento de acciones personalizados (enlaces previos), o después de que finalicen todas las acciones personalizadas y se realice una copia de seguridad de los elementos adicionales especificados por las acciones personalizadas (enlaces posteriores).

Por ejemplo, esta es la plantilla YAML para un recurso personalizado que se va a implementar mediante enlaces de copia de seguridad:

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 enlaces

En el script de enlace de restauración, los comandos personalizados o los scripts se escriben para ejecutarse en los contenedores de un pod de AKS restaurado.

Esta es la plantilla YAML para un recurso personalizado que se va a implementar mediante enlaces de restauración:

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

Obtenga información cómo usar enlaces durante la copia de seguridad de AKS.

Nota:

• Durante la restauración, la extensión de copia de seguridad espera a que aparezca el contenedor y, después, se ejecutan comandos exec en ellos, definidos en los enlaces de restauración.
• En caso de que realice la restauración en el mismo espacio de nombres del que se ha realizado una copia de seguridad, los enlaces de restauración no se ejecutarán, ya que solo se busca un nuevo contenedor generado. Esto sucede independientemente de si se ha optado por omitir o aplicar revisiones a la directiva.

Modificación de recursos durante la restauración de copias de seguridad en un clúster de AKS

Puede usar la característica de modificación de recursos para modificar los recursos de Kubernetes de copia de seguridad durante la restauración especificando revisiones JSON como elementos configmap implementados en el clúster de AKS.

Creación y aplicación de un modificador de recursos configmap durante la restauración

Para crear y aplicar la modificación de recursos, siga estos pasos:

1. Cree modificadores de recursos configmap.

   Debe crear un elemento configmap en el espacio de nombres preferido a partir de un archivo YAML que haya definido modificadores de recursos.

   Ejemplo del comando de creación:

   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"
   

   • El elemento configmap anterior aplica la revisión JSON a todas las copias de volumen persistente de los espacios de nombres bar y foo con un nombre que comienza por mysql y match label foo: bar. La revisión JSON reemplaza storageClassName por premium y quita la etiqueta test de las copias de volumen persistente.
   • Aquí, Namespace es el espacio de nombres original del recurso de copia de seguridad y no el nuevo espacio de nombres donde se va a restaurar el recurso.
   • Puede especificar varias revisiones JSON para un recurso determinado. Las revisiones se aplican según el orden especificado en el elemento configmap. Se aplica una revisión posterior en orden. Si se especifican varias revisiones para la misma ruta de acceso, la última revisión invalida las revisiones anteriores.
   • Puede especificar varios elementos resourceModifierRules en el elemento configmap. Las reglas se aplican según el orden especificado en el elemento configmap.

2. Creación de una referencia de modificador de recursos en la configuración de restauración

   Al realizar una operación de restauración, proporcione el nombre del elemento ConfigMap y el espacio de nombres donde está implementado como parte de la configuración de restauración. Estos detalles se deben proporcionar en Reglas de modificadores de recursos.

   

Operaciones admitidas por el modificador de recursos de

• Add (Agregar)

  Puede usar la operación Agregar para agregar un nuevo bloque al código JSON del recurso. En el ejemplo siguiente, la operación agrega los detalles de un nuevo contenedor a la especificación con una implementación.

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

• Remove

  Puede usar la operación Quitar para quitar una clave del código JSON del recurso. En el ejemplo siguiente, la operación quita la etiqueta con la prueba como clave.

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

• Reemplazar

  Puede usar la operación Reemplazar a fin de reemplazar un valor para la ruta de acceso mencionada por una alternativa. En el ejemplo siguiente, la operación reemplaza storageClassName en la notificación de volumen 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"
  

• Copiar

  Puede usar la operación Copiar para copiar un valor de una ruta de acceso de los recursos definidos en otra ruta distinta.

  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"
  

• Prueba

  Puede usar la operación Test para comprobar si hay un valor determinado presente en el recurso. Si el valor está presente, se aplica la revisión. Si el valor no está presente, no se aplica la revisión. En el ejemplo siguiente, la operación comprueba si las notificaciones de volumen persistente tienen premium como StorageClassName y, si es true, lo reemplaza 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"
  

• Revisión JSON

  Este elemento configmap aplica la revisión JSON a todas las implementaciones de los espacios de nombres de manera predeterminada y ``nginxwith the name that starts withnginxdep`. La revisión JSON actualiza el recuento de réplicas a 12 para todas estas implementaciones.

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

• Revisión de combinación JSON

  Este elemento ConfigMap aplicará la revisión de combinación JSON a todas las implementaciones de los espacios de nombres predeterminados y nginx con el nombre que empieza por nginxdep. La revisión de combinación JSON agregará o actualizará la etiqueta "app" con el valor "nginx1".

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

• Revisión de combinación estratégica

  Este elemento ConfigMap aplicará la revisión de combinación estratégica a todos los pods de los espacios de nombres predeterminados con el nombre que empieza por nginx. La revisión de combinación estratégica actualizará la imagen del contenedor nginx a 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"
              }
            ]
          }
        }
  

¿Qué nivel de almacenamiento de copia de seguridad admite la copia de seguridad de AKS?

Azure Backup para AKS admite dos niveles de almacenamiento como almacenes de datos de copia de seguridad:

• Nivel operativo: la extensión de copia de seguridad instalada en el clúster de AKS realiza primero la copia de seguridad tomando instantáneas de volumen a través del controlador de CSI y almacena el estado del clúster en un contenedor de blobs en su propio inquilino. Este nivel admite un RPO inferior con la duración mínima entre dos copias de seguridad de cuatro horas. Además, en el caso de los volúmenes basados en discos de Azure, el nivel operativo admite restauraciones más rápidas.

• Nivel de almacén: para almacenar los datos de copia de seguridad durante más tiempo a un costo menor que las instantáneas, la copia de seguridad de AKS admite el almacén de datos estándar del almacén. Según las reglas de retención establecidas en la directiva de copia de seguridad, la primera copia de seguridad correcta (de un día, semana, mes o año) se mueve a un contenedor de blobs fuera del inquilino. Este almacén de datos no solo permite una retención más larga, sino que también proporciona protección contra ransomware. También puede mover copias de seguridad almacenadas en el almacén a otra región (región emparejada de Azure) para la recuperación habilitando la redundancia geográfica y la restauración entre regiones en el almacén de Backup.

Nota:

Puede almacenar los datos de copia de seguridad en un almacén de datos estándar a través de la directiva de copia de seguridad mediante la definición de reglas de retención. Solo se mueve un punto de recuperación programado al día al nivel de almacén. Sin embargo, puede mover cualquier número de copias de seguridad a petición al almacén según la regla seleccionada.

Descripción de los precios

Incurrirá en cargos por:

• Cuota de instancia protegida: Azure Backup para AKS cobra una Precio de instancia protegida por espacio de nombres al mes. Al configurar la copia de seguridad de un clúster de AKS, se crea una instancia protegida. Cada instancia tiene un número específico de espacios de nombres de los que se realiza una copia de seguridad tal como se define en la configuración de copia de seguridad. Para más información sobre los precios de copia de seguridad de AKS, consulte Precios de Cloud Backup y seleccione Azure Kubernetes Service como carga de trabajo

• Precio de instantánea: Azure Backup para AKS protege un volumen persistente basado en disco tomando instantáneas almacenadas en el grupo de recursos de la suscripción de Azure. Estas instantáneas incurren en cargos de almacenamiento de instantáneas. Dado que las instantáneas no se copian en el almacén de Backup, no se aplica el costo de almacenamiento de copia de seguridad. Para obtener más información sobre los precios de las instantáneas, consulte precios de disco administrado.

• Cuota de almacenamiento de copia de seguridad: Azure Backup para AKS también admite el almacenamiento de copias de seguridad en el nivel de almacén. Esto se puede lograr mediante la definición de reglas de retención para el estándar de almacén en la directiva de copia de seguridad, con un punto de restauración al día apto para moverse al almacén. Los puntos de restauración almacenados en el nivel de almacén se cobran una tarifa independiente denominada Cuota de almacenamiento de copia de seguridad según el total de datos almacenados (en GB) y el tipo de redundancia habilitados en el almacén de Backup.

Paso siguiente

Requisitos previos para la copia de seguridad de Azure Kubernetes Service