Matriz de compatibilidad de la copia de seguridad de Azure Kubernetes Service

Puede usar Azure Backup como ayuda en la protección de Azure Kubernetes Service (AKS). En este artículo se resume la disponibilidad por regiones, los escenarios admitidos y las limitaciones.

Regiones admitidas

• Azure Backup para AKS admite el almacenamiento de datos de copia de seguridad en los niveles Vault y Operational (Snapshot) en las siguientes regiones de Azure:

Centro de Australia, Centro de Australia 2, Este de Australia, Sudeste de Australia, Sur de Brasil, Sudeste de Brasil, Centro de Canadá, Este de Canadá, Centro de la India, Centro de EE. UU., Este de EE. UU., Este de EE. UU. 2, Centro de Francia, Sur de Francia, Norte de Alemania, Centro de Italia, Este de Japón, Oeste de Japón, Oeste de La India, Centro de Corea del Sur, Centro de Corea del Norte, Centro de Corea del Norte de EE. UU., Norte de Europa, Este de Noruega, Oeste de Noruega, Norte de Sudáfrica, Oeste de Sudáfrica, Centro-sur de EE. UU., Sur de la India, Sudeste asiático, Centro de Suecia, Norte de Suiza, Oeste de Suiza, Norte de Emiratos Árabes Unidos, Sur de Reino Unido, Oeste de Reino Unido, Centro-oeste de EE. UU., Oeste de EE. UU. 2, Oeste de EE. UU. 2, Oeste de EE. UU. 3

• Las siguientes regiones solo admiten el nivel Operativo (Instantánea):

Este de China 2, Este de China 3, Norte de China 2, Norte de China 3, US GOV Arizona, US GOV Texas, US GOV Virginia, Centro de Israel, Centro de Polonia y Centro de España

Escenarios compatibles

• Azure Backup para AKS solo admite clústeres que ejecutan versiones de Kubernetes compatibles. Esta es la lista de las versiones de Kubernetes admitidas. Si el clúster está en una versión no admitida, es posible que las operaciones de copia de seguridad se sigan ejecutando, pero no se tratan los errores durante la copia de seguridad o restauración. Para garantizar la compatibilidad completa y la confiabilidad, actualice a una versión compatible, valide las copias de seguridad y póngase en contacto con el soporte técnico si los problemas persisten.

• Azure Backup para AKS solo admite volúmenes persistentes basados en controladores CSI (Azure Disks). No se admiten complementos de volumen en árbol. Asegúrese de que el controlador CSI y la instantánea están habilitados para el clúster. Si están deshabilitados, habilite estas configuraciones. Además, si las cargas de trabajo usan volúmenes en árbol, migrelos a volúmenes basados en CSI para habilitar la compatibilidad con la copia de seguridad.

• Actualmente, Azure Backup para AKS solo admite volúmenes persistentes basados en disco de Azure aprovisionados mediante el controlador CSI. Las SKU de disco compatibles incluyen HDD estándar, SSD estándar y SSD Premium.

• Se admiten volúmenes aprovisionados de forma dinámica y estática; Sin embargo, para los volúmenes estáticos, la clase de almacenamiento debe definirse explícitamente en la especificación YAML ; de lo contrario, el volumen se omitirá durante la copia de seguridad.

• Azure Backup para AKS admite clústeres que usan una identidad administrada asignada por el sistema o asignada por el usuario. No se admiten los clústeres configurados con una entidad de servicio. Para habilitar la copia de seguridad, actualice el clúster para usar una identidad administrada asignada por el sistema o una identidad administrada asignada por el usuario.

• Azure Backup para AKS ofrece copias de seguridad de nivel operativo y de nivel de almacén. Las copias de seguridad de nivel operativo constan de instantáneas de tipos de volumen persistentes admitidos, junto con los metadatos almacenados en el contenedor de blobs especificados durante la instalación de la extensión de copia de seguridad. Por otro lado, las copias de seguridad del nivel de almacén se almacenan fuera del sitio, de forma segura y fuera del inquilino. Con la directiva de copia de seguridad, puede optar por habilitar copias de seguridad de nivel operativo y de almacén o usar solo el nivel operativo.

• Las instantáneas de volumen persistente tomadas como parte de la copia de seguridad del nivel operativo son coherentes por naturaleza. Aunque Azure Backup para AKS no admite actualmente tomar instantáneas de todos los PVs exactamente en el mismo milisegundo para lograr instantáneas coherentes entre volúmenes.

• La frecuencia mínima de copia de seguridad admitida en Azure Backup para AKS es cada 4 horas, con opciones adicionales para intervalos de 6, 8, 12 y 24 horas. Se espera que las copias de seguridad se completen en un período de 2 horas desde la hora de inicio programada. Estas frecuencias se aplican a las copias de seguridad de nivel operativo, lo que permite varias copias de seguridad al día. Sin embargo, solo la primera copia de seguridad correcta en un período de 24 horas es apta para transferirse al nivel de almacén. Una vez creada una copia de seguridad en el nivel operativo, puede tardar hasta cuatro horas en moverse al nivel de almacén.

• Backup Vault y el clúster de AKS deben encontrarse en la misma región. Sin embargo, pueden residir en suscripciones diferentes siempre que estén dentro del mismo inquilino.

• Azure Backup para AKS admite la restauración de copias de seguridad en el mismo clúster de AKS o en otro mediante copias de seguridad de nivel operativo y de almacén. El clúster de AKS de destino puede estar en la misma suscripción o en otra, conocida como Restauración entre suscripciones.

• Al restaurar desde el nivel operativo, el clúster de AKS de destino debe estar en la misma región que las copias de seguridad. Sin embargo, si las copias de seguridad se almacenan en el nivel de almacén con la configuración de almacenamiento con redundancia geográfica y restauración entre regiones habilitada en el almacén de Backup, puede restaurar a otra región dentro de una región emparejada de Azure.

• Para habilitar Azure Backup para AKS mediante la CLI de Azure, asegúrese de que usa la versión 2.41.0 o posterior. Para actualizar la CLI, ejecute el comando az upgrade.

• Para habilitar Azure Backup para AKS mediante Terraform, use la versión 3.99.0 o posterior.

• Azure Backup para AKS requiere que se instale una extensión de copia de seguridad. Esta extensión requiere una cuenta de almacenamiento y preferiblemente un contenedor de blobs vacío dentro de ella como entrada durante la instalación. No use un contenedor de blobs con archivos relacionados con copias de seguridad.

• La cuenta de almacenamiento especificada durante la instalación de la extensión de copia de seguridad debe estar en la misma región que el clúster de AKS. Solo se admiten las cuentas de almacenamiento de uso general v2; No se admiten cuentas de Premium Storage.

• Si el clúster de AKS se implementa dentro de una red virtual privada, se debe configurar un punto de conexión privado para habilitar las operaciones de copia de seguridad.

• La extensión de copia de seguridad solo se puede instalar en grupos de nodos que usan procesadores basados en x86 y ejecutan Ubuntu o Linux de Azure como sistema operativo.

• Tanto el clúster de AKS como los pods de extensión de copia de seguridad deben estar en un estado en ejecución y correcto antes de realizar operaciones de copia de seguridad o restauración, incluida la eliminación de puntos de recuperación expirados.

• Azure Backup para AKS proporciona alertas a través de Azure Monitor que le permite tener una experiencia coherente para la administración de alertas en diferentes servicios de Azure, incluidas las alertas clásicas, las alertas integradas de Azure Monitor y las alertas de registro personalizadas para las notificaciones de error de copia de seguridad. Las alertas de copia de seguridad admitidas están disponibles aquí.

• Azure Backup para AKS admite varios informes relacionados con la copia de seguridad. Actualmente, los datos de copia de seguridad solo se pueden ver seleccionando "Todo" para el tipo de carga de trabajo en los filtros de informe. Los informes de copia de seguridad admitidos están disponibles aquí.

• Azure Backup para AKS admite la eliminación temporal mejorada para las copias de seguridad almacenadas en el nivel de almacén, lo que proporciona protección contra la eliminación accidental o malintencionada. En el caso de las copias de seguridad almacenadas en el nivel operativo, las instantáneas subyacentes no están protegidas por eliminación temporal y se pueden eliminar permanentemente.

• Azure Backup para AKS admite la autorización multiusuario (MUA) que permite agregar una capa adicional de protección a las operaciones críticas en los almacenes de Backup donde se configuran las copias de seguridad.

• Azure Backup para AKS admite el almacén inmutable, que ayuda a proteger los datos de copia de seguridad evitando las operaciones que podrían provocar la pérdida de puntos de recuperación. Sin embargo, actualmente no se admite el almacenamiento WORM (escribir una vez, leer muchos) para las copias de seguridad.

• Azure Backup para AKS admite el cifrado de clave deCustomer-Managed (CMK), pero solo es aplicable a las copias de seguridad almacenadas en el nivel de almacén.

• Para que las operaciones de copia de seguridad y restauración se completen correctamente, la identidad administrada del almacén de Backup requiere las asignaciones de roles. Si no tiene los permisos necesarios, puede haber problemas de permisos durante las operaciones de configuración o restauración de copias de seguridad poco después de asignar roles, ya que las asignaciones de roles tardan unos minutos en surtir efecto. Obtenga información sobre las definiciones de roles.

Escenarios y limitaciones no admitidos

• Azure Backup para AKS no admite las siguientes SKU de disco de Azure: Discos SSD prémium v2 y Ultra.

• Azure File Shares, Azure Blob Storage y volúmenes persistentes basados en Azure Container Storage no son compatibles con AKS Backup. Si usa estos tipos de volúmenes persistentes en los clústeres de AKS, puede realizar una copia de seguridad de ellos por separado mediante soluciones dedicadas de Azure Backup. Para más información, consulte Copias de seguridad de recursos compartidos de Azure Files e Copias de seguridad de Azure Blob Storage.

• Los tipos de volumen persistente no admitidos se omiten automáticamente durante el proceso de copia de seguridad del clúster de AKS.

• La extensión de copia de seguridad no se puede instalar en grupos de nodos basados en Windows ni en grupos de nodos basados en ARM64. Los clústeres de AKS que usan estos nodos deben aprovisionar un grupo de nodos basado en Linux independiente (preferiblemente un grupo de nodos del sistema con procesadores basados en x86) para admitir la instalación de la extensión de copia de seguridad.

• Azure Backup para AKS no se admite actualmente para clústeres de AKS aislados de red.

• No instale la extensión de copia de seguridad de AKS junto con Velero ni con las soluciones de copia de seguridad basadas en Velero, ya que esto puede provocar conflictos durante las operaciones de copia de seguridad y restauración. Además, asegúrese de que los recursos de Kubernetes no usen etiquetas o anotaciones que contengan el prefijo velero.io, a menos que un escenario admitido requiera explícitamente. La presencia de estos metadatos puede provocar un comportamiento inesperado.

• No se admite la modificación de la configuración de copia de seguridad o el grupo de recursos de instantánea asignado a una instancia de copia de seguridad durante la instalación de copia de seguridad del clúster de AKS.

• Los siguientes espacios de nombres se omiten de la configuración de copia de seguridad y no se pueden configurar para las copias de seguridad: kube-system, kube-node-lease, kube-public.

• Azure Backup no escala automáticamente los nodos de AKS, solo restaura los datos y los recursos asociados. El escalado automático se administra mediante AKS, mediante características como Cluster Autoscaler. Si el escalado automático está habilitado en el clúster de destino, debe controlar el escalado de recursos automáticamente. Antes de restaurar, asegúrese de que el clúster de destino tenga suficientes recursos para evitar errores de restauración o problemas de rendimiento.

• Estos son los límites de copia de seguridad de AKS:

  Configuración	Límite
  Número de directivas de copia de seguridad por almacén de Backup	5\.000
  Número de instancias de copia de seguridad por almacén de Backup	5\.000
  Número de copias de seguridad a petición permitidas al día por instancia de Backup	10
  Número de espacios de nombres por instancia de copia de seguridad	800
  Número de restauraciones permitidas por instancia de copia de seguridad en un día	10

Limitaciones específicas de la copia de seguridad de almacén y restauración entre regiones

• Actualmente, los discos de Azure con volúmenes persistentes de tamaño <= 1 TB pueden moverse al nivel de almacén; los discos con el tamaño superior se omiten en los datos de copia de seguridad movidos al nivel de almacén.

• Actualmente, se admiten instancias de copia de seguridad con <= 100 discos conectados como volumen persistente. Es posible que se produzca un error en las operaciones de copia de seguridad y restauración si el número de discos es mayor que el límite.

• Solo los discos de Azure con acceso público habilitado desde todas las redes pueden moverse al nivel de almacén; si hay discos con acceso de red aparte del acceso público, se produce un error en la operación de almacenamiento por niveles.

• La característica de recuperación ante desastres solo está disponible entre regiones emparejadas de Azure (si la copia de seguridad está configurada en un almacén de copia de seguridad con redundancia geográfica con restauración entre regiones habilitada en ellas). Los datos de copia de seguridad solo están disponibles en una región emparejada de Azure. Por ejemplo, si tiene un clúster de AKS en este de EE. UU. que se realiza una copia de seguridad en un almacén de copia de seguridad con redundancia geográfica con restauración entre regiones habilitada en ellos, los datos de copia de seguridad también están disponibles en Oeste de EE. UU. para la restauración.

• En el nivel de almacén, solo se crea un punto de recuperación programado al día, lo que proporciona un objetivo de punto de recuperación (RPO) de 24 horas en la región primaria. En la región secundaria, la replicación de este punto de recuperación puede tardar hasta 12 horas adicionales, lo que da lugar a un RPO efectivo de hasta 36 horas.

• Cuando se crea una copia de seguridad en el nivel operativo y se convierte en apta para el nivel de almacén, el proceso de niveles puede tardar hasta cuatro horas en comenzar.

• Al mover copias de seguridad del nivel Operativo al nivel de almacén, la lógica de eliminación conserva las instantáneas esenciales para garantizar una correcta integridad de datos y operaciones de operaciones en niveles. En concreto, durante la ordenación por niveles del punto de recuperación más reciente (RP) en el almacén de origen (nivel operativo), se requieren instantáneas de las dos siguientes:

  • El último RP del nivel Operativo (almacén de origen).
  • Rp de protección anterior en el nivel de almacén (almacén de destino).

Como resultado, se conservan intencionadamente dos puntos de recuperación en el nivel operativo y no se eliminan:

• El RP más reciente en el nivel Operativo.
• Rp del nivel operativo vinculado al rp de nivel de almacén más reciente.

Este comportamiento evita la pérdida accidental de datos y garantiza copias de seguridad coherentes. Por lo tanto, puede observar que algunas copias de seguridad operativas persisten más tiempo que la directiva de retención diaria configurada debido a estas dependencias de niveles.

• Al mover copias de seguridad del nivel Operativo al nivel de almacén, la cuenta de almacenamiento proporcionada a la extensión de copia de seguridad debe tener habilitado el acceso a la red pública. Si la cuenta de almacenamiento está detrás de un firewall o tiene habilitado el acceso privado, asegúrese de que el almacén de Backup se agrega como servicio de confianza en la configuración de red de la cuenta de almacenamiento para permitir la transferencia de datos sin problemas.

• Durante la restauración desde el nivel de almacén, los recursos hidratados de la ubicación de almacenamiento provisional que incluye una cuenta de almacenamiento y un grupo de recursos no se limpian después de la restauración. Deben eliminarse manualmente.

• Durante la restauración, la cuenta de almacenamiento provisional debe tener habilitado el acceso a la red pública para permitir que el servicio de copia de seguridad acceda y transfiera datos. Sin acceso público, es posible que se produzca un error en la operación de restauración debido a restricciones de conectividad.

• Durante la restauración, si el clúster de AKS de destino se implementa dentro de una red virtual privada, debe habilitar un punto de conexión privado entre el clúster y la cuenta de almacenamiento provisional para garantizar una transferencia de datos segura y correcta.

• Si la versión de clúster de AKS de destino difiere de la versión usada durante la copia de seguridad, la operación de restauración puede producir un error o completarse con advertencias para varios escenarios, como los recursos en desuso en la versión más reciente del clúster. En el caso de restaurar desde el nivel de almacén, puede usar los recursos hidratados en la ubicación de almacenamiento provisional para restaurar los recursos de la aplicación en el clúster de destino.

• Actualmente, la copia de seguridad basada en el nivel de almacén no se admite con la implementación de Terraform.

Pasos siguientes

• Acerca de la copia de seguridad del clúster de Azure Kubernetes Service.
• Realice una copia de seguridad del clúster de Azure Kubernetes Service mediante Azure Portal, la CLI de Azure, Azure PowerShell, Azure Resource Manager, Bicep y Terraform.
• Restaure el clúster de Azure Kubernetes Service mediante Azure Portal, la CLI de Azure y Azure PowerShell.
• Administre copias de seguridad de Azure Kubernetes Service mediante Azure Backup.