Descripción general de la solución pasiva en frío 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 pasiva en frío para AKS. Dentro de esta solución, se implementan dos clústeres de AKS independientes e idénticos en dos regiones de Azure emparejados con solo un clúster que atiende activamente el tráfico cuando se necesita la aplicación.

Nota:

La práctica siguiente se ha revisado internamente y se ha examinado junto con nuestros asociados de Microsoft.

Descripción general de la solución de frío pasivo

En este enfoque, tenemos dos clústeres de AKS independientes que se implementan en dos regiones de Azure. Cuando se necesita la aplicación, activamos el clúster pasivo para recibir tráfico. Si el clúster pasivo deja de funcionar, debemos activar manualmente el clúster de acceso esporádico para asumir el flujo de tráfico. Podemos establecer esta condición a través de una entrada manual cada vez o para especificar un evento determinado.

Escenarios y configuraciones

Esta solución se implementa mejor como una carga de trabajo de "uso según sea necesario", que es útil para escenarios que requieren que las cargas de trabajo se ejecuten en horas específicas del día o se ejecuten a petición. Algunos casos de uso de ejemplo para un enfoque pasivo-frío incluyen:

  • Una empresa de fabricación que necesita ejecutar una simulación compleja e intensiva de recursos en un conjunto de datos grande. En este caso, el clúster pasivo se encuentra en una región en la nube que ofrece servicios de almacenamiento e informática de alto rendimiento. El clúster pasivo solo se usa cuando el usuario desencadena la simulación o mediante una programación. Si el clúster no funciona al activarse, el clúster en frío puede utilizarse como copia de seguridad y la carga de trabajo puede ejecutarse en él en su lugar.
  • Una agencia gubernamental que necesita mantener una copia de seguridad de sus sistemas críticos y datos en caso de ataque cibernético o desastre natural. En este caso, el clúster pasivo se encuentra en una ubicación segura y aislada que no es accesible para el público.

Componentes

La solución de recuperación ante desastres pasiva en frío utiliza numerosos 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. Cuando se necesita la aplicación, el clúster pasivo se activa para recibir tráfico de red.

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.

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.

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 utiliza 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 el clúster pasivo no funciona correctamente debido a un problema en la región específica de Azure donde se encuentra, puede activar el clúster en frío y redirigir todo el tráfico a la región de ese clúster. Puedes usar este proceso mientras el clúster pasivo se desactiva hasta que empiece a funcionar de nuevo. El clúster de acceso esporádico puede tardar un par de minutos en conectarse, ya que se ha desactivado y necesita completar el proceso de configuración. Este enfoque no es ideal para aplicaciones sensibles al tiempo. En ese caso, recomendamos considerar una conmutación por error de tipo activo-activo.

Grupos 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 permiten comprobar 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 aplicación (global)

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 regiones restantes en buen estado. Los clústeres y pods de Kubernetes de estas regiones siguen 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.
  • Utilice el Horizontal Pod Autoscaler para aumentar el número de réplicas de pods a fin de compensar el aumento de la demanda regional.
  • Utilice Cluster Autoscaler de AKS para aumentar el número de nodos de instancia del clúster de Kubernetes para 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 impedir que los nodos de AKS se conviertan en un único punto de error regional, use Azure Availability Zones. Las zonas de disponibilidad garantizan que los nodos de AKS de una zona de disponibilidad determinada estén físicamente separados de los definidos en otra.

Grupos de nodos de Kubernetes (global)

En caso de una caída total de una región, Azure Front Door redirige el tráfico a las demás regiones en buen estado. De nuevo, asegúrese de compensar el aumento de tráfico y de 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ás considerando otra solución, consulta los artículos siguientes:

  • Se actualizó por última vez el