Implementación azul-verde de clústeres de AKS

Este artículo ofrece una guía para la implementación azul-verde de una estrategia que permita probar una nueva versión de un clúster de Azure Kubernetes Service (AKS) mientras continúa ejecutando la versión actual. Una vez validada la versión nueva, un cambio de enrutamiento cambia el tráfico de usuario a ella. Esta forma de implementar aumenta la disponibilidad al realizar cambios, incluidas las actualizaciones, en clústeres de AKS. En este artículo se describe el diseño y la implementación de una implementación azul-verde de AKS que usa servicios administrados de Azure y características nativas de Kubernetes.

Architecture

En esta sección se describen las arquitecturas para la implementación azul-verde de los clústeres de AKS. Hay dos casos:

• Las aplicaciones y las API están orientadas al público.
• Las aplicaciones y las API tienen acceso privado.

También hay un caso híbrido, no descrito aquí, en el que hay una combinación de aplicaciones y API tanto orientadas al público como privadas en el clúster.

En el diagrama siguiente se muestra la arquitectura del caso público:

Descargue un archivo Visio de esta arquitectura.

Azure Front Door y Azure DNS proporcionan el mecanismo de enrutamiento que cambia el tráfico entre los clústeres azul y verde. Para más información, consulte Implementación azul-verde con Azure Front Door. Con Azure Front Door, es posible implementar un conmutador completo o un conmutador más controlado basado en ponderaciones. Esta técnica es la más confiable y eficaz en un entorno de Azure. Si quiere usar su propio DNS y equilibrador de carga, debe asegurarse de que están configurados para proporcionar un conmutador seguro y confiable.

Azure Application Gateway proporciona los servidores front-end, que están dedicados a los puntos de conexión públicos.

Este diagrama es para el caso de acceso privado:

Descargue un archivo Visio de esta arquitectura.

En este caso, una única instancia de Azure DNS implementa el cambio de tráfico entre los clústeres azul y verde. Esto se hace mediante los registros A y CNAME. Para más información, consulte la sección T3: Cambio del tráfico al clúster verde.

Application Gateway proporciona los servidores front-end, que están dedicados a los puntos de conexión privados.

Flujo de trabajo

En una implementación azul-verde hay cinco fases para actualizar la versión actual del clúster a la versión nueva. En nuestra descripción, el clúster azul es la versión actual y el verde es la nueva.

Las fases son:

1. T0: El clúster azul está activado.
2. T1: Implementación del clúster verde.
3. T2: Sincronización del estado de Kubernetes entre los clústeres azul y verde.
4. T3: Cambio del tráfico al clúster verde.
5. T4: Destrucción del clúster azul.

Una vez que la versión nueva esté activa, se convierte en el clúster azul para cualquier cambio o actualización que ocurra a continuación.

Los clústeres azules y verdes se ejecutan al mismo tiempo, pero solo durante un período de limitado, lo que optimiza los costos y los esfuerzos operativos.

Desencadenadores de transición

Los desencadenadores para realizar la transición de fase a fase se pueden automatizar. Hasta que esto se logra, algunos o todos ellos son manuales. Los desencadenadores están relacionados con lo siguiente:

• Métricas de carga de trabajo específicas, objetivos de nivel de servicio (SLO) y contratos de nivel de servicio (SLA): se usan principalmente en la fase T3 para validar el estado general del clúster de AKS antes de cambiar el tráfico.
• Métricas de la plataforma Azure: se usan para evaluar el estado y la condición de las cargas de trabajo y el clúster de AKS. Se usan en todas las transiciones.

Detectabilidad de red de los clústeres

Puede proporcionar detectabilidad de red para los clústeres de las siguientes maneras:

• Con registros DNS que apunten a los clústeres. Por ejemplo:

  • aks-blue.contoso.com apunta a la dirección IP privada o pública del clúster azul.
  • aks-green.contoso.com apunta a la dirección IP privada o pública del clúster verde.

  Después, puede usar estos nombres de host directamente o en la configuración del grupo de back-end de la puerta de enlace de aplicaciones que está delante de cada clúster.

• Con registros DNS que apunten a las puertas de enlace de aplicaciones. Por ejemplo:

  • aks-blue.contoso.com apunta a la dirección IP privada o pública de la puerta de enlace de aplicación, que tiene como grupo de back-end la dirección IP privada o pública del clúster azul.
  • aks-green.contoso.com apunta a la dirección IP privada o pública de la puerta de enlace de aplicación, que tiene como grupo de back-end la dirección IP privada o pública del clúster verde.

T0: El clúster azul está activado

La fase inicial, T0, es que el clúster azul esté activo. Esta fase prepara la versión nueva del clúster para la implementación.

La condición de desencadenador para la fase T1 es la versión de una versión del clúster nueva, el clúster verde.

T1: Implementación del clúster verde

Esta fase comienza la implementación del clúster verde nuevo. El clúster azul permanece activado y el tráfico en directo todavía se enruta a él.

El desencadenador para pasar a la fase T2 es la validación del clúster de AKS verde en el nivel de plataforma. La validación usa métricas de Azure Monitor y comandos de la CLI para comprobar el estado de la implementación. Para más información, consulte Supervisión de Azure Kubernetes Service (AKS) con Azure Monitor de datos de Supervisión de la referencia de datos de AKS.

La supervisión de AKS se puede dividir en distintos niveles, como se muestra en el diagrama siguiente:

La condición del clúster se evalúa en los niveles 1 y 2, y en alguno de los niveles 3. Para el nivel 1, puede usar la vista nativa de varios clústeres de Monitor para validar el estado, como se muestra aquí:

En el nivel 2, asegúrese de que el servidor de API de Kubernetes y Kubelet funcionan correctamente. Puede usar el libro Kubelet en Monitor, específicamente, las dos cuadrículas del libro que muestran las estadísticas operativas clave de los nodos:

• La información general sobre la cuadrícula de nodos resume el número total de operaciones, errores y operaciones correctas en porcentaje, junto con la tendencia de cada nodo.
• La información general por cuadrícula de tipo de operación proporciona, para cada tipo de operación, el número de operaciones, errores y operaciones correctas por porcentaje y tendencia.

El nivel 3 está dedicado a los objetos y aplicaciones de Kubernetes que se implementan de forma predeterminada en AKS, como omsagent, kube-proxy, etc. Para esta comprobación, puede usar la vista Información de Monitor para comprobar el estado de las implementaciones de AKS:

Como alternativa, puedes usar el libro dedicado que se documenta en Implementación y métricas de HPA con Container Insights. Este es un ejemplo:

Una vez que la validación es correcta, puede realizar la transición a la fase T2.

T2: Sincronización del estado de Kubernetes entre los clústeres azul y verde

En esta fase, las aplicaciones, los operadores y los recursos de Kubernetes aún no se implementan en el clúster verde o, al menos, no todos ellos se pueden aplicar e implementar cuando se aprovisiona el clúster de AKS. El objetivo principal de esta fase es que, al final de la sincronización, el clúster verde sea compatible con versiones anteriores del azul. Si es así, es posible validar el estado del nuevo clúster antes de cambiar el tráfico al clúster verde.

Existen varias maneras de sincronizar el estado de Kubernetes entre clústeres:

• Reimplementación de integración continua y entrega continua (CI/CD). Normalmente, es suficiente usar las mismas canalizaciones de CI/CD que para la implementación normal de las aplicaciones. Las herramientas comunes para hacerlo son: Acciones de GitHub, Azure DevOps y Jenkins.
• GitOps, con soluciones promocionadas en el sitio web de Cloud Native Computing Foundation (CNCF), como Flux y ArgoCD.
• Una solución personalizada que almacena las configuraciones y los recursos de Kubernetes en un almacén de datos. Normalmente, estas soluciones se basan en generadores de manifiestos de Kubernetes que comienzan por definiciones de metadatos y, después, almacenan los manifiestos de Kubernetes generados en un almacén de datos como Azure Cosmos DB. Suelen ser soluciones personalizadas que se basan en el marco de descripción de la aplicación que está en uso.

En el diagrama siguiente se muestra el proceso de sincronización del estado de Kubernetes:

Normalmente, durante la sincronización, no se permite la implementación de versiones de aplicación nuevas en el clúster activo. Este período de tiempo comienza con la sincronización y finaliza cuando se completa el cambio al clúster verde. La manera de deshabilitar las implementaciones en Kubernetes puede variar. Las dos soluciones posibles son las siguientes:

• Deshabilitar las canalizaciones de implementación.

• Deshabilitar la cuenta de servicio de Kubernetes que ejecuta implementaciones.

  Es posible automatizar la deshabilitación de la cuenta de servicio mediante Open Policy Agent (OPA). Todavía no es posible usar características nativas de AKS porque aún están en versión preliminar.

El período de sincronización se puede evitar mediante mecanismos avanzados que administran el estado de Kubernetes en varios clústeres.

Cuando se completa la sincronización, se requiere la validación del clúster y las aplicaciones. Esto incluye:

• Una comprobación de las plataformas de supervisión y registro para validar el estado del clúster. Puede considerar la posibilidad de hacer lo mismo que en la fase T1: Implementación del clúster verde.
• Pruebas funcionales de la aplicación en función de la cadena de herramientas que está actualmente en uso.

Se recomienda ejecutar también una sesión de prueba de carga para comparar el rendimiento de las aplicaciones de clúster verde con una línea base de rendimiento. Puede usar su herramienta preferida o Azure Load Testing.

Normalmente, el clúster verde se expone en la puerta de enlace de aplicaciones o en el equilibrador de carga externo con una dirección URL interna que no es visible para los usuarios externos.

Cuando se valide el clúster nuevo, puede continuar con la siguiente fase para cambiar el tráfico a este.

T3: Cambio del tráfico al clúster verde

Una vez se ha completado la sincronización y validado el clúster verde en los niveles de plataforma y aplicación, está listo para ascender a clúster principal y empezar a recibir el tráfico en directo. El cambio se realiza en el nivel de red. A menudo, las cargas de trabajo no tienen estado. Pero si las cargas de trabajo tienen estado, se debe implementar una solución adicional para mantener el estado y el almacenamiento en caché durante el cambio.

Este es un diagrama que muestra el estado de destino después de aplicar el cambio:

Las técnicas que se describen en este artículo implementan cambios completos: el 100 % del tráfico se enruta al clúster nuevo. Esto se debe a que el enrutamiento se aplica en el nivel DNS con una asignación de registros A o CNAME que se actualiza para que apunte al clúster verde y a que hay una puerta de enlace de aplicaciones para cada clúster.

Este es un ejemplo de configuración para cambiar los puntos de conexión orientados al privado. La solución propuesta usa registros A para realizar el cambio. Desde una perspectiva de asignación de DNS e IP, la situación antes del cambio es la siguiente:

• A record aks.priv.contoso.com apunta a la dirección IP privada de la puerta de enlace de aplicaciones azul.
• A record aks-blue.priv.contoso.com apunta a la dirección IP privada de la puerta de enlace de aplicaciones azul.
• A record aks-green.priv.contoso.com apunta a la dirección IP privada de la puerta de enlace de aplicaciones verde.

El cambio vuelve a configurarse a lo siguiente:

• A record aks.priv.contoso.com apunta a la dirección IP privada de la puerta de enlace de aplicaciones verde.
• A record aks-blue.priv.contoso.com apunta a la dirección IP privada de la puerta de enlace de aplicaciones azul.
• A record aks-green.priv.contoso.com apunta a la dirección IP privada de la puerta de enlace de aplicaciones verde.

Los usuarios de los clústeres verán el cambio después del período de vida (TTL) y la propagación DNS de los registros.

En el caso de los puntos de conexión orientados al público, el enfoque recomendado usa Azure Front Door y Azure DNS. Esta es la configuración antes del cambio:

• CNAME record official-aks.contoso.com apunta a un registro del dominio de Azure Front Door generado automáticamente. Para más información, consulte el Tutorial: Incorporación de un dominio personalizado a Front Door.
• A record aks.contoso.com apunta a la dirección IP pública de la puerta de enlace de aplicaciones azul.
• La configuración de origen de Azure Front Door apunta al nombre de host aks.contoso.com. Para más información sobre cómo configurar los grupos de back-end, consulte Orígenes y grupos de origen en Azure Front Door.
  • A record aks-blue.contoso.com apunta a la dirección IP pública de la puerta de enlace de aplicaciones azul.
  • A record aks-green.contoso.com apunta a la dirección IP pública de la puerta de enlace de aplicaciones verde.

El cambio vuelve a configurarse a lo siguiente:

• CNAME record official-aks.contoso.com apunta a un registro del dominio de Azure Front Door generado automáticamente.
• A record aks.contoso.com apunta a la dirección IP pública de la puerta de enlace de aplicaciones verde.
• La configuración de origen de Azure Front Door apunta al nombre de host aks.contoso.com.
  • A record aks-blue.contoso.com apunta a la dirección IP pública de la puerta de enlace de aplicaciones azul.
  • A record aks-green.contoso.com apunta a la dirección IP pública de la puerta de enlace de aplicaciones verde.

Las técnicas de conmutación alternativas, como los conmutadores parciales para versiones controladas, son posibles con servicios de Azure adicionales, como Azure Front Door o Traffic Manager. Para ver una implementación de un conmutador de tráfico azul-verde en el nivel de Azure Front Door, consulte Implementación azul-verde con Azure Front Door.

Como se describe en el ejemplo, desde una perspectiva de red, esta técnica se basa en la definición de cuatro nombres de host:

• Nombre de host oficial orientado al público: el nombre de host público oficial que usan los usuarios finales y los consumidores.
• Nombre de host del clúster: el nombre de host oficial que usan los consumidores de las cargas de trabajo hospedadas en los clústeres.
• Nombre de host del clúster azul: el nombre de host dedicado para el clúster azul.
• Nombre de host del clúster verde: el nombre de host dedicado para el clúster verde.

El nombre de host del clúster es el que se ha configurado en el nivel de puerta de enlace de aplicaciones para administrar el tráfico de entrada. El nombre de host también forma parte de la configuración de entrada de AKS para administrar correctamente la seguridad de la capa de transporte (TLS). Este host solo se usa para transacciones y solicitudes en directo.

Si Azure Front Door también forma parte de la implementación, no se ve afectado por el cambio, ya que solo administra el nombre de host oficial del clúster. Proporciona la abstracción adecuada para los usuarios de la aplicación. No se ven afectados por el cambio, ya que el registro DNS CNAME siempre apunta a Azure Front Door.

Los nombres de host de clúster azul y verde se usan principalmente para probar y validar los clústeres. Para estos fines, los nombres de host se exponen en el nivel de puerta de enlace de aplicaciones con puntos de conexión dedicados y también en el nivel de controlador de entrada de AKS para administrar TLS de forma correcta.

En esta fase, la validación se basa en las métricas de infraestructura y supervisión de aplicaciones, y en el cierre de sesión único y el contrato de nivel de servicio oficiales, cuando están disponibles. Si la validación es correcta, realice la transición a la fase final para destruir el clúster azul.

T4: Destrucción del clúster azul

El cambio de tráfico correcto nos lleva a la fase final, en la que todavía se produce la validación y la supervisión para asegurar que el clúster verde funciona según lo previsto con el tráfico en directo. La validación y la supervisión abarcan el nivel de plataforma y de aplicación.

Una vez completada esta validación, se puede destruir el clúster azul. La destrucción es un paso que se recomienda encarecidamente para reducir los costos y hacer un uso adecuado de la elasticidad que proporciona Azure, especialmente AKS.

Esta es la situación después de que se destruya el clúster azul:

Componentes

• Application Gateway es un equilibrador de carga de tráfico web (OSI capa 7) que permite administrar el tráfico a las aplicaciones web. En esta solución se usa como puerta de enlace para el tráfico HTTP para acceder a los clústeres de AKS.
• Azure Kubernetes Service (AKS) es un servicio de Kubernetes administrado que puede usar para implementar y administrar aplicaciones contenedorizadas. Esta plataforma de aplicaciones es el componente principal de este patrón.
• Azure Container Registry es un servicio administrado que se usa para almacenar y administrar imágenes de contenedor y artefactos relacionados. En esta solución se usa para almacenar y distribuir imágenes y artefactos de contenedor, como gráficos de Helm, en los clústeres de AKS.
• Azure Monitor es una solución de supervisión para recopilar, analizar y responder a los datos de supervisión de los entornos en la nube y locales. Proporciona las características principales de supervisión necesarias para ejecutar la implementación azul verde. Se usa en esta arquitectura debido a su integración con AKS y su capacidad de proporcionar funcionalidades de registro, supervisión y alertas que se pueden usar para administrar las transiciones de fase.
• Azure Key Vault ayuda a resolver los siguientes problemas: administración de secretos, administración de claves y administración de certificados; se usa para almacenar y administrar los secretos y certificados necesarios en el nivel de aplicación y plataforma para esta solución.
• Azure Front Door es un equilibrador de carga global y un sistema de administración de puntos de conexión de aplicaciones. Se usa en esta solución como punto de conexión público para las aplicaciones HTTP hospedadas en AKS. En esta solución, tiene la responsabilidad fundamental de administrar el cambio de tráfico entre las Application Gateway azul y verde.
• Azure DNS es un servicio de hospedaje para dominios de DNS que ofrece resolución de nombres mediante la infraestructura de Microsoft Azure. Administra los nombres de host que se usan en la solución para los clústeres azul y verde, y desempeña un papel importante en los cambios de tráfico, especialmente para los puntos de conexión privados.

Alternativas

• Existen técnicas alternativas para implementar los cambios de tráfico que pueden proporcionar más control. Por ejemplo, es posible realizar un cambio parcial mediante reglas de tráfico basadas en uno o varios de los siguientes elementos:
  • Porcentaje del tráfico entrante
  • Encabezados HTTP
  • Cookies
• Otra alternativa que proporciona una mayor protección frente a problemas causados por cambios es tener implementaciones basadas en anillos. En lugar de solo clústeres azules y verdes, es posible tener más clústeres, denominados anillos. Cada anillo es lo suficientemente grande como para el número de usuarios que tiene acceso a la versión nueva de AKS. En cuanto a la implementación azul-verde que se describe aquí, los anillos se pueden quitar para tener la optimización y el control de costos adecuados.
• Las posibles alternativas a Application Gateway son NGINX y HAProxy.
• Una posible alternativa a Container Registry es Harbor.
• En algunas circunstancias, es posible usar diferentes servicios de equilibrio de carga y DNS para realizar los cambios de tráfico, en lugar de Azure Front Door y Azure DNS.
• Esta solución se basa en las API de Kubernetes del controlador de entrada estándar. Si la solución se beneficiaría en su lugar de la API de Gateway, use Application Gateway for Containers. Puede ayudar a administrar el equilibrio de carga y controlar la administración del tráfico de entrada entre Application Gateway y los pods. Application Gateway for Containers controla la configuración de las Application Gateway de aplicaciones.

Detalles del escenario

Las principales ventajas de la solución son las siguientes:

• Tiempo de inactividad minimizado durante la implementación.
• Estrategia de reversión planeada.
• Control y operaciones mejorados durante la versión y la implementación de cambios y actualizaciones de AKS.
• Pruebas para la necesidad de ejecutar procedimientos de recuperación ante desastres (DR).

En estos artículos se describen los principios clave y los aspectos fundamentales de la implementación azul-verde:

• ¿Qué es la infraestructura como código (IaC)?
• ¿Qué es la infraestructura mutable contra la inmutable?
• ¿Qué es informática elástica o la elasticidad de la nube?
• ¿Qué es la entrega continua?

Desde la perspectiva de la automatización y CI/CD, la solución se puede implementar de varias maneras. Se recomienda lo siguiente:

• Bicep o Terraform para IaC.
• Azure Pipelines o Acciones de GitHub para CI/CD.

Posibles casos de uso

La implementación azul-verde permite realizar cambios en clústeres sin que afecte a las aplicaciones y cargas de trabajo en ejecución. Algunos ejemplos de cambios son los siguientes:

• Cambios operativos
• Activación de nuevas características de AKS
• Cambios en los recursos compartidos de los clústeres
• Actualización de la versión de Kubernetes
• Modificación de recursos y objetos de Kubernetes, como la puerta de enlace de entrada, la malla de servicio, los operadores, las directivas de red, etc.
• Reversión a la versión anterior de un clúster de AKS que todavía está implementado, sin afectar a las cargas de trabajo que se ejecutan en el clúster

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

• La implementación azul-verde se puede automatizar completamente, como una implementación sin intervención táctil. Normalmente, una implementación inicial tiene desencadenadores manuales para activar las fases. A lo largo del proceso y con las características de madurez y supervisión adecuadas, es posible automatizar los desencadenadores. Esto significa que hay pruebas automatizadas y métricas específicas, contrato de nivel de servicio y cierre de sesión único, para automatizar los desencadenadores.
• Es importante tener nombres de host dedicados para los clústeres azules y verdes y también tener configuraciones de punto de conexión dedicadas en las puertas de enlace y equilibradores de carga que están delante de los clústeres. Esto es fundamental para mejorar la confiabilidad y la validez de la implementación del nuevo clúster. De este modo, la validación de la implementación se produce con la misma arquitectura y configuraciones de un clúster de producción estándar.
• Considere una situación en la que los clústeres de AKS sean recursos compartidos para varias aplicaciones administradas por diferentes unidades de negocio. En casos así, es habitual que la propia plataforma de AKS esté administrada por un equipo dedicado responsable del funcionamiento general y el ciclo de vida de los clústeres, y que haya puntos de conexión en los clústeres con fines de administración y operaciones. Se recomienda que estos puntos de conexión tengan un controlador de entrada dedicado en los clústeres de AKS para una separación adecuada de los problemas y para la confiabilidad.
• La implementación azul-verde es útil para implementar y probar soluciones de continuidad empresarial y recuperación ante desastres (BC/DR) para AKS y cargas de trabajo relacionadas. En concreto, proporciona las estructuras fundamentales para administrar varios clústeres, incluidos los casos en los que los clústeres se distribuyen entre varias regiones.
• El éxito con la implementación azul-verde se basa en aplicar todos los aspectos de la implementación, como la automatización, la supervisión y la validación, no solo a la plataforma de AKS, sino también a las cargas de trabajo y las aplicaciones que se implementan en la plataforma. Esto le ayuda a obtener el máximo beneficio de la implementación azul-verde.
• En la solución propuesta hay dos Application Gateway por cada escenario público y privado, por lo que hay cuatro en total. Esta decisión consiste en aplicar la implementación azul verde en el nivel de Azure Application Gateway para evitar tiempos de inactividad causados por una configuración incorrecta de las puertas de enlace. El principal inconveniente de esta decisión es el coste, ya que hay cuatro instancias de Application Gateway. Se ejecutan en paralelo solo en el período de tiempo en el que hay cambios relevantes en las configuraciones de Application Gateway, como directivas WAF o una configuración de escalado. Para una mayor optimización de costes, puede optar por una sola instancia de Application Gateway por cada escenario, lo que significa dos Application Gateway en total. Esto requerirá que mueva la lógica azul/verde a Application Gateway, en lugar de Azure Front Door. Así, en lugar de que Azure Front Door se controle de forma imperativa, lo hace Application Gateway.

Confiabilidad

La confiabilidad garantiza que tu aplicación puede cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

• La implementación azul-verde tiene un efecto directo y positivo en la disponibilidad de la plataforma y las cargas de trabajo de AKS. En concreto, aumenta la disponibilidad durante la implementación de cambios en la plataforma de AKS. Hay poco tiempo de inactividad si las sesiones de usuario se administran correctamente.
• La implementación azul-verde proporciona cobertura de confiabilidad durante la implementación porque, de forma predeterminada, existe la opción de revertir a la versión anterior del clúster de AKS si algo va mal en la versión nueva del clúster.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

• La implementación azul-verde se adopta ampliamente en Azure debido a la elasticidad nativa proporcionada por la nube. Esto permite optimizar los costos en términos de operaciones y consumo de recursos. La mayoría de los ahorros se producen al quitar el clúster que ya no es necesario después de implementar correctamente una versión nueva.
• Cuando se implementa una versión nueva, es habitual hospedar los clústeres azules y verdes de la misma subred para seguir teniendo la misma línea base de costo. Todas las conexiones de red y el acceso a los recursos y servicios son los mismos para los dos clústeres, y todos los servicios y recursos de Azure siguen siendo los mismos.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

• La implementación azul-verde, implementada correctamente, proporciona automatización, entrega continua e implementación resistente.
• Uno de los aspectos clave de la entrega continua es que ofrece iterativamente incrementos de cambios de plataforma y carga de trabajo. Con la implementación azul-verde de AKS, se logra la entrega continua en el nivel de plataforma, de forma controlada y segura.
• La resistencia es fundamental para la implementación azul-verde, ya que incluye la opción de revertir al clúster anterior.
• La implementación azul-verde proporciona el nivel adecuado de automatización para reducir el esfuerzo relacionado con la estrategia de continuidad empresarial.
• La supervisión de la plataforma y las aplicaciones es fundamental para una implementación correcta. Para la plataforma, es posible usar las funcionalidades nativas de supervisión de Azure. Para las aplicaciones, la supervisión debe diseñarse e implementarse.

Implementación de este escenario

Para obtener un ejemplo implementado de la implementación azul-verde descrita en esta guía, consulte Acelerador de zonas de aterrizaje de AKS.

Esta implementación de referencia se basa en Application Gateway y ¿Qué es el controlador de entrada de Application Gateway?. Cada clúster tiene su propia puerta de enlace de aplicaciones y el conmutador de tráfico se realiza mediante DNS, en particular mediante la configuración CNAME.

Consideraciones sobre las regiones

Puede implementar los clústeres azules y verdes en regiones independientes o en la misma región. El diseño y los principios operativos no se ven afectados por esta elección. Pero algunos tipos de configuraciones de red adicionales pueden verse afectados, como los siguientes:

• Una red virtual dedicada y una subred para AKS y la puerta de enlace de aplicación.
• Conexión con servicios de respaldo como Monitor, Container Registry y Key Vault.
• Visibilidad de Azure Front Door de la puerta de enlace de aplicaciones.

Hay requisitos previos para la implementación en la misma región:

• Las redes virtuales y subredes deben tener el tamaño para hospedar dos clústeres.
• La suscripción de Azure debe proporcionar capacidad suficiente para los dos clústeres.

Implementación del controlador de entrada y equilibradores de carga externos

Hay diferentes enfoques para la implementación del controlador de entrada y equilibradores de carga externos:

• Puede tener un único controlador de entrada con un equilibrador de carga externo dedicado, como la implementación de referencia de la arquitectura descrita en esta guía. AGIC es una aplicación de Kubernetes que permite usar el equilibrador de carga L7 de Application Gateway para exponer el software en la nube en Internet. En determinados escenarios, hay puntos de conexión de administrador en los clústeres de AKS además de los puntos de conexión de la aplicación. Los puntos de conexión de administrador son para realizar tareas operativas en las aplicaciones o para tareas de configuración, como actualizar mapas de configuración, secretos, directivas de red y manifiestos.
• Puede tener un único equilibrador de carga externo que sirva varios controladores de entrada que se implementan en el mismo clúster o en varios clústeres. Este enfoque no se trata en la implementación de referencia. En este escenario, se recomienda tener puertas de enlace de aplicaciones independientes para puntos de conexión orientados al público y para los privados.
• La arquitectura resultante que se propone y se describe en esta guía se basa en un controlador de entrada estándar que se implementa como parte del clúster de AKS, como NGINX y Envoy. En la implementación de referencia, usamos AGIC, lo que significa que hay una conexión directa entre la puerta de enlace de aplicaciones y los pods de AKS, pero esto no afecta a la arquitectura azul-verde general.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Vincenzo Morra | Arquitecto de incubación de SAO

Otros colaboradores:

• Oscar Pla Alvarez | Arquitecto de soluciones de dominio

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• ¿Qué es la infraestructura como código (IaC)?
• Implementación azul-verde (Martin Fowler)
• Documentación de AKS
• Documentación sobre Azure Monitor
• Acelerador de zonas de aterrizaje de AKS para implementaciones azul-verde
• Patrón de arquitectura para cargas de trabajo críticas en Azure
• Servicios de Azure para la protección de la conectividad de red
• Microsoft Cloud Adoption Framework para Azure

Recursos relacionados

• Línea base de AKS para clústeres de varias regiones
• Introducción a la misión crítica de Azure
• Implementaciones críticas sin tiempo de inactividad de Azure
• Validación continua crítica de Azure