Línea base de AKS para clústeres de varias regiones

En esta arquitectura se detalla cómo ejecutar varias instancias de un clúster de Azure Kubernetes Service (AKS) en varias regiones en una configuración activo/activo y de alta disponibilidad.

Esta arquitectura se basa en la arquitectura de línea de base de AKS, el punto de partida recomendado de Microsoft para la infraestructura de AKS. La línea de base de AKS detalla las características de infraestructura, como la identidad de carga de trabajo de Microsoft Entra, las restricciones de entrada y salida, los límites de los recursos y otras configuraciones seguras de la infraestructura de AKS. Estos detalles de infraestructura no se tratan en este documento. Se recomienda familiarizarse con la línea de base de AKS antes de continuar con el contenido relativo a varias regiones.

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Componentes

Muchos componentes y servicios de Azure se usan en esta arquitectura de AKS de varias regiones. A continuación, se enumeran solo esos componentes que son únicos de esta arquitectura de varios clústeres. Para conocer el resto, consulte la arquitectura de línea de base de AKS.

• Clústeres de AKS regionales: 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 entre todas las regiones. Si una región deja de estar disponible, el tráfico se enruta a la región más cercana al usuario que emitió la solicitud.
• Redes en estrella tipo "hub and spoke" regionales: se implementa un par de redes en estrella tipo "hub and spoke" por cada instancia de AKS regional. Se usan directivas de Azure Firewall Manager para administrar las directivas de firewall en todas las regiones.
• Almacén de claves regional: Azure Key Vault se aprovisiona en cada región. Los almacenes de claves se usan para almacenar valores y claves confidenciales específicos del clúster de AKS y servicios auxiliares que se encuentran en esa región.
• varias áreas de trabajo de análisis: las áreas de trabajo de Log Analytics se usan para almacenar métricas de redes regionales y registros de diagnóstico. Además, se usa una instancia compartida de Log Analytics para almacenar métricas y registros de diagnóstico de todas las instancias de AKS.
• Perfil global de Azure Front Door: Azure Front Door se usa para equilibrar la carga y enrutar el tráfico a una instancia de Azure Application Gateway regional, que se encuentra delante de cada clúster de AKS. Azure Front Door permite el enrutamiento global de capa 7, ambos necesarios para esta arquitectura.
• Registro de contenedor global: las imágenes de contenedor de la carga de trabajo se almacenan en un registro de contenedor administrado. En esta arquitectura, se usa una única instancia de Azure Container Registry con todas las instancias de Kubernetes del clúster. La replicación geográfica de Azure Container Registry permite la replicación de imágenes en las regiones de Azure seleccionadas y la provisión de acceso continuado a las imágenes incluso si una región experimenta interrupciones.

Patrones de diseño

Esta arquitectura usa dos patrones de diseño de nube:

• Nodos geográficos, donde cualquier región puede atender cualquier solicitud.
• Stamps de implementación, en las que se implementan varias copias independientes de una aplicación o componente de aplicación desde un único origen, como una plantilla de implementación.

Consideraciones sobre el patrón de nodos geográficos

Al seleccionar las regiones para implementar cada clúster de AKS, tenga en cuenta las regiones cercanas al consumidor de la carga de trabajo o a sus clientes. Además, considere la posibilidad de usar la replicación entre regiones. La replicación entre regiones replica de forma asincrónica las mismas aplicaciones y datos en otras regiones de Azure para la protección mediante la recuperación ante desastres. A medida que el clúster escale por encima de dos regiones, siga planeando la replicación entre regiones para cada par de clústeres de AKS.

Dentro de cada región, los nodos de los grupos de nodos de AKS se reparten entre varias zonas de disponibilidad para ayudar a evitar problemas debidos a errores zonales. Las zonas de disponibilidad se admiten en un conjunto limitado de regiones, lo que influye en la ubicación del clúster regional. Para más información sobre AKS y las zonas de disponibilidad, incluida una lista de regiones admitidas, consulte Zonas de disponibilidad de AKS.

Consideraciones sobre los stamps de implementación

Cuando se administra una solución de AKS de varias regiones, se implementan varios clústeres de AKS en varias regiones. Cada uno de estos clústeres se considera una stamp. En caso de un error regional o de que exista la necesidad de agregar más capacidad o presencia regional para los clústeres, es posible que tenga que crear otra instancia de stamp. Al seleccionar un proceso para crear y administrar stamps de implementación, es importante tener en cuenta lo siguiente:

• Seleccionar la tecnología adecuada para las definiciones de stamps que permita la configuración generalizada. Por ejemplo, puede usar Bicep para definir la infraestructura como código.
• Proporcione valores específicos de instancia mediante un mecanismo de entrada de implementación, como variables o archivos de parámetros.
• Seleccione herramientas de implementación que permitan una implementación flexible, repetible e idempotente.
• En una configuración de stamps activo/activo, tenga en cuenta cómo se equilibra el tráfico entre cada uno. Esta arquitectura usa Azure Front Door para el equilibrio global de carga.
• A medida que se agregan y se quitan stamps de la colección, considere los problemas de capacidad y coste.
• Considere cómo adquirir visibilidad o supervisar la colección de stamps como una sola unidad.

Cada uno de estos elementos se detalla con instrucciones específicas en las secciones siguientes.

Administración de flotas

Esta solución representa una topología de varios clústeres y varias regiones, sin la inclusión de un orquestador avanzado para tratar todos los clústeres como parte de una flota unificada. Cuando aumente el número de clústeres, considere la posibilidad de inscribir los miembros en Azure Kubernetes Fleet Manager para mejorar la administración a gran escala de los clústeres participantes. La arquitectura de la infraestructura presentada aquí no cambia fundamentalmente con la inscripción en Fleet Manager, pero las operaciones de día 2 y actividades similares se benefician de un plano de control que puede dirigirse a varios clústeres de forma simultánea.

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.

Implementación y arranque de clústeres

Al implementar varios clústeres de Kubernetes en configuraciones de alta disponibilidad y distribuidas geográficamente, es esencial considerar la suma de cada clúster de Kubernetes como una unidad acoplada. Puede que quiera desarrollar estrategias basadas en código para la implementación y la configuración automatizadas a fin de asegurarse de que cada instancia de Kubernetes sea lo más idéntica posible. Considere estrategias de escalado y reducción horizontal, incluida la adición o eliminación de otros clústeres de Kubernetes. El diseño, el plan de implementación y configuración deben tener en cuenta las interrupciones de la zona de disponibilidad, los errores regionales y otros escenarios comunes.

Definición de clúster

Tiene muchas opciones para implementar un clúster de Azure Kubernetes Service. Azure Portal, la CLI de Azure o el módulo de Azure PowerShell son todas buenas opciones para implementar clústeres de AKS individuales o no acoplados. Sin embargo, estos métodos pueden presentar desafíos al trabajar con muchos clústeres de AKS estrechamente acoplados. Por ejemplo, con Azure Portal existe la probabilidad de errores de configuración debido a pasos que faltan u opciones de configuración no disponibles. La implementación y la configuración de muchos clústeres mediante el portal es un proceso que consume tiempo y que requiere la atención de uno o varios ingenieros. Si usa la CLI de Azure o Azure PowerShell, puede construir un proceso repetible y automatizado mediante las herramientas de línea de comandos. Sin embargo, la responsabilidad de la idempotencia, el control de errores de implementación y la recuperación de errores es suya y de los scripts que crea.

Al trabajar con varias instancias de AKS, se recomienda considerar las soluciones de infraestructura como código, por ejemplo, las plantillas de Bicep, Azure Resource Manager o Terraform. Las soluciones de infraestructura como código proporcionan una solución de implementación automatizada, escalable e idempotente. Por ejemplo, puede usar un archivo de Bicep para los servicios compartidos de la solución y otro para los clústeres de AKS y otros servicios regionales. Mediante la infraestructura como código, se puede definir un stamp de implementación con configuraciones generalizadas, como redes, autorización y diagnóstico. Además, se puede proporcionar un archivo de parámetros de implementación con valores específicos de la región. Con esta configuración, se puede usar una sola plantilla para implementar un stamp casi idéntico en cualquier región.

El costo de desarrollar y mantener los recursos de infraestructura como código puede ser elevado. En algunos casos, la sobrecarga de definir la infraestructura como código puede superar las ventajas, como cuando tiene un número muy pequeño (por ejemplo, 2 o 3) y un número inmutable de instancias de AKS. En estos casos, es aceptable usar un enfoque más imperativo, como con las herramientas de línea de comandos o incluso con enfoques manuales con Azure Portal.

Implementación del clúster

Una vez definido el stamp del clúster, dispone de muchas opciones para implementar instancias individuales o varias instancias del stamp. Nuestra recomendación es usar tecnología moderna de integración continua, como Acciones de GitHub o Azure Pipelines. Estas son las ventajas de las soluciones de implementación basadas en integración continua:

• Implementaciones basadas en código que permiten agregar y quitar stamps mediante código
• Funcionalidades integradas de prueba
• Funcionalidades integradas de entorno y almacenamiento provisional
• Soluciones integradas de administración de secretos
• Integración con el control de código fuente, tanto para el código de aplicación como para las plantillas y scripts de implementación
• Historial y registro de implementaciones
• Funcionalidades de control y auditoría de acceso, para controlar quién puede realizar cambios y en qué condiciones

A medida que se agregan o quitan nuevos stamps del clúster global, la canalización de implementación debe actualizarse para mantener la coherencia. Un enfoque consiste en implementar los recursos de cada región como un paso individual dentro de un flujo de trabajo de Acciones de GitHub. Esta configuración es sencilla, ya que cada instancia del clúster está claramente definida dentro de la canalización de implementación. Esta configuración conlleva cierta sobrecarga administrativa en lo referente a agregar y quitar clústeres de la implementación.

Otra opción sería crear lógica empresarial para crear clústeres basados en una lista de ubicaciones deseadas u otras que indiquen puntos de datos. Por ejemplo, la canalización de implementación podría contener una lista de regiones deseadas; un paso dentro de la canalización podría recorrer en iteración la lista e implementar un clúster en cada región encontrada en la lista. La desventaja de esta configuración es la complejidad de la generalización de la implementación y que cada stamp del clúster no se detalla explícitamente en la canalización de implementación. La ventaja es que agregar o quitar stamps del clúster de la canalización se convierte en una actualización sencilla de la lista de regiones deseadas.

Además, quitar un stamp de clúster de la canalización de implementación no siempre retira los recursos del stamp. En función de la solución de implementación y la configuración, puede que necesite un paso adicional para retirar las instancias de AKS y otros recursos de Azure. Considere la posibilidad de usar pilas de implementación para habilitar la administración completa del ciclo de vida de los recursos de Azure, incluida la limpieza cuando ya no los necesite.

Arranque del clúster

Una vez que se ha implementado cada instancia o stamp de Kubernetes, es necesario implementar y configurar los componentes del clúster, como los controladores de entrada, las soluciones de identidad y los componentes de la carga de trabajo. También deberá considerar la posibilidad de aplicar directivas de seguridad, acceso y gobernanza en el clúster.

Igual que en la implementación, estas configuraciones pueden resultar difíciles de administrar manualmente en varias instancias de Kubernetes. En su lugar, tenga en cuenta las siguientes opciones de configuración y directiva a gran escala.

GitOps

En lugar de configurar manualmente los componentes de Kubernetes, se recomienda usar métodos automatizados para aplicar configuraciones a un clúster de Kubernetes, ya que estas configuraciones se registran en un repositorio de origen. Este proceso se conoce a menudo como GitOps, y las soluciones conocidas de GitOps para Kubernetes incluyen Flux y Argo CD. Por ejemplo, la extensión Flux para AKS habilita el arranque de los clústeres automáticamente después de implementar los clústeres.

GitOps se detalla mejor en la arquitectura de referencia de línea de base de AKS. Al usar un enfoque basado en GitOps para la configuración, se asegura de que cada instancia de Kubernetes se configure de forma similar sin esfuerzo previo. Un proceso de configuración optimizado se vuelve aún más importante a medida que crece el tamaño de la flota.

Azure Policy

A medida que se agregan varias instancias de Kubernetes, aumentan las ventajas asociadas con la gobernanza, el cumplimiento y la configuración basados en directivas. Con el uso de directivas, en concreto Azure Policy, se proporciona un método centralizado y escalable para el control del clúster. La ventaja de las directivas de AKS se detalla en la arquitectura de referencia de línea de base de AKS.

Azure Policy debe habilitarse al crear los clústeres de AKS. Las iniciativas deben asignarse en modo auditoría para obtener visibilidad de la falta de cumplimiento. También puede establecer más directivas que no forman parte de una iniciativa integrada. Esas directivas se establecen en el modo de denegación. Por ejemplo, hay una directiva para asegurarse de que solo las imágenes de contenedor aprobadas se ejecutan en el clúster. Considere la posibilidad de crear sus propias iniciativas personalizadas. Integre las directivas aplicables a la carga de trabajo en una única asignación.

El ámbito de la directiva hace referencia al destino de cada directiva e iniciativa de directiva. Puede usar Bicep para asignar directivas al grupo de recursos en el que se implementa cada clúster de AKS. A medida que crece la superficie del clúster global, se generarán muchas directivas duplicadas. También puede definir el ámbito de las directivas a una suscripción de Azure o a un grupo de administración de Azure. Este método permite aplicar un único conjunto de directivas a todos los clústeres de AKS dentro del ámbito de una suscripción o todas las suscripciones que se encuentran en un grupo de administración.

Al diseñar directivas para varios clústeres de AKS, tenga en cuenta los siguientes puntos:

• Aplique directivas que se deban aplicar globalmente a todas las instancias de AKS para un grupo de administración o a una suscripción.
• Coloque cada clúster regional en su propio grupo de recursos, lo que permite aplicar directivas específicas de la región al grupo de recursos.

Consulte Organización de recursos de Cloud Adoption Framework para obtener materiales que ayuden a establecer una estrategia de administración de directivas.

Implementación de las cargas de trabajo

Además de la configuración de las instancias de AKS, tenga en cuenta la carga de trabajo implementada en cada instancia o stamp regional. Será necesario configurar las soluciones o canalizaciones de implementación para dar cabida a cada stamp regional. A medida que se agregan más stamps al clúster global, el proceso de implementación debe ampliarse o ser lo suficientemente flexible como para dar cabida a las nuevas instancias regionales.

Al planear la implementación de las cargas de trabajo, tenga en cuenta los siguientes elementos.

• Generalice la implementación, por ejemplo, con un gráfico de Helm, para asegurarse de que se puede usar una única configuración de implementación en varios stamps del clúster.
• Use una única canalización de implementación continua configurada para implementar la carga de trabajo en todos los stamps del clúster.
• Proporcione detalles de la instancia específicos del stamp como parámetros de implementación.
• Tenga en cuenta cómo se configuran el registro de diagnóstico de aplicaciones y el seguimiento distribuido para la observabilidad en toda la aplicación.

Disponibilidad y conmutación por error

Una de las motivaciones importantes para elegir una arquitectura de Kubernetes de varias regiones es la disponibilidad del servicio. Es decir, si un servicio o componente de servicio deja de estar disponible en una región, el tráfico se debe enrutar a una región donde otra instancia de ese servicio siga estando disponible. Una arquitectura de varias regiones incluye muchos puntos de error diferentes. En esta sección, se describe cada uno de estos posibles puntos de error.

Errores de pod de aplicación

Se usa un objeto de implementación de Kubernetes para crear un conjunto de réplicas, que administra varias réplicas de un pod. Si un pod no está disponible, el tráfico se enruta entre el resto. 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 automáticamente. Se pueden usar sondeos de ejecución para comprobar el estado de la aplicación o el proceso que se ejecuta en el pod. Si el servicio no responde, el sondeo de ejecución quita el pod, lo que obligará a ReplicaSet a crear una instancia.

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

Errores de hardware del centro de datos

En ocasiones, se puede producir un error localizado. Por ejemplo, un único bastidor de servidores Azure podría dejar de recibir alimentación. Para impedir que los nodos de AKS se conviertan en un único punto de error, use zonas de disponibilidad de Azure. El uso de zonas de disponibilidad garantiza que los nodos de AKS de una zona de disponibilidad determinada estén físicamente separados de los definidos en otra.

Para más información, consulte Zonas de disponibilidad de AKS y Azure.

Errores en una región de Azure

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, Azure Front Door enruta todo el tráfico al resto de regiones en buen estado. Los clústeres y pods de Kubernetes de las regiones correctas siguen atendiendo solicitudes.

En esta situación, debe tener cuidado para compensar el aumento del tráfico o de solicitudes al resto de clústeres. Considere los siguientes puntos:

• 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 Azure CNI, asegúrese de que tiene una subred lo suficientemente grande como para admitir todas las direcciones IP del pod mientras el tráfico está en aumento.
• 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.

Para más información, consulte Horizontal Pod Autoscaler y AKS Cluster Autoscaler.

Topología de red

Al igual que sucede con la arquitectura de referencia de línea de base de AKS, esta arquitectura usa una topología de red en estrella tipo hub-and-spoke (radial). Además de las consideraciones especificadas en la arquitectura de referencia de línea de base de AKS, tenga en cuenta los siguientes procedimientos recomendados:

• Implemente un conjunto de redes virtuales en estrella tipo hub-spoke para cada instancia regional de AKS. Dentro de cada región, empareje cada radio con la red virtual del concentrador.
• Enrute todo el tráfico saliente a través de la instancia de Azure Firewall que se encuentra en cada red de centro regional. Use directivas de Azure Firewall Manager para administrar las directivas de firewall en todas las regiones.
• Siga el dimensionamiento de IP que se encuentra en la arquitectura de referencia de línea base de AKS y permita más direcciones IP para las operaciones de escalado de nodos y pods en caso de que experimente un error regional en otra región y el tráfico a las regiones restantes aumente sustancialmente.

Administración del tráfico

Con la arquitectura de referencia de línea de base de AKS, el tráfico de carga de trabajo se enruta directamente a una instancia de Azure Application Gateway para posteriormente reenviarse al equilibrador de carga back-end y a los recursos de entrada de AKS. Cuando se trabaja con varios clústeres, las solicitudes de cliente se enrutan a través de una instancia de Azure Front Door, que se enruta a la instancia de Azure Application Gateway.

Descargue un archivo de Visio de este diagrama.

1. El usuario envía una solicitud a un nombre de dominio (por ejemplo, https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), que se resuelve en el perfil de Azure Front Door. Esta solicitud se cifra con un certificado comodín (*.azurefd.net) emitido para todos los subdominios de Azure Front Door. Azure Front Door valida la solicitud con las directivas de Web Application Firewall, selecciona el origen más rápido (en función del estado y la latencia) y usa el DNS público para resolver la dirección IP de origen (instancia de Azure Application Gateway).

2. Azure Front Door reenvía la solicitud a la instancia de Application Gateway adecuada seleccionada, que actúa como punto de entrada para el stamp regional. El tráfico fluye a través de Internet. Azure Front Door garantiza que el tráfico al origen se cifre.

   Considere un método para asegurarse de que la instancia de Application Gateway solo acepte el tráfico de la instancia de Front Door. Un enfoque es usar un grupo de seguridad de red en la subred que contenga la instancia de Application Gateway. Las reglas pueden filtrar el tráfico entrante (o saliente) en función de propiedades como Source, Port o Destination. La propiedad Source permite establecer una etiqueta de servicio integrada que indica las direcciones IP de un recurso de Azure. Esta abstracción facilita la configuración y el mantenimiento de la regla y el seguimiento de las direcciones IP. Además, considere la posibilidad de usar el encabezado X-Azure-FDID, que Azure Front Door agrega a la solicitud antes de enviarla al origen, para asegurarse de que la instancia de Application Gateway solo acepta tráfico de la instancia de Front Door. Para más información sobre los encabezados de Front Door, consulte Admisión de protocolos para encabezados HTTP en Azure Front Door.

Consideraciones sobre recursos compartidos

Aunque el objetivo de este escenario es tener varias instancias de Kubernetes repartidas entre varias regiones de Azure, tiene sentido compartir algunos recursos en todas las regiones. Un enfoque consiste en usar un único archivo de Bicep para implementar todos los recursos compartidos y, a continuación, otro para implementar cada marca regional. En esta sección se detalla cada uno de estos recursos compartidos y las consideraciones para usarlos en varias instancias de AKS.

Container Registry

En esta arquitectura, se usa Azure Container Registry para proporcionar servicios de imagen de contenedor. El clúster extrae imágenes de contenedor del registro. Tenga en cuenta los siguientes elementos al trabajar con Azure Container Registry en una implementación de clúster de varias regiones.

Disponibilidad geográfica

Coloque un registro de contenedor en cada región en la que se implemente un clúster de AKS. Este enfoque permite operaciones de red de baja latencia y habilita transferencias de capa de imagen confiables y rápidas. También significa que tiene varios puntos de conexión de servicios de imágenes para proporcionar disponibilidad cuando los servicios regionales no estén disponibles. El uso de la funcionalidad de replicación geográfica de Azure Container Registry le permite administrar una instancia de Container Registry replicada automáticamente en varias regiones.

Considere la posibilidad de crear un único registro, con réplicas en cada región de Azure que contenga clústeres. Para más información sobre la replicación de Azure Container Registry, consulte Replicación geográfica en Azure Container Registry.

Imagen que muestra varias réplicas de Azure Container Registry desde Azure Portal.

Acceso al clúster

Cada clúster de AKS requiere acceso al registro de contenedor para que pueda extraer capas de imagen de contenedor. Hay varias maneras de establecer el acceso a Azure Container Registry. Esta arquitectura se crea una identidad administrada para cada clúster, al que se le concede el rol de AcrPull en el registro de contenedor. Para obtener más información y recomendaciones sobre cómo usar identidades administradas para el acceso a Azure Container Registry, consulte Arquitectura de referencia de línea de base de AKS.

Esta configuración se define en el archivo de Bicep de stamps del clúster para que cada vez que se implemente un nuevo stamp, se conceda acceso a la nueva instancia de AKS. Dado que el registro de contenedor es un recurso compartido, asegúrese de que las implementaciones incluyen el identificador de recurso del registro de contenedor como parámetro.

Azure Monitor

La característica Container Insights de Azure Monitor es la herramienta recomendada para supervisar y comprender el rendimiento y el estado de las cargas de trabajo de clústeres y contenedores. Container Insights usa un área de trabajo de Log Analytics para almacenar datos de registro y métricas de Azure Monitor para almacenar datos numéricos de series temporales. Las métricas de Prometheus también se pueden recopilar mediante Container Insights y los datos se pueden enviar al servicio administrado de Azure Monitor para Prometheus o los registros de Azure Monitor. Para más información, consulte la arquitectura de referencia de línea de base de AKS.

También puede configurar la configuración de diagnóstico del clúster de AKS para recopilar y analizar los registros de recursos de los componentes del plano de control de AKS y reenviarlos a un área de trabajo de Log Analytics.

Al diseñar una solución de supervisión para una arquitectura de varias regiones, es importante tener en cuenta el acoplamiento entre cada stamp. Puede implementar una única área de trabajo de Log Analytics, compartida por cada clúster de Kubernetes. Al igual que con los demás recursos compartidos, defina el stamp regional para consumir información sobre el área de trabajo global de Log Analytics y conecte cada clúster regional a esa única área de trabajo compartida. Cuando cada clúster regional emite registros de diagnóstico a esa única área de trabajo de Log Analytics, puede usar los datos, junto con las métricas de recursos, para crear informes y paneles más fácilmente que le ayuden a comprender cómo se ejecuta toda la solución de varias regiones.

Azure Front Door

Azure Front Door se usa para equilibrar la carga y enrutar el tráfico a cada clúster de AKS. Azure Front Door también habilita el enrutamiento global de capa 7. Estas funcionalidades son necesarias para este escenario.

Configuración de clúster

A medida que se agrega cada instancia regional de AKS, Application Gateway implementada junto con el clúster de Kubernetes debe inscribirse como origen en Azure Front Door, lo que hace que esté disponible para el enrutamiento. Esta operación requiere una actualización de los recursos de infraestructura como código. Como alternativa, esta operación se puede desacoplar de la configuración de implementación y administrarse con herramientas como la CLI de Azure.

Certificados

Azure Front Door no admite orígenes mediante certificados autofirmados, ni siquiera en entornos de desarrollo o pruebas. Para permitir el tráfico HTTPS, debe crear el certificado TLS/SSL firmado por una entidad de certificación (CA). Para información sobre otras entidades de certificación que admiten Front Door, consulte Entidades de certificación permitidas para habilitar HTTPS personalizado en Azure Front Door.

Para las pruebas o para clústeres que no son de producción, puede considerar la posibilidad de usar Certbot para crear un certificado Let's Encrypt Authority X3 para cada una de las instancias de Application Gateway.

Al planear un clúster de producción, use el método preferido de su organización para adquirir certificados TLS.

Acceso e identidad del clúster

Como se describe en la arquitectura de referencia de línea de base de AKS, se recomienda usar Microsoft Entra ID como proveedor de identidad para los clústeres. Los grupos de Microsoft Entra se pueden usar para controlar el acceso a los recursos del clúster.

Al administrar varios clústeres, deberá decidir un esquema de acceso. Las opciones son:

• Crear un grupo de acceso global a todo el clúster en el que los miembros puedan acceder a todos los objetos de todas las instancias de Kubernetes del clúster. Con esta opción, se reducen las necesidades de administración; sin embargo, se conceden privilegios importantes a cualquier miembro del grupo.
• Crear un grupo de acceso individual para cada instancia de Kubernetes que se usa para conceder acceso a los objetos de una instancia de clúster individual. Con esta opción, aumenta la sobrecarga administrativa; sin embargo, también se proporciona un acceso más pormenorizado al clúster.
• Defina controles de acceso pormenorizados para los espacios de nombres y los tipos de objetos de Kubernetes y correlacione los resultados con una estructura de grupo de Microsoft Entra. Con esta opción, la sobrecarga administrativa aumenta considerablemente; sin embargo, se proporciona un acceso pormenorizado no solo a cada clúster, sino también a los espacios de nombres y las API de Kubernetes que se encuentran en cada uno.

Para el acceso administrativo, considere la posibilidad de crear un grupo de Microsoft Entra para cada región. Conceda a cada grupo acceso total a la marca de clúster correspondiente en esa región. Los miembros de cada grupo tendrán acceso administrativo a los clústeres correspondientes.

Para obtener más información sobre cómo administrar el acceso al clúster de AKS con Microsoft Entra ID, consulte Integración de Microsoft Entra y AKS.

Datos, estado y caché

Al usar un conjunto distribuido globalmente de clústeres de AKS, tenga en cuenta la arquitectura de la aplicación, el proceso u otras cargas de trabajo que podrían ejecutarse en el clúster. Si las cargas de trabajo basadas en estado se reparten entre los clústeres, ¿será necesario acceder a un almacén de estado? Si, debido a un error, se vuelve a crear un proceso en otra parte del clúster, ¿la carga de trabajo o el proceso seguirán teniendo acceso a un almacén de estado dependiente o a una solución de almacenamiento en caché? El estado se puede almacenar de muchas maneras, pero es complejo administrar incluso en un único clúster de Kubernetes. La complejidad aumenta al agregar varios clústeres de Kubernetes. Debido a los problemas de acceso regional y de complejidad, considere la posibilidad de diseñar las aplicaciones para usar un servicio de almacén de estado distribuido globalmente.

El diseño de esta arquitectura no incluye la configuración para problemas de estado. Si ejecuta una única aplicación lógica entre varios clústeres de AKS, considere la posibilidad de diseñar la carga de trabajo para usar un servicio de datos distribuido globalmente, como Azure Cosmos DB. Azure Cosmos DB es un sistema de base de datos distribuido globalmente que permite leer y escribir datos de las réplicas locales de la base de datos, y el servicio Cosmos DB administra la replicación geográfica automáticamente. Para más información, consulte Azure Cosmos DB.

Si la carga de trabajo utiliza una solución de almacenamiento en caché, asegúrese de diseñar los servicios de almacenamiento en caché para que sigan funcionando incluso durante los eventos de conmutación por error. Compruebe que la propia carga de trabajo sea resistente a la conmutación por error relacionada con la caché y de que las soluciones de almacenamiento en caché existan en todas las instancias regionales de AKS.

Optimización de costos

Use lacalculadora de precios de Azure para estimar los costos de los servicios usados en la arquitectura. Otros procedimientos recomendados se describen en la sección Optimización de costes de Marco de buena arquitectura de Microsoft Azure, y las opciones específicas de configuración de la optimización de costes en el artículo Optimización de costes.

Considere la posibilidad de habilitar el análisis de costes de AKS para la asignación de costos de infraestructura de clúster pormenorizadas mediante construcciones específicas de Kubernetes.

Pasos siguientes

• Zonas de disponibilidad de AKS
• Azure Kubernetes Fleet Manager
• Replicación geográfica en Azure Container Registry
• Regiones emparejadas de Azure

Recursos relacionados

• Revisión del Marco de buena arquitectura de Azure para Azure Kubernetes Service (AKS)
• Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)
• Canalización de CI/CD para cargas de trabajo basadas en contenedores
• Integración de Microsoft Entra y AKS
• Documentación de Azure Front Door
• Documentación sobre Azure Cosmos DB