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
La compatibilidad de nivel operativo con la copia de seguridad de AKS se admite en todas las siguientes regiones de nube pública de Azure: Este de EE. UU., Norte de Europa, Oeste de Europa, Sudeste de Asia, Oeste de EE. UU. 2, Oeste de EE. UU., Oeste de EE. UU., Centro-norte de EE. UU., Centro de EE. UU., Centro-norte de EE. UU., Centro de Francia, Centro de Corea del Sur, Este de Australia, Este de Reino Unido, Este de Ee. UU., Este de Ee. UU., Este de Japón, Centro-sur de EE. UU., Centro de EE. UU. Oeste de EE. UU. 3, Centro de Canadá, Este de Canadá, Este de Australia, Centro de la India, Este de Noruega, Centro-oeste de Alemania, Norte de Suiza, Centro de Suecia, Oeste de Japón, Oeste de Reino Unido, Sur de Corea del Sur, Norte de Sudáfrica, Sur de Francia, Sur de Brasil, Norte de Emiratos Árabes Unidos, Este de China 2, Norte de China 3, USGov Virginia, USGov Arizona y USGov Texas.
La compatibilidad con la restauración entre regiones y niveles de almacén para la copia de seguridad de AKS está disponible en las siguientes regiones: Este de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU., Oeste de EE. UU. 3, Norte de Europa, Centro de Europa, Centro de EE. UU., Centro de EE. UU., Sur de Reino Unido, Este de Asia, Este de Asia, Este de Japón, Este de la India, Centro de La India, Centro de Canadá y Este de Noruega.
Nota:
Habilite la funcionalidad De restauración entre regiones para que el almacén de Backup tenga las copias de seguridad disponibles en una región emparejada de Azure. Consulte la lista de regiones emparejadas de Azure.
Limitaciones
La copia de seguridad de AKS admite clústeres de AKS con la versión 1.22 o posterior de Kubernetes. Esta versión tiene instalados controladores de Container Storage Interface (CSI).
Antes de instalar la extensión de copia de seguridad en un clúster de AKS, asegúrese de que los controladores CSI y las instantáneas estén habilitados para el clúster. Si están deshabilitados, habilite estas configuraciones.
Proporcione un contenedor de blobs nuevo y vacío como entrada al instalar la extensión de copia de seguridad en un clúster de AKS por primera vez. No use el mismo contenedor de blobs para más de un clúster de AKS.
Las copias de seguridad de AKS no admiten volúmenes del árbol. Solo puede hacer copias de seguridad de volúmenes basados en controladores CSI. Puede migrar de volúmenes de árbol a volúmenes persistentes basados en controladores CSI.
Actualmente, una copia de seguridad de AKS solo admite la copia de seguridad de volúmenes persistentes basados en discos de Azure (habilitados por el controlador CSI). Las SKU de disco de Azure admitidas son HDD estándar, SSD estándar y SSD prémium. No se admiten los discos que pertenecen a SSD Prémium v2 y SKU de disco Ultra. Se admiten volúmenes estáticos y aprovisionados dinámicamente. Para la copia de seguridad de discos estáticos, la especificación de volúmenes persistentes debe tener la clase de almacenamiento definida en el archivo YAML ; de lo contrario, estos volúmenes persistentes se omiten de la operación de copia de seguridad.
Los recursos compartidos de Azure Files y los volúmenes persistentes de Azure Blob Storage no son compatibles con la copia de seguridad de AKS debido a la falta de capacidad de instantáneas basada en el controlador CSI. Si usa dichos volúmenes persistentes en los clústeres de AKS, puede configurar copias de seguridad para ellos mediante las soluciones 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.
Se omite cualquier tipo de volumen persistente no admitido mientras se crea una copia de seguridad para el clúster de AKS.
Actualmente, no se admiten los clústeres de AKS que usan una entidad de servicio. Si el clúster de AKS usa una entidad de servicio para su autorización, puede actualizar el clúster para que use una identidad administrada asignada por el sistema o una identidad administrada asignada por el usuario.
Solo puede instalar la extensión de Backup en los nodos del agente con Ubuntu y Azure Linux como sistema operativo. Los clústeres de AKS con nodos de agente basados en Windows no permiten la instalación de la extensión de copia de seguridad.
No se puede instalar la extensión de copia de seguridad en el clúster de AKS con nodos de agente basados en Arm64 con independencia del sistema operativo (Ubuntu/Azure Linux/Windows) que se ejecute en estos nodos.
No instale la extensión de copia de seguridad de AKS junto con Velero ni con otros servicios de copia de seguridad basados en Velero. Esto podría provocar la interrupción del servicio de copia de seguridad durante las futuras actualizaciones de Velero controladas por usted o la copia de seguridad de AKS.
Debe instalar la extensión de copia de seguridad en el clúster de AKS. Si usa la CLI de Azure para instalar la extensión de copia de seguridad, asegúrese de que la versión sea la 2.41 o posterior. Utilice el comando
az upgradepara actualizar la CLI de Azure.El contenedor de blobs proporcionado como entrada durante la instalación de la extensión de copia de seguridad debe estar en la misma región y suscripción que el clúster de AKS. Solo se admiten contenedores de blobs en una cuenta de almacenamiento V2 de uso general y no se admite la cuenta de Premium Storage.
El almacén de Backup y el clúster de AKS deben estar en la misma región y suscripción.
Azure Backup para AKS proporciona copias de seguridad del nivel operativo (instantánea) y del nivel de almacén. Se pueden almacenar varias copias de seguridad al día en el nivel operativo, con solo una copia de seguridad al día que se almacenará en el almacén según la directiva de retención definida.
Actualmente, no se admite la modificación de la directiva de copia de seguridad ni la modificación del grupo de recursos de la instantánea (asignados a una instancia de copia de seguridad durante la configuración de la copia de seguridad del clúster de AKS).
Los clústeres de AKS y los pods de la extensión de copia de seguridad deben encontrarse en estado de ejecución para que se realicen las operaciones de copia de seguridad y restauración. Este estado incluye la eliminación de los puntos de recuperación expirados.
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.
El almacén de Backup no admite Azure Lighthouse. Por lo tanto, Lighthouse para Azure Backup para AKS no puede habilitar la administración entre inquilinos y no se pueden realizar copias de seguridad o restaurar clústeres de AKS entre inquilinos.
Los siguientes espacios de nombres se omiten de la configuración de copia de seguridad y no se configuran para las copias de seguridad:
kube-system,kube-node-lease,kube-public.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 Se admite la configuración de una cuenta de almacenamiento con punto de conexión privado.
Para habilitar Azure Backup para AKS a través de Terraform, su versión debe ser >= 3.99.
Limitaciones adicionales para la copia de seguridad y restauración entre regiones
Solo el disco 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.
La característica 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). 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. del que se realiza una copia de seguridad en un almacén de copia de seguridad con redundancia geográfica, los datos de copia de seguridad también estarán disponibles en Oeste de EE. UU. para la restauración.
Solo hay un punto de recuperación programado disponible en el nivel de almacén por día que proporciona un RPO de 24 horas en la región primaria. Para la región secundaria, el punto de recuperación puede tardar hasta 12 horas, lo que proporciona un RPO de 36 horas.
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. Tendrán que eliminarse manualmente.
En caso de que el clúster de destino esté dentro de una red virtual, habilite un punto de conexión privado entre el clúster y la cuenta de almacenamiento provisional.
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.