Introducción a la solución de alta disponibilidad activo-activo recomendada 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. Si se produce un desastre que provoque que la región deje de estar disponible, 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.
Aunque hay varios patrones que pueden proporcionar capacidad de recuperación para una solución de AKS, en esta guía se describe la solución de alta disponibilidad activo-activo recomendada 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 ambos clústeres atienden activamente el tráfico.
Nota:
El siguiente caso de uso se puede considerar el procedimiento estándar dentro de AKS. Se ha revisado internamente y aprobado junto con nuestros asociados de Microsoft.
Introducción a la solución de alta disponibilidad activo-activo
Esta solución se basa en dos clústeres de AKS idénticos configurados para atender activamente el tráfico. Se coloca un administrador de tráfico global, como Azure Front Door, delante de los dos clústeres para distribuir el tráfico entre ellos. Debe configurar de forma coherente los clústeres para hospedar una instancia de todas las aplicaciones necesarias para que funcione la solución.
Las zonas de disponibilidad son otra manera de garantizar alta disponibilidad y tolerancia a errores del clúster de AKS dentro de la misma región. Las zonas de disponibilidad permiten distribuir los nodos del clúster entre varias ubicaciones aisladas dentro de una región de Azure. De este modo, si una zona se vuelve inactiva debido a una interrupción de energía, un error de hardware o un problema de red, el clúster puede seguir ejecutándose y atendiendo a las aplicaciones. Las zonas de disponibilidad también mejoran el rendimiento y la escalabilidad del clúster al reducir la latencia y la contención entre los nodos. Para configurar zonas de disponibilidad para el clúster de AKS, debe especificar los números de zona al crear o actualizar los grupos de nodos. Para más información, consulte ¿Qué son las zonas de disponibilidad en Azure?
Nota:
Las zonas de disponibilidad se admiten en muchas regiones. Considere el uso de regiones con zonas de disponibilidad para proporcionar mayor resistencia y disponibilidad para las cargas de trabajo. Para más información, consulte Recuperación a partir de una interrupción del servicio en toda la región.
Escenarios y configuraciones
Esta solución se implementa mejor al hospedar aplicaciones sin estado o con otras tecnologías también implementadas en ambas regiones, como el escalado horizontal. En escenarios en los que la aplicación hospedada depende de recursos, como las bases de datos, que se encuentran activamente en una sola región, se recomienda implementar una solución activo-pasivo para ahorra costos, ya que este tipo de solución tiene más tiempo de inactividad que activo-activo.
Componentes
La solución de alta disponibilidad activo-activo usa muchos servicios de Azure. En esta sección solo se tratan los componentes únicos de esta arquitectura de varios clústeres. Para más información sobre los componentes restantes, consulte la arquitectura de línea base de AKS.
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, la configuración de Azure Front Door enruta el tráfico de red entre todas las regiones. Si una región deja de estar disponible, el tráfico se enruta a una región con el tiempo de carga más rápido para el usuario.
Red en estrella tipo "hub and spoke" por región: se implementa un par de redes en estrella tipo "hub and spoke" por cada instancia de AKS regional. Las directivas de Azure Firewall Manager administran las directivas de firewall en todas las regiones.
Almacén de claves regional: se aprovisiona Azure Key Vault en cada región para almacenar valores y claves confidenciales específicos de la instancia de AKS y para admitir los servicios que se encuentran en esa región.
Azure Front Door: 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. Azure Front Door permite el enrutamiento global de nivel siete.
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 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 aplicación (regional)
Un objeto de implementación de Kubernetes crea varias réplicas de un pod (ReplicaSet). Si una no está disponible, el tráfico se enruta entre el resto de réplicas. 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. Los sondeos de ejecución pueden comprobar el estado de la aplicación o el 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 atender solicitudes. En este caso, la instancia de Azure Front Door enruta todo el tráfico al resto de 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 proceso tengan el tamaño adecuado de forma que puedan absorber el aumento repentino del tráfico debido a la conmutación por error de la región. 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.
- Use Horizontal Pod Autoscaler para aumentar el número de réplicas de pod a fin de compensar el aumento de la demanda regional.
- Use Cluster Autoscaler de AKS para aumentar el número de nodos de instancia de Kubernetes a fin de compensar el aumento de la demanda regional.
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 un error regional completo, Azure Front Door enruta el tráfico al resto de regiones en buen estado. De nuevo, asegúrese de compensar el aumento del tráfico y las solicitudes al resto del clúster.
Estrategia de pruebas de conmutación por error
Aunque actualmente no hay ningún mecanismo disponible en AKS para quitar una región entera de implementación con fines de prueba, Azure Chaos Studio ofrece la posibilidad de crear un experimento de caos en el clúster.
Pasos siguientes
Si estás considerando otra solución, consulta los artículos siguientes:
Azure Kubernetes Service