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

Azure Kubernetes Service (AKS)

Azure Front Door

Azure Application Gateway

Azure Container Registry

Azure Firewall

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. Aquí solo se enumeran los componentes ú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 de AKS , cada uno de ellos en una región de Azure independiente. 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 una región restante más cercana al usuario que emitió la solicitud.
Redes regionales en estrella tipo hub-spoke: Se implementa una red virtual en estrella tipo hub-spoke regional para cada instancia regional de AKS. directivas de de Azure Firewall Manager se usan para administrar directivas de firewall en todas las regiones.
almacén de claves regional: de 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 registro: se usan áreas de trabajo de log Analytics regional para almacenar métricas de red 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.
Flota de AKS: Se implementa Un Administrador de flotas de Azure Kubernetes para coordinar las actualizaciones de la versión del clúster de Kubernetes y las actualizaciones de la versión de la imagen de nodo en cada uno de los clústeres de AKS regionales.
Clúster de centro de flotas (administrado por Microsoft):opcionalmente, se puede implementar un único clúster del centro de Azure Kubernetes Fleet Manager para admitir características específicas de flotas, como la propagación de cargas de trabajo. El clúster de concentrador es un recurso de Azure de ámbito regional que ayuda a administrar la propagación de cargas de trabajo y el equilibrio de carga entre varios clústeres de miembros. Es mejor implementar el clúster de concentrador como un clúster de concentrador privado, que debe ser accesible desde clústeres miembro para admitir señales de latido y realizar procesos de conciliación de configuración.
perfil global de Azure Front Door: de Azure Front Door se usa para equilibrar la carga y enrutar 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 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 para azure Container Registry permite replicar imágenes en las regiones de Azure seleccionadas y proporcionar acceso continuado a imágenes incluso si una región está experimentando una interrupción.

Alternativas

Esta solución usa Fleet Manager de Azure Kubernetes. Las flotas permiten una serie de funcionalidades para administrar varios clústeres, con un enfoque en la optimización de las operaciones del día 2 al proporcionar un plano de control que pueda organizar actividades en varios clústeres. Las ventajas de Fleet Manager aumentan a medida que crece el número de clústeres de su flota.

En esta solución, la flota organiza las actualizaciones de la versión de Kubernetes en varios clústeres, así como las actualizaciones de la versión de la imagen de nodo. Estas funcionalidades no requieren que se implemente un clúster de concentrador. Puede optar por hacer que cada clúster realice actualizaciones de la versión y de la imagen de nodo de Kubernetes de forma independiente, lo que no requiere una flota. Sin embargo, si lo hace, es probable que los clústeres obtengan actualizaciones de versiones en momentos diferentes y pueden resultar difíciles de validar la carga de trabajo y la configuración con varias versiones en el entorno de producción simultáneamente.

También puede usar una flota para la coordinación de la implementación de cargas de trabajo, lo que requiere que agregue un clúster de concentrador. Las implementaciones de cargas de trabajo se describen con más detalle más adelante en este artículo.

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.

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.

Después de la creación de un clúster, debe inscribirse en la flota como un clúster miembro. Este paso se puede completar mediante la implementación de un recurso de Resource Manager de tipo Microsoft.ContainerService/fleets/members, que hace referencia al identificador de recurso del clúster miembro. Después de inscribir el clúster miembro en la flota, se puede agregar a las ejecuciones de actualización y usar otras funcionalidades de flota que configure.

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. Es posible que tenga que crear espacios de nombres de Kubernetes y también debe considerar la posibilidad de aplicar directivas de seguridad, acceso y gobernanza en el clúster. Estas operaciones se conocen como arranque del clúster para preparar las cargas de trabajo que se implementarán en él.

De forma similar a la implementación, las configuraciones de arranque pueden resultar difíciles de administrar manualmente en varias instancias de Kubernetes. Si usa un clúster de concentrador con Azure Kubernetes Fleet Manager, puede implementar parte de la configuración de arranque en toda la flota, como los espacios de nombres. Sin embargo, otros componentes de arranque requieren un enfoque de implementación diferente.

Debe tener en cuenta una de las siguientes opciones para aplicar la configuración de arranque y la directiva a escala.

GitOps

En lugar de configurar manualmente los componentes de Kubernetes en cada clúster, se recomienda usar métodos automatizados para aplicar configuraciones a un clúster de Kubernetes, ya que estas configuraciones se comprueban 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.

Puede usar un enfoque de GitOps para implementar la configuración del clúster base. Puede inscribir el clúster en la flota para participar en actividades de toda la flota, como lanzamientos de actualizaciones automatizadas.

También puede usar GitOps opcionalmente para implementar las cargas de trabajo. Para más información, consulte la sección implementación de cargas de trabajo a continuación.

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.

Inscripción de flota

Después de implementar y configurar un clúster, inscriba en la flota como un clúster miembro. Cada clúster miembro se puede asignar a un grupo de actualizaciones, que se puede usar como parte de una estrategia de actualización para determinar dónde se ejecuta la actualización del clúster. Para más información sobre las estrategias de inscripción, grupos y actualización de clústeres, consulte Definición de estrategias de actualización reutilizables mediante Azure Kubernetes Fleet Manager.

Implementación de las cargas de trabajo

Cada clúster de AKS de la arquitectura ejecuta aplicaciones que admiten la carga de trabajo. Es importante planear cómo implementará y actualizará los componentes de carga de trabajo de forma segura y controlada, y cómo mantendrá la coherencia de las versiones de aplicación entre cada clúster. Por lo tanto, además de la configuración de la instancia de AKS, tenga en cuenta las cargas de trabajo que se implementan en cada instancia regional o marca. Las soluciones o canalizaciones de implementación requieren configuración para dar cabida a cada sello 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.

Hay varios enfoques de implementación que puede tener en cuenta, entre los que se incluyen:

Tuberías: En escenarios con un pequeño número de clústeres y relativamente pocas implementaciones sencillas, a menudo es mejor usar canalizaciones de entrega continua (CD) dedicadas ligeras.

Normalmente, una sola canalización implementa una carga de trabajo en uno o varios clústeres. Este enfoque minimiza la sobrecarga operativa y sigue siendo manejable en entornos a bajo escala. Al pasar de un solo clúster a un modelo de pocos clústeres, puede evolucionar las canalizaciones de implementación que ya tiene en vigor.
Propagación de cargas de trabajo de Fleet Manager de Azure Kubernetes: La propagación de cargas de trabajo de flota simplifica la tarea de orquestar definiciones de carga de trabajo entre varios clústeres miembro desde un plano de control centralizado. Las flotas admiten un enfoque confiable y escalable para las implementaciones de cargas de trabajo, lo que permite un gran número de cargas de trabajo y clústeres miembros.

La propagación de cargas de trabajo requiere el uso de un clúster de concentrador, que es un clúster de AKS administrado por Microsoft que ayuda a realizar un seguimiento del estado esperado de los clústeres miembros. Este clúster de concentrador es un recurso regional. Si una interrupción regional afecta al clúster de concentrador, la propagación de cargas de trabajo podría experimentar una interrupción temporal.
GitOps: A medida que la infraestructura madura aún más, la adopción de una estrategia basada en GitOps se vuelve cada vez más beneficiosa. GitOps permite mecanismos de implementación declarativos, auditables y basados en extracción, que ofrecen escalabilidad, gobernanza y colaboración en equipo. La transición a este modelo se recomienda especialmente al administrar una gran flota dinámica de clústeres en varias regiones.

Para más información, consulte GitOps para Azure Kubernetes Service.

Para decidir qué enfoque tiene sentido para la solución, tenga en cuenta estas preguntas:

¿Espera que el número de clústeres permanezca fijo o aumente con el tiempo? Si tiene previsto expandir el número de clústeres, o si planea ajustar el número de clústeres dinámicamente, puede volverse rápidamente inconfundible para mantener la configuración de cada clúster en las canalizaciones de implementación.
¿Cuántas unidades implementables tiene que administrar? Si tiene un pequeño número de aplicaciones monolíticas, solo tiene un pequeño número de implementaciones individuales para coordinar. Sin embargo, si tiene una arquitectura distribuida basada en microservicios, un gran número de cargas de trabajo o ambas. después, esto puede crecer rápidamente en cientos de unidades implementables. La creación de una canalización para cada implementación podría resultar inviable.
¿Qué tipo de estrategias de implementación necesita? Entre las estrategias comunes se incluyen las actualizaciones graduales, las implementaciones azul-verde y las implementaciones controladas. Algunos enfoques de implementación deben permitir el "tiempo de elaboración" entre lanzamientos, con una supervisión cercana para comprobar las regresiones introducidas por la implementación. Evalúe cada enfoque de implementación para determinar si admite sus requisitos específicos.
¿En qué restricciones de seguridad de red funcionan los clústeres? Fleet Manager de Azure Kubernetes funciona en una topología de clúster en estrella tipo hub-and-spoke, donde los clústeres miembros mantienen conexiones salientes a un clúster central para la conciliación de cargas de trabajo y la supervisión de latidos. Una estrategia basada en GitOps requiere que los clústeres participantes establezcan el acceso saliente a un repositorio de Git. Cuando se usan canalizaciones, el agente de canalización normalmente requiere conectividad a cada clúster para realizar operaciones de implementación.

Independientemente de cómo organizará las implementaciones, tiene como objetivo generalizar cada implementación, como con un gráfico de Helm, para asegurarse de que se puede usar una única configuración de implementación en varios clústeres (stamps). Además, tenga en cuenta cómo se puede configurar el registro de diagnóstico de aplicaciones y el seguimiento distribuido para la observabilidad en toda la aplicación en cada uno de los clústeres.

Fiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, vea Lista de comprobación de revisión de diseño para lade confiabilidad.

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.

Diagrama de arquitectura que muestra el tráfico de la carga de trabajo en la implementación de varias regiones.

Descargue un archivo de Visio de este diagrama.

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).
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.

Registro de contenedores

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.

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

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 (portal de entrada de Azure)

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.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación de revisión de diseño para security.

Control de acceso 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.

Seguridad de los recursos de la flota

Cuando se usa una flota para centralizar aspectos de la administración de clústeres, es importante proteger los recursos de la flota para evitar el uso indebido. Los recursos de flota usan el control de acceso basado en rol de Azure y puede conceder permisos de flota a un conjunto restringido de administradores. Siga el principio de privilegios mínimos y conceda el menor acceso posible al recurso de flota (el plano de control de la flota).

Si la flota usa un clúster de concentrador, tenga en cuenta las siguientes recomendaciones adicionales:

Evalúe las asignaciones de roles que cree en el clúster de concentrador (las asignaciones de roles del plano de datos ). Estas asignaciones de roles conceden acceso a los recursos de Kubernetes que crea la flota. Asigne el ámbito de las asignaciones de roles a un espacio de nombres de Kubernetes individual siempre que sea posible.
Use un clúster de concentrador privado para restringir la conectividad a Internet. Sin embargo, asegúrese de que la arquitectura de red permite que los clústeres miembro lleguen al clúster del concentrador.

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.

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 obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Cuando se opera un entorno de varios clústeres con un recurso de flota, la supervisión se vuelve más difícil. De forma similar, tenga en cuenta cómo coordinará las actualizaciones de los componentes del clúster de AKS.

Supervisión de clústeres y cargas de trabajo

La revisión manual de paneles y registros puede resultar difícil a medida que aumenta el número de clústeres, por lo que debe tener en cuenta cómo agregará sistemáticamente los registros y las métricas.

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.

Para más información sobre cómo configurar áreas de trabajo de Azure Monitor en un entorno de varios clústeres, consulte Azure Monitor.

Supervisión de las operaciones de la flota

Cuando Fleet Manager organiza una ejecución de actualización, puede supervisar el progreso de la ejecución a medida que avanza entre clústeres. Los datos se almacenan en Azure Resource Graph y se pueden exportar a Azure Monitor para alertas y almacenamiento.

Si decide usar Fleet Manager para la propagación de cargas de trabajo, puede supervisar el lanzamiento mediante Azure Portal o kubectl.

También puede recopilar registros de recursos del recurso de flota y reenviarlos a un área de trabajo de Log Analytics.

Aplicación de actualizaciones en toda la flota

En esta arquitectura de referencia, Fleet Manager aplica actualizaciones de versiones de Kubernetes y actualizaciones de imágenes de nodo en toda la flota. Puede especificar estrategias de actualización que configuren cómo se implementan las actualizaciones en los clústeres. Además, Fleet Manager respeta las ventanas de mantenimiento de cada clúster, por lo que es recomendable establecer las ventanas de mantenimiento adecuadas para cada clúster. Las ventanas de mantenimiento de cada clúster pueden ser diferentes cuando se usan clústeres en varias zonas geográficas y, por tanto, en diferentes zonas horarias.

Para más información, consulte Actualización de imágenes de nodo y Kubernetes en varios clústeres de miembros.

Optimización de costos

La optimización de costos consiste en examinar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la 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.