Confiabilidad en Azure Application Gateway para contenedores

Azure Application Gateway para contenedores es un servicio de equilibrio de carga de capa de aplicación administrada (nivel 7) y administración dinámica del tráfico para cargas de trabajo que se ejecutan en Kubernetes. Enruta las solicitudes entrantes a los destinos de back-end del clúster.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo Azure Application Gateway for Containers controla errores transitorios, errores de zona de disponibilidad, errores de toda la región y mantenimiento del servicio. También se describen las opciones de copia de seguridad y restauración y la información clave sobre el acuerdo de nivel de servicio (SLA).

Recomendaciones de implementación de producción para la confiabilidad

Application Gateway para contenedores es de alta disponibilidad de forma predeterminada. Para cargas de trabajo de producción:

Para obtener una arquitectura de ejemplo e instrucciones sobre la topología, el flujo de tráfico, la confiabilidad, la seguridad y las operaciones, consulte Implementar Application Gateway para contenedores en Azure Kubernetes Service.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

Una implementación de Application Gateway for Containers incluye recursos en Azure y en su clúster de Kubernetes.

• Recursos de Azure: el plano de control organiza la configuración del proxy de la puerta de enlace en función de su configuración. El plano de datos administrado Azure se ejecuta fuera del clúster y procesa el tráfico de la aplicación.
• Recursos de Kubernetes: Defina el enrutamiento y otra configuración mediante recursos de Kubernetes. El controlador ALB se ejecuta en el clúster, supervisa esos recursos y propaga la configuración a Application Gateway para contenedores en Azure.

Puede elegir entre dos estrategias de implementación. Con la estrategia bring your own (BYO), puede administrar el ciclo de vida de Application Gateway for Containers, asociación y recursos de front-end a través de herramientas de Azure. Con la estrategia administrada por ALB Controller, ALB Controller administra el ciclo de vida de esos recursos de Azure en función de los recursos de Kubernetes que defina.

Para obtener una descripción completa de los componentes, consulte Componentes de Application Gateway for Containers.

Después de implementar y configurar Application Gateway para contenedores, enruta las solicitudes entrantes a los destinos de back-end, que representan la aplicación que se ejecuta en Kubernetes.

Si el controlador ALB o el plano de control no están disponibles, el plano de datos continúa procesando el tráfico mediante la última configuración aplicada correctamente. Durante la interrupción, las actualizaciones de configuración no se propagan y el servicio no puede programar la configuración necesaria para los eventos de escalado horizontal.

Arquitectura física

Azure administra y escala automáticamente la infraestructura del plano de datos en función del tráfico de la aplicación. Application Gateway para contenedores siempre se implementa en una configuración de alta disponibilidad: en regiones que admiten zonas de disponibilidad, las puertas de enlace tienen redundancia de zona; en regiones que no admiten zonas de disponibilidad, Azure usa conjuntos de disponibilidad.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para más información, vea Recomendaciones para gestionar errores temporales.

Al usar Application Gateway para contenedores, tenga en cuenta los procedimientos recomendados siguientes:

• Implemente la lógica de reintento. Configure los clientes para reintentar las solicitudes después de fallos transitorios de conexión.

• Configure sondeos de estado con tolerancia. Si configura sondeos de estado personalizados, establezca el umbral de estado no correcto para tolerar los errores transitorios. El umbral de estado no correcto especifica el número de sondeos con error consecutivos que desencadenan que el destino back-end se marque como en mal estado. El sondeo de estado predeterminado usa un umbral de estado no correcto de tres sondeos, lo que ayuda a evitar que un único error transitorio del sondeo marque el back-end como en mal estado.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Al implementar Application Gateway para contenedores en una región de Azure que admita zonas de disponibilidad, Microsoft configura automáticamente el plano de control y el plano de datos como con redundancia de zona en varias zonas. No se seleccionan las zonas que usa el servicio.

Requisitos

Compatibilidad con regiones: Para usar la redundancia de zona, elija una región que admita Application Gateway for Containers y zonas de disponibilidad. Compruebe la disponibilidad regional de Application Gateway for Containers y compárela con la lista de regiones que admiten zonas de disponibilidad.

Consideraciones

Responsabilidad compartida con la plataforma de Kubernetes: Microsoft administra el redireccionamiento del tráfico para Application Gateway for Containers durante un fallo de zona. Para Azure Kubernetes Service (AKS), Microsoft administra el plano de control de Kubernetes. Es responsable de configurar la resistencia ante fallos de zona para los grupos de nodos del clúster y otros recursos que administre y para el comportamiento de las aplicaciones durante una interrupción de zona.

• Clúster: Configure los grupos de nodos de AKS y otros recursos de clúster enlazados a zona que administra para abarcar zonas de disponibilidad. AKS administra el plano de control; consulte Configurar zonas de disponibilidad para grupos de nodos de AKS.

• Sus cargas de trabajo: usted es responsable de implementar varias réplicas de pod, distribuirlas entre zonas y garantizar que haya cargas de trabajo back-end correctas disponibles para servir el tráfico durante una interrupción de zona. Puede usar grupos de nodos que abarquen zonas de disponibilidad, restricciones de propagación de topología y antiafinidad de pods.

• Objetos de configuración de Kubernetes: Application Gateway for Containers usa objetos de configuración de Kubernetes almacenados por la API de clúster. Su disponibilidad depende del plano de control de Kubernetes y de la configuración que administras en el clúster.

• Controlador ALB: Implemente el controlador ALB en el clúster de Kubernetes para conciliar la configuración. No forma parte de la ruta de acceso de datos de Application Gateway for Containers.

  El controlador ALB ejecuta dos réplicas, con una que actúa como líder y la otra como secundaria. Si el líder deja de estar disponible, la base de datos secundaria puede convertirse en líder y continuar propagando la configuración. Ambas réplicas se pueden ejecutar en la misma zona de disponibilidad, en función de cómo los programe el clúster. Es responsable de configurar los pods de clúster y controlador para la resiliencia de zona. Utilice restricciones de propagación de topología de pod o antiafinidad de pod para distribuir las réplicas entre zonas. Para más información, consulte Configuración de zonas de disponibilidad para grupos de nodos de AKS.

Cost

La compatibilidad con la zona de disponibilidad para Application Gateway para contenedores no conlleva cargos adicionales más allá de los precios del servicio estándar. Para obtener más información sobre los precios, consulte precios de Azure Application Gateway.

Configurar soporte de zonas de disponibilidad

Al implementar una nueva puerta de enlace en una región admitida, es con redundancia de zona de forma predeterminada. No es necesario habilitar la redundancia de zona en Azure recursos.

Es responsable de configurar el clúster de Kubernetes, el controlador ALB y las cargas de trabajo de back-end para la resistencia de zona.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar al implementar Application Gateway para contenedores en una región que admita zonas de disponibilidad y en la que todas las zonas usadas por el servicio estén operativas.

• Operación entre zonas: el plano de datos de Application Gateway for Containers administrado por Azure distribuye las solicitudes entrantes entre la infraestructura en varias zonas.

  Es responsable de configurar las cargas de trabajo de back-end para que se ejecuten entre zonas y proporcionar destinos en buen estado para recibir ese tráfico.

• Replicación de datos entre zonas: Application Gateway para contenedores no almacena los datos de la aplicación. La plataforma administra el estado de configuración a través del plano de control con redundancia de zona para proporcionar durabilidad y resistencia.

Comportamiento durante un fallo de zona

En esta sección se describe lo que puede esperar al implementar Application Gateway for Containers en una región que admite zonas de disponibilidad y una de las zonas usadas por el servicio tiene una interrupción.

• Detección y respuesta: Application Gateway for Containers redirige el tráfico a la infraestructura en las zonas en buen estado restantes durante una interrupción de zona. No es necesario tomar medidas para la redistribución del tráfico del gateway.

  Sin embargo, es responsable del efecto de la interrupción en el clúster de Kubernetes y las aplicaciones back-end.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Se quitan las conexiones existentes a la zona fallida. Los clientes deben reintentar las solicitudes siguiendo las instrucciones de Capacidad de recuperación ante errores transitorios. Se establecen nuevas conexiones a la infraestructura en el resto de zonas correctas.

• Pérdida de datos esperada: Application Gateway para contenedores no almacena los datos de la aplicación. La plataforma administra el estado de configuración a través del plano de control con redundancia de zona para proporcionar durabilidad y resistencia.

• Tiempo de inactividad esperado: Los clientes pueden experimentar una breve interrupción cuando se interrumpen las conexiones a la zona que ha fallado. Los clientes deben reintentar las solicitudes para establecer nuevas conexiones a la infraestructura en las zonas operativas restantes.

  El plano de control administrado Azure permanece disponible durante una interrupción de una sola zona. Sin embargo, la capacidad de aplicar actualizaciones de configuración también depende de la disponibilidad del plano de control de Kubernetes y del controlador ALB.

• Redistribución: Application Gateway for Containers redirige el tráfico a la infraestructura en las zonas en buen estado restantes.

Recuperación de zona

Application Gateway for Containers se recupera automáticamente de los problemas subyacentes. Azure administra la recuperación de la infraestructura de la puerta de enlace.

Prueba de fallos de zona

La plataforma de Application Gateway for Containers administra el enrutamiento del tráfico y la respuesta a los errores de zona para la propia puerta de enlace. No es necesario iniciar ni administrar la respuesta del gateway. Si tiene un clúster de Kubernetes que administra, puede usar Azure Chaos Studio para probar la respuesta del clúster a errores de zona. Para obtener más información, consulte Probar la resiliencia de las zonas de disponibilidad.

Resistencia a errores en toda la región

Application Gateway for Containers es un servicio de una sola región. Si la región de Azure en la que implementó un gateway deja de estar disponible, ese gateway no estará disponible.

Soluciones de varias regiones personalizadas para la resistencia

Application Gateway para contenedores no proporciona una implementación integrada de varias regiones ni una solución de conmutación por error. Para prepararse ante una interrupción regional, implemente y configure una puerta de enlace independiente y un clúster de Kubernetes en cada región. Es responsable de dirigir el tráfico entre las pasarelas regionales y configurar la conmutación por error.

• Configure Application Gateway for Containers de forma coherente entre regiones. Para simplificar las implementaciones y mantener las configuraciones alineadas, defina la infraestructura como código (IaC) mediante herramientas como Bicep o Terraform.

• Elija y configure un servicio global de administración del tráfico, como Azure Front Door o Azure Traffic Manager, para dirigir a los clientes a las puertas de enlace regionales. Estos servicios usan diferentes modelos de enrutamiento y configuraciones de sondeo de estado. Configure el servicio seleccionado para dirigir el tráfico fuera de una puerta de enlace no disponible y revise su documentación para comprender el comportamiento de enrutamiento y las consideraciones de conmutación por error. Azure Front Door también proporciona funcionalidades como la protección contra ataques de denegación de servicio distribuido (DDoS), las funcionalidades de firewall de aplicaciones web (WAF) y el enrutamiento basado en reglas.

• Implemente las aplicaciones back-end en cada región y configúrelas para proporcionar cargas de trabajo correctas durante una interrupción. Si sus aplicaciones dependen de datos u otros servicios de Azure también, diseñe y configure esos servicios para la disponibilidad multirregional. Revise la guía de confiabilidad de cada servicio para comprender sus opciones y limitaciones multirregión.

Copias de seguridad y restauración

Application Gateway para contenedores no almacena los datos de la aplicación. Azure Resource Manager almacena la configuración del recurso de Azure de la puerta de enlace. Puede volver a crear estos recursos volviendo a implementar su configuración.

Usted es responsable de conservar la configuración y los recursos de Kubernetes que definen cómo se implementa la puerta de enlace y enruta el tráfico:

• Defina los recursos Azure y su configuración en la infraestructura como código (IaC), como Bicep o Terraform, y mantenga las definiciones en el control de versiones. Puede usarlos para volver a desplegar los recursos del gateway.

• Realice una copia de seguridad de los recursos de Kubernetes que configuran la puerta de enlace, como los recursos ApplicationLoadBalancer, Gateway y HTTPRoute. Restáurelos en el clúster cuando necesite volver a crear la configuración de enrutamiento.

• Conserve la configuración relacionada, incluidas las reglas personalizadas y las directivas de firewall de aplicaciones web, en el control de versiones o a través del proceso de copia de seguridad de configuración estándar. Puede usar pipelines de implementación para volver a crear los recursos de Azure y Kubernetes de forma coherente.

Resistencia al mantenimiento del servicio

Microsoft administra el mantenimiento de Application Gateway para contenedores a la vez que mantiene la alta disponibilidad del servicio.

El tamaño mínimo de subred necesario de /24 para cada asociación tiene en cuenta las ventanas de mantenimiento, por lo que no es necesario asignar espacio de direcciones IP de subred adicional para el mantenimiento.

Para más información, consulte Escalado y disponibilidad de Application Gateway para contenedores.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte los SLAs de los servicios en línea.

El Acuerdo de Nivel de Servicio de Application Gateway para contenedores mide el plano de control y el plano de datos por separado. Ambos planes se tienen en cuenta en el cálculo general del Acuerdo de Nivel de Servicio.

Contenido relacionado

• Implementar Application Gateway para contenedores en Azure Kubernetes Service
• Confiabilidad en Azure