Introducción a la solución de recuperación ante desastres activa-pasiva para Azure Kubernetes Service (AKS)

Cuando se crea una aplicación en Azure Kubernetes Service (AKS) y se elige una región de Azure durante la creación de recursos, la aplicación es de una sola región. Cuando la región deja de estar disponible durante un desastre, la aplicación también deja de estar disponible. Si crea una implementación idéntica en una región secundaria de Azure, la aplicación se vuelve menos susceptible a un desastre en una sola región, lo que garantiza la continuidad empresarial, y cualquier replicación de datos en las regiones le permite recuperar el último estado de la aplicación.

En esta guía se describe una solución de recuperación ante desastres activa-pasiva para AKS. Dentro de esta solución, se implementan dos clústeres de AKS independientes e idénticos en dos regiones de Azure emparejadas donde solo un clúster atiende activamente el tráfico.

Introducción a la solución activa-pasiva

En este enfoque de recuperación ante desastres, tenemos dos clústeres de AKS independientes que se implementan en dos regiones de Azure. Sin embargo, solo uno de los clústeres atiende activamente el tráfico en cualquier momento. El clúster secundario (que no gestiona activamente el tráfico) contiene los mismos datos de configuración y de la aplicación que el clúster principal, pero no acepta tráfico a menos que así lo indique el administrador de tráfico de Azure Front Door.

Escenarios y configuraciones

Esta solución se implementa mejor al hospedar aplicaciones que dependen de recursos, como bases de datos, que sirven activamente el tráfico en una región. En escenarios en los que necesita hospedar aplicaciones sin estado implementadas en ambas regiones, como el escalado horizontal, se recomienda considerar una solución activa-activa, ya que activa-pasiva implica una latencia agregada.

Componentes

La solución de recuperación ante desastres activa-pasiva usa muchos servicios de Azure. Esta arquitectura de ejemplo implica los siguientes componentes:

Varios clústeres y regiones: se implementan varios clústeres de AKS, cada uno en una región de Azure distinta. 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.

Priorización de clúster configurada: establece un nivel de priorización entre 1 y 5 para cada clúster (con 1 siendo la prioridad más alta y 5 es la prioridad más baja). Puede establecer varios clústeres en el mismo nivel de prioridad y especificar el peso de cada clúster. Si el clúster principal deja de estar disponible, el tráfico se enruta automáticamente a la siguiente región seleccionada en Azure Front Door. Todo el tráfico debe pasar por Azure Front Door para que este sistema funcione.

Azure Front Door: Azure Front Door equilibra la carga y enruta el tráfico a la instancia de Azure Application Gateway en la región primaria (el clúster debe marcarse con prioridad 1). En caso de error de región, el servicio redirige el tráfico al siguiente clúster de la lista de prioridades.

Para más información, consulte Enrutamiento de tráfico basado en la prioridad.

Par hub-spoke: Se implementa un par hub-spoke para cada instancia regional de AKS. Las directivas de Azure Firewall Manager administran las reglas de firewall en cada región.

Key Vault: aprovisiona una instancia de Azure Key Vault en cada región para almacenar secretos y claves.

Log Analytics: las instancias regionales de Log Analytics almacenan métricas de redes regionales y registros de diagnóstico. Una instancia compartida almacena métricas y registros de diagnóstico de todas las instancias de AKS.

Container Registry: las imágenes de contenedor de la carga de trabajo se almacenan en un registro de contenedor administrado. Con esta solución, 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 si una región experimenta interrupciones.

Proceso de conmutación por error

Si un servicio o componente del servicio deja de estar disponible en una región, el tráfico se debe enrutar a una región donde ese servicio esté disponible. Una arquitectura de varias regiones incluye muchos puntos de error diferentes. En esta sección, tratamos los posibles puntos de error.

Pods de aplicaciones (regionales)

Un objeto de implementación de Kubernetes crea varias réplicas de un pod (ReplicaSet). Si una de ellas no está disponible, el tráfico se redirige entre las réplicas restantes. ReplicaSet de Kubernetes intenta mantener en funcionamiento el número especificado de réplicas. Si una instancia queda inactiva, se debe volver a crear otra. Las sondas de actividad pueden verificar el estado de la aplicación o del proceso que se ejecuta en el pod. Si el pod no responde, el sondeo de ejecución lo quita, lo que obliga a ReplicaSet a crear una nueva instancia.

Para más información, consulte ReplicaSet de Kubernetes.

Pods de aplicaciones (globales)

Cuando toda una región deja de estar disponible, los pods del clúster ya no están disponibles para procesar solicitudes. En este caso, la instancia de Azure Front Door dirige todo el tráfico a las demás regiones en buen estado. Los clústeres y pods de Kubernetes de estas regiones seguirán atendiendo solicitudes. Para compensar el aumento del tráfico y las solicitudes al resto del clúster, tenga en cuenta lo siguiente:

• Asegúrese de que los recursos de red y de computación estén dimensionados correctamente para absorber cualquier aumento repentino del tráfico debido a la conmutación por error regional. Por ejemplo, al usar Container Network Interface (CNI) de Azure, asegúrate de tener una subred que pueda admitir todas las direcciones IP del pod con una carga de tráfico máxima.
• Utiliza el Horizontal Pod Autoscaler para aumentar el número de réplicas del pod a fin de compensar el aumento de la demanda regional.
• Use el Cluster Autoscaler de AKS para aumentar el número de nodos de Kubernetes y compensar el aumento de la demanda en la región.

Grupos de nodos de Kubernetes (regional)

En ocasiones, se puede producir un error localizado en los recursos de proceso, como que un único bastidor de servidores de Azure no reciba alimentación. Para evitar que los nodos de AKS de esta solución activa-pasiva se conviertan en un único punto de fallo regional, use Azure Availability Zones. Las zonas de disponibilidad garantizan que los nodos de AKS de cada zona de disponibilidad estén separados físicamente de los definidos en otra zona de disponibilidad.

Grupos de nodos de Kubernetes (global)

En caso de una caída regional completa, Azure Front Door redirige el tráfico a las demás regiones en buen estado. De nuevo, asegúrese de tener en cuenta el aumento del tráfico y de las solicitudes en el clúster restante.

Estrategia de pruebas de conmutación por error

Aunque actualmente no existen mecanismos en AKS para dejar fuera de servicio una región de implementación completa con fines de prueba, puede utilizar Azure Chaos Studio Workspaces para simular la caída de una zona de disponibilidad en los grupos de nodos del clúster.

Pasos siguientes

Si está considerando otra solución, consulte los artículos siguientes:

• Descripción general de la solución de alta disponibilidad activa-activa para Azure Kubernetes Service (AKS)
• Descripción general de la solución pasiva en frío para Azure Kubernetes Service (AKS)