Alta disponibilidad y recuperación ante desastres en Azure Kubernetes Service (AKS)

Al crear y administrar aplicaciones en la nube, siempre existe el riesgo de sufrir interrupciones debido a cortes del servicio y desastres. Para garantizar la continuidad empresarial (BC), debe tener un plan para la alta disponibilidad (HA) y la recuperación ante desastres (DR).

La alta disponibilidad hace referencia al diseño y la implementación de un sistema o servicio que es muy confiable y que experimenta un tiempo de inactividad mínimo. La alta disponibilidad es una combinación de herramientas, tecnologías y procesos que garantizan que un sistema o servicio esté disponible para realizar su función prevista. La alta disponibilidad es un componente fundamental del planeamiento de la recuperación ante desastres. La recuperación ante desastres consiste en reponerse tras un desastre y restaurar las operaciones empresariales a un estado normal. La recuperación ante desastres es un subconjunto de BC, que es el proceso de mantener las funciones empresariales o reanudarlas rápidamente en caso de una interrupción importante.

En este artículo se tratan algunos procedimientos recomendados para las aplicaciones implementadas en AKS, pero de ninguna manera pretende ser una lista exhaustiva de posibles soluciones.

Información general sobre la tecnología

Un clúster de Kubernetes se divide en dos componentes:

• El plano de control, que proporciona los servicios básicos de Kubernetes y la orquestación de las cargas de trabajo de las aplicaciones, así como
• Los nodos que ejecutan las cargas de trabajo de las aplicaciones.

Cuando crea un clúster de AKS, la plataforma Azure crea y configura automáticamente un plano de control. AKS ofrece dos planes de tarifa para administrar clústeres: el nivel Gratis y el nivel estándar. Para más información, consulte Planes de tarifa Gratuito y Estándar para la administración de clústeres de AKS.

El plano de control y sus recursos solo residen en la región en la que creó el clúster. AKS proporciona un plano de control de inquilino único con un servidor de API, un planificador, etc. dedicados. El usuario define el número de nodos, así como su tamaño, y la plataforma Azure configura la comunicación segura entre el plano de control y los nodos. La interacción con el plano de control se produce a través de las API de Kubernetes, como kubectl o el panel de Kubernetes.

Para ejecutar las aplicaciones y los servicios de soporte técnico, necesitará un nodo de Kubernetes. Un clúster de AKS tiene al menos un nodo, una máquina virtual de Azure que ejecuta los componentes de nodo de Kubernetes y el entorno de ejecución del contenedor. El tamaño de la máquina virtual de Azure para los nodos define las CPU, la memoria, el tamaño y el tipo del almacenamiento disponible (por ejemplo, SSD de alto rendimiento o HDD normal). Planee el tamaño de almacenamiento y las VM en función de si las aplicaciones pueden requerir grandes cantidades de CPU y memoria o almacenamiento de alto rendimiento. En AKS, la imagen de máquina virtual para los nodos del clúster se basa en Ubuntu Linux, Azure Linux o Windows Server 2022. Al crear un clúster de AKS o escalar horizontalmente el número de nodos, la plataforma Azure crea y configura automáticamente el número solicitado de máquinas virtuales.

Para obtener más información sobre los componentes de carga de trabajo y clúster, consulte Conceptos básicos de Kubernetes para AKS.

Consideraciones importantes

Recursos regionales y globales

Los recursos regionales se aprovisionan como parte de un sello de implementación en una sola región de Azure. Estos recursos no comparten nada con los recursos de otras regiones y se pueden quitar o replicar de forma independiente en otras regiones. Para obtener más información, consulte Recursos regionales.

Los recursos globales comparten la vigencia del sistema y pueden estar disponibles globalmente en el contexto de una implementación de varias regiones. Para más información, consulte Recursos globales.

Objetivos de recuperación

Un plan de recuperación ante desastres completo debe especificar los requisitos empresariales de cada proceso que implementa la aplicación:

• Objetivo de punto de recuperación (RPO): duración máxima de la pérdida de datos que resulta aceptable. El RPO se mide en unidades de tiempo, como minutos, horas o días.
• El Objetivo de tiempo de recuperación (RTO) es la duración máxima del tiempo de inactividad aceptable, con el tiempo de inactividad definido por la especificación. Por ejemplo, si la duración del tiempo de inactividad aceptable en un desastre es de ocho horas, el RTO es de ocho horas.

Zonas de disponibilidad

Puede usar zonas de disponibilidad para distribuir los datos entre varias zonas de la misma región. Dentro de una región, las zonas de disponibilidad están lo suficientemente cerca como para tener conexiones de baja latencia con otras zonas de disponibilidad, pero están lo suficientemente separadas como para reducir la probabilidad de que más de una se vea afectada por interrupciones locales o el tiempo. Para obtener más información, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Resistencia zonal

Los clústeres de AKS son resistentes a errores zonales. Si se produce un error en una zona, el clúster continúa ejecutándose en las zonas restantes. El plano de control y los nodos del clúster se distribuyen entre las zonas y la plataforma Azure controla automáticamente la distribución de los nodos. Para obtener más información, consulte Resiliencia zonal de AKS.

Equilibrio de carga

Equilibrio de carga global

Los servicios de equilibrio de carga global distribuyen el tráfico en servidores de back-end regionales, nubes o servicios locales híbridos. Estos servicios enrutan el tráfico del usuario final al servidor de back-end disponible más cercano. También reaccionan a los cambios en la confiabilidad o el rendimiento del servicio, con el fin de maximizar la disponibilidad y el rendimiento. Los siguientes servicios de Azure proporcionan equilibrio de carga global:

• Azure Front Door
• Azure Traffic Manager
• Azure Load Balancer entre regiones
• Azure Kubernetes Fleet Manager

Equilibrio de carga regional

Los servicios regionales de equilibrio de carga distribuyen el tráfico de las redes virtuales entre las máquinas virtuales o puntos de conexión de servicio zonales y con redundancia de zona de una región. Los siguientes servicios de Azure proporcionan equilibrio de carga regional:

• Equilibrador de carga de Azure
• Introducción a Puerta de enlace de aplicaciones
• Azure Application Gateway for Containers

Observabilidad

Necesita recopilar datos de las aplicaciones y la infraestructura para permitir operaciones efectivas y una confiabilidad maximizada. Azure proporciona herramientas para ayudarle a supervisar y administrar las cargas de trabajo de AKS. Para obtener más información, consulte Recursos de observabilidad.

Definición del ámbito

El tiempo de actividad de la aplicación se vuelve importante a medida que administra clústeres de AKS. De forma predeterminada, AKS proporciona alta disponibilidad mediante el uso de varios nodos en un conjunto de escalado de máquinas virtuales (VMSS), pero estos nodos no protegen su sistema de un error de región. Para maximizar el tiempo de actividad, planee con antelación la continuidad empresarial y prepare todo lo necesario para la recuperación ante desastres con los siguientes procedimientos recomendados:

• Planear los clústeres de AKS en varias regiones.
• Enrutar el tráfico entre varios clústeres con Azure Traffic Manager.
• Usar la replicación geográfica para los registros de imágenes de contenedor.
• Planear el estado de la aplicación entre varios clústeres.
• Replicar el almacenamiento entre varias regiones.

Implementaciones del modelo de implementación

Modelo de implementación	Ventajas	Desventajas
Activo-activo	• Sin pérdidas de datos ni incoherencias durante la conmutación por error • Alta resistencia • Mejor uso de los recursos con un mayor rendimiento	• Implementación y administración complejas • Mayor coste • Necesidad de un equilibrador de carga y una forma de enrutamiento del tráfico
Activo-pasivo	• Implementación y administración más sencillas • Coste menor • Sin necesidad de un equilibrador de carga o un administrador de tráfico	• Potencial de pérdida de datos o incoherencias durante la conmutación por error • Tiempo de recuperación y tiempo de inactividad más largos • Infrautilización de los recursos
Pasivo-acceso esporádico	• Coste más bajo • Sin necesidad de sincronización, replicación, equilibrador de carga o administrador de tráfico • Adecuado para cargas de trabajo de prioridad baja y que no sean críticas	• Alto riesgo de pérdidas de datos o incoherencias durante la conmutación por error • Tiempo de recuperación y tiempo de inactividad más largos • Necesidad de intervención manual para activar el clúster y desencadenar la copia de seguridad

Modelo de implementación de alta disponibilidad activo-activo

En el modelo de implementación de alta disponibilidad (HA) activo-activo, tiene dos clústeres de AKS independientes implementados en dos regiones de Azure diferentes (normalmente regiones emparejadas, como Centro de Canadá y Este de Canadá o Este de EE. UU. 2 y Centro de EE. UU.) que atienden activamente el tráfico.

Con esta arquitectura de ejemplo:

• Implementará dos clústeres de AKS en regiones de Azure independientes.
• Durante las operaciones normales, el tráfico de red se enruta entre ambas regiones. Si una región deja de estar disponible, el tráfico se enruta automáticamente a la región más cercana al usuario que emitió la solicitud.
• Hay un par de estrella tipo hub-and-spoke implementado para cada instancia regional de AKS. Las directivas de Azure Firewall Manager administran las reglas de firewall en las regiones.
• Azure Key Vault se aprovisiona en cada región para almacenar secretos y claves.
• Azure Front Door equilibra la carga y enruta el tráfico a una instancia regional de Azure Application Gateway, que se encuentra delante de cada clúster de AKS.
• Las instancias regionales de Log Analytics almacenan métricas de redes regionales y registros de diagnóstico.
• Las imágenes de contenedor de la carga de trabajo se almacenan en un registro de contenedor administrado. Se usa una única instancia de Azure Container Registry para todas las instancias de Kubernetes del clúster. La replicación geográfica de Azure Container Registry permite replicar imágenes en las regiones de Azure seleccionadas y proporcionar acceso continuado a las imágenes incluso aunque una región experimente interrupciones.

Para crear un modelo de implementación activo-activo en AKS, realice los pasos siguientes:

1. Cree dos implementaciones idénticas en dos regiones de Azure diferentes.

2. Cree dos instancias de su aplicación web.

3. Cree un perfil de Azure Front Door con los siguientes recursos:

   • Extremo.
   • Dos grupos de origen, cada uno con una prioridad de uno.
   • Una ruta.

4. Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door. 5. Configure todos los demás servicios de back-end de Azure, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.

5. Implemente código en ambas aplicaciones web con implementación continua.

Para obtener más información, vea Descripción general de la solución de alta disponibilidad activa-activa recomendada para AKS.

Modelo de implementación de recuperación ante desastres activo-pasivo

En el modelo de implementación de recuperación ante desastres (DR) activo-pasivo, tiene dos clústeres de AKS independientes implementados en dos regiones de Azure diferentes (normalmente regiones emparejadas, como Centro de Canadá y Este de Canadá o Este de EE. UU. 2 y Centro de EE. UU.) que atienden activamente el tráfico. Solo uno de los clústeres atiende activamente el tráfico en un momento dado. El otro clúster contiene los mismos datos de configuración y aplicación que el clúster activo, pero no acepta tráfico a menos que lo dirija un administrador de tráfico.

Con esta arquitectura de ejemplo:

• Implementará dos clústeres de AKS en regiones de Azure independientes.
• Durante las operaciones normales, el tráfico de red se enruta al clúster de AKS principal, que se establece en la configuración de Azure Front Door.
  • La prioridad debe establecerse entre 1 y 5(1 corresponde al valor más alto y 5, al más bajo).
  • Puede establecer varios clústeres en el mismo nivel de prioridad y puede especificar el peso de cada uno.
• Si el clúster principal deja de estar disponible (se produce un desastre), el tráfico se enruta automáticamente a la siguiente región seleccionada en Azure Front Door.
  • Todo el tráfico debe pasar por el administrador de tráfico de Azure Front Door para que este sistema funcione.
• Azure Front Door enruta el tráfico a Azure App Gateway en la región primaria (el clúster debe marcarse con la prioridad 1). Si se produce un error en esta región, el servicio redirige el tráfico al siguiente clúster de la lista de prioridades.
  • Las reglas vienen de Azure Front Door.
• Se implementa un par en estrella tipo hub-and-spoke para cada instancia regional de AKS. Las directivas de Azure Firewall Manager administran las reglas de firewall en las regiones.
• Azure Key Vault se aprovisiona en cada región para almacenar secretos y claves.
• Las instancias regionales de Log Analytics almacenan métricas de redes regionales y registros de diagnóstico.
• Las imágenes de contenedor de la carga de trabajo se almacenan en un registro de contenedor administrado. Se usa una única instancia de Azure Container Registry para todas las instancias de Kubernetes del clúster. La replicación geográfica de Azure Container Registry permite replicar imágenes en las regiones de Azure seleccionadas y proporcionar acceso continuado a las imágenes incluso aunque una región experimente interrupciones.

Para crear un modelo de implementación activo-pasivo en AKS, realice los pasos siguientes:

1. Cree dos implementaciones idénticas en dos regiones de Azure diferentes.

2. Configure reglas de escalabilidad automática para la aplicación secundaria para que se escale al mismo recuento de instancias que la principal cuando la región primaria se vuelva inactiva. Mientras esté inactivo, no es necesario escalarlo verticalmente. Esto ayuda a reducir los costes.

3. Cree dos instancias de la aplicación web, con una en cada clúster.

4. Cree un perfil de Azure Front Door con los siguientes recursos:

   • Extremo.
   • Un grupo de origen con una prioridad de uno para la región primaria.
   • Un segundo grupo de origen con una prioridad de dos para la región secundaria.
   • Una ruta.

5. Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door.

6. Configure todos los demás servicios de back-end de Azure, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.

7. Implemente código en ambas aplicaciones web con implementación continua.

Para obtener más información, vea Descripción general de la solución de recuperación ante desastres activa-pasiva recomendada para AKS.

Modelo de implementación de conmutación por error pasivo-de acceso esporádico

El modelo de implementación de conmutación por error pasivo-de acceso esporádico se configura de la misma manera que el modelo de implementación de recuperación ante desastres activo-pasivo, a excepción de que los clústeres permanecen inactivos hasta que un usuario los activa en caso de desastre. Consideramos que este enfoque está fuera de alcance porque implica una configuración similar a la activa-pasiva, pero con la complejidad adicional de la intervención manual para activar el clúster y activar una copia de seguridad.

Con esta arquitectura de ejemplo:

• Creará dos clústeres de AKS, preferiblemente en diferentes regiones o zonas para una mejor resiliencia.
• Cuando necesite conmutar por error, active la implementación para asumir el flujo de tráfico.
• En caso de que el clúster pasivo principal deje de funcionar, deberá activar manualmente el clúster de acceso esporádico para que se haga cargo del flujo de tráfico.
• Esta condición debe establecerse mediante una entrada manual cada vez o un determinado evento según lo que haya especificado.
• Azure Key Vault se aprovisiona en cada región para almacenar secretos y claves.
• Las instancias regionales de Log Analytics almacenan métricas de redes regionales y registros de diagnóstico para cada clúster.

Para crear un modelo de implementación pasivo-de acceso esporádico en AKS, realice los pasos siguientes:

1. Cree dos implementaciones idénticas en dos regiones o zonas diferentes.
2. Configure reglas de escalabilidad automática para la aplicación secundaria para que se escale al mismo recuento de instancias que la principal cuando la región primaria se vuelva inactiva. Mientras esté inactivo, no es necesario escalarlo verticalmente, lo que ayuda a reducir los costes.
3. Cree dos instancias de la aplicación web, con una en cada clúster.
4. Configure todos los demás servicios de back-end de Azure, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.
5. Establezca una condición cuando se deba desencadenar el clúster de acceso esporádico. Si lo necesita, puede usar un equilibrador de carga.

Para obtener más información, vea Descripción general de la solución de conmutación por error pasiva-de acceso esporádico para AKS.

Límites y cuotas del servicio

AKS establece límites y cuotas predeterminados para recursos y características, incluidas restricciones de uso para determinadas SKU de VM.

Recurso	Límite
Clústeres máximos por suscripción globalmente	5000
Clústeres máximos por suscripción y región 1	100
Número máximo de nodos por clúster con Virtual Machine Scale Sets y el SKU estándar de Load Balancer	5000 entre todos los grupos de nodos Nota: si no puede escalar verticalmente hasta 5000 nodos por clúster, consulte Procedimientos recomendados para clústeres grandes.
Número máximo de nodos por grupo de nodos (grupos de nodos de Virtual Machine Scale Sets)	1000
Número máximo de grupos de nodos por clúster	100
Número máximo de pods por nodo: con el complemento de red de Kubenet 1	Máximo: 250 Valor predeterminado de la CLI de Azure: 110 Valor predeterminado de la plantilla de Azure Resource Manager: 110 Valor predeterminado de la implementación de Azure Portal: 30
Número máximo de pods por nodo: con Azure Container Networking Interface (Azure CNI)2	Máximo: 250 Máximo recomendado para contenedores de Windows Server: 110 Valor predeterminado: 30
Abrir el complemento de AKS Open Service Mesh	Versión del clúster de Kubernetes: versiones admitidas de AKS Controladores de OSM por clúster: 1 Pods por controlador OSM: 1600 Cuentas de servicio de Kubernetes administradas por OSM: 160
Número máximo de servicios de Kubernetes con equilibrio de carga por clúster con SKU de Standard Load Balancer	300
Número máximo de nodos por clúster con los conjuntos de disponibilidad de máquina virtual y el SKU básico de Load Balancer	100

¹ Se admiten más a petición.
² Los contenedores de Windows Server deben usar el complemento de red de Azure CNI. Kubenet no se admite para contenedores de Windows Server.

Nivel del plano de control de Kubernetes	Límite
Nivel Standard	Escala automáticamente el servidor de API de Kubernetes en función de la carga. Límites de componentes de plano de control más grandes e instancias de servidor de API/etcd.
Nivel gratis	Recursos limitados con un límite de solicitudes en proceso de 50 de mutación y de 100 llamadas de solo lectura Límite recomendado de 10 nodos por clúster. Lo mejor para experimentar, obtener información y realizar pruebas sencillas. No se recomienda para cargas de trabajo críticas o de producción.

Para más información, consulte Límites y cuotas del servicio AKS.

Backup

Azure Backup admite la copia de seguridad de los recursos del clúster de AKS y los volúmenes persistentes conectados al clúster mediante una extensión de copia de seguridad. El almacén de Backup se comunica con el clúster de AKS a través de la extensión para realizar operaciones de copia de seguridad y restauración.

Para más información, consulte los siguientes artículos.

• Acerca de la copia de seguridad de AKS mediante Azure Backup (versión preliminar)
• Copia de seguridad de AKS mediante Azure Backup (versión preliminar)