Modelos de implementación de varias regiones para Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) proporciona un entorno de Kubernetes administrado para implementar, administrar y escalar aplicaciones en contenedores. Para proporcionar resistencia a interrupciones regionales para las aplicaciones que se ejecutan en AKS, puede implementar varios modelos de implementación de varias regiones. En este artículo se proporciona información general sobre estos modelos, sus ventajas y desventajas, y los procedimientos recomendados para mantener el tiempo de actividad de la aplicación.

AKS proporciona una variedad de funcionalidades que admiten alta disponibilidad (HA) y recuperación ante desastres (DR) para el clúster y las aplicaciones que se ejecutan en AKS. Para obtener más información sobre cómo AKS admite los requisitos de confiabilidad, consulte Confiabilidad en AKS.

Consideraciones

A continuación se muestran algunas consideraciones importantes al implementar modelos de implementación de varias regiones en AKS:

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.

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

Definición de á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 despliegue multiregión

En la tabla siguiente se resumen los tres modelos de implementación de varias regiones principales en AKS, junto con sus ventajas y desventajas:

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:

   • Un punto de conexión.
   • 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:

   • Un punto de conexión.
   • 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.

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

• Confiabilidad en AKS
• 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)
• Continuidad empresarial, alta disponibilidad y recuperación ante desastres