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 de referencia 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.

Architecture

Architecture diagram showing multi-region deployment.

Descargue un archivo Visio de esta arquitectura.

GitHub logoHay disponible una implementación de referencia de esta arquitectura en GitHub.

Componentes

Muchos componentes y servicios de Azure se usan en la arquitectura de referencia 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.

  • Varios clústeres o varias regiones 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.
  • Red en estrella tipo "hub and spoke" por región Se implementa un par de redes en estrella tipo "hub and spoke" por cada instancia de AKS regional. 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 para almacenar valores confidenciales y claves específicas de la instancia de AKS, así como servicios complementarios que se encuentran en esa región.
  • Azure Front Door Este servicio 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 siete, ambos necesarios para esta arquitectura de referencia.
  • Log Analytics Las instancias regionales 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.
  • Registro de contenedor 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 de referencia usa dos modelos de diseño de nube. Nodo geográfico, donde cualquier región puede atender cualquier solicitud y stamps de implementación, donde se implementan varias copias independientes de una aplicación o componente de aplicación desde un único origen (plantilla de implementación).

Consideraciones sobre el modelo de nodo geográfico

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

Al administrar un clúster de AKS de varias regiones, se implementan varias instancias de AKS en varias regiones. Cada una de estas instancias se considera un stamp. En caso de un error regional o de que exista la necesidad de agregar más capacidad o presencia regional para el clúster, 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, como la infraestructura como código
  • Proporcionar valores específicos de instancia mediante un mecanismo de entrada de implementación, como variables o archivos de parámetros.
  • Seleccionar 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.
  • A medida que se agregan y se quitan stamps de la colección, considere los problemas de capacidad y costo.
  • Considerar 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 de esta arquitectura de referencia.

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. Le interesará considerar estrategias de escalado y reducción horizontal mediante la adición o eliminación de otras instancias de Kubernetes. Le interesará el diseño y el plan de implementación y configuración, para tener en cuenta los errores regionales u 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. Además, la implementación y la configuración de muchos clústeres mediante el portal es un proceso puntual que requiere la atención de uno o varios ingenieros. Puede construir un proceso automatizado que se repita 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 muchas instancias de AKS, se recomienda considerar las soluciones de infraestructura como código, por ejemplo, las plantillas de Azure Resource Manager, las plantillas de Bicep o las configuraciones de Terraform. Las soluciones de infraestructura como código proporcionan una solución de implementación automatizada, escalable e idempotente. Esta arquitectura de referencia incluye una plantilla de ARM para los servicios compartidos de soluciones y otra para los clústeres de AKS y los 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, como cuando se implementa un número estático o fijo de instancias de AKS, la sobrecarga de la infraestructura como código puede superar las ventajas. En estos casos, es más adecuado el uso de un enfoque más imperativo, por ejemplo, con herramientas de línea de comandos o incluso un enfoque manual.

Implementación del clúster

Una vez establecida la definición del 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 del código o del origen de implementación
  • Historial y registro de implementaciones

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. En la implementación de referencia, cada región se implementa como un paso individual dentro de un flujo de trabajo de acciones de GitHub (ejemplo). 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 utilizar la lógica 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 del clúster de la canalización de implementación no garantiza necesariamente que también se retire. En función de la solución de implementación y la configuración, puede que necesite un paso adicional para garantizar que las instancias de AKS se han retirado correctamente.

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, considere la posibilidad de 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. Esta implementación usa la extensión Flux para AKS para habilitar el arranque de los clústeres automáticamente y después de implementar los clústeres.

GitOps se detalla mejor en la arquitectura de referencia de línea de base de AKS. Lo importante a destacar aquí es que el uso de un enfoque basado en GitOps para la configuración ayuda a garantizar que cada instancia de Kubernetes se configure de forma similar sin esfuerzo previo. Esto se vuelve aún más importante a medida que crece el tamaño de su 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, Azure Policy en este caso, 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.

En esta implementación de referencia, Azure Policy se habilita al crear los clústeres de AKS y se asigna la iniciativa restrictiva en modo de auditoría para obtener visibilidad sobre los casos de incumplimiento. La implementación también establece 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. La implementación de referencia asociada a esta arquitectura usa una plantilla de ARM 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:

  • Las directivas que se deben aplicar globalmente a todas las instancias de AKS se pueden aplicar a un grupo de administración o a una suscripción.
  • La colocación de cada clúster regional en su propio grupo de recursos 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 ese servicio esté 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.

Pods de aplicación (regional)

Se usa un objeto de implementación de Kubernetes para crear varias réplicas de un pod (ReplicaSet). Si una 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. Por último, 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 quitará el pod, lo que obligará a ReplicaSet a crear una instancia.

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

Pods de aplicación (global)

Cuando toda una región deja de estar disponible, los pods del clúster ya no están disponibles para atender solicitudes. En este caso, la instancia de Azure Front Door enruta todo el tráfico al resto de regiones en buen estado. Los clústeres y pods de Kubernetes de estas regiones seguirán atendiendo solicitudes.

En esta situación, debe tener cuidado para compensar el aumento del tráfico o de solicitudes al resto de clústeres. Algunos aspectos que se deben tener en cuenta son:

  • 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 tener una subred que pueda admitir todas las direcciones IP del pod con una carga de tráfico máxima.
  • Use Horizontal Pod Autoscaler para aumentar el número de réplicas de pod a fin de compensar el aumento de la demanda regional.
  • Use AKS Cluster Autoscaler 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.

Grupos de nodos de Kubernetes (regional)

En ocasiones, se puede producir un error localizado en los recursos de proceso, por ejemplo, si un único bastidor de servidores de Azure deja de recibir suministro eléctrico. Para impedir que los nodos de AKS se conviertan en un único punto de error regional, 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.

Grupos de nodos de Kubernetes (global)

En caso de un error regional completo, Azure Front Door enrutará el tráfico al resto de regiones en buen estado. De nuevo, en esta situación, debe tener cuidado para compensar el aumento del tráfico o de solicitudes al resto de clústeres.

Para más información, consulte Azure Front Door.

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 una topología de red en estrella tipo hub-and-spoke para cada instancia de AKS regional, donde las redes virtuales de centro y radio estén emparejadas.
  • 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 de base de AKS y permita direcciones IP adicionales para las operaciones de escalado de nodos y pods en caso de error regional.

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

Architecture diagram showing workload traffic in multi-region deployment.

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.azurefd.net), que se resuelve en la instancia de Azure Front Door. Esta solicitud se cifra con un certificado comodín (*.azurefd.net) emitido para todos los subdominios de Azure Front Door. La instancia de Azure Front Door valida la solicitud con las directivas de WAF, selecciona el back-end 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 back-end (instancia de Azure Application Gateway).

  2. 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 y se cifra mediante Azure Front Door. 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 de Front Door a back-end para asegurarse de que la instancia de Application Gateway solo acepta el 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 esta arquitectura de referencia es tener varias instancias de Kubernetes repartidas entre varias regiones de Azure, tiene sentido tener algunos recursos compartidos en todas las instancias. En la implementación de referencia de varias regiones de AKS se usa una sola plantilla de ARM para implementar todos los recursos compartidos y, luego, otra para implementar cada stamp 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 de referencia, se usa Azure Container Registry para proporcionar servicios de imagen de contenedor (extracción). 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

El posicionamiento de un registro de contenedor en cada región en la que se implementa un clúster de AKS permite operaciones de cierre de red, lo que hace posible transferencias rápidas y confiables de la capa de imagen. Tenga múltiples 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 en varias regiones.

En la implementación de referencia de varias regiones de AKS se creó una única instancia de Container Registry y réplicas de esta instancia en cada región del clúster. 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 ACR desde Azure Portal.

Image showing multiple ACR replicas from within the Azure portal.

Acceso al clúster

Cada instancia de AKS necesita acceso para extraer capas de imagen de Azure Container Registry. Hay varias maneras de establecer el acceso a Azure Container Registry; en esta arquitectura de referencia se usa una identidad administrada de Azure para cada clúster, a la que se le concede el rol AcrPull en la instancia de Container Registry. Puede encontrar más información y recomendaciones sobre el uso de identidades administradas para el acceso a Container Registry en la arquitectura de referencia de línea de base de AKS.

Esta configuración se define en la plantilla de ARM 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 Container Registry es un recurso compartido, asegúrese de que la plantilla del stamp de implementación pueda consumir y usar los datos necesarios, en este caso, el identificador de recurso de Container Registry.

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 enviar los datos al servicio administrado de Azure Monitor para Prometheus o los registros de Azure Monitor.

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, consulte la arquitectura de referencia de línea de base de AKS.

Al considerar la supervisión de una implementación entre regiones, como esta arquitectura de referencia, es importante tener en cuenta el acoplamiento entre cada stamp. En este caso, considere cada stamp un componente de una sola unidad (clúster regional). En la implementación de referencia de AKS de varias regiones se utiliza un área de trabajo de Log Analytics única, 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 única de Log Analytics y conectar a ella cada clúster.

Ahora que cada clúster regional omite los registros de diagnóstico de una solo área de trabajo de Log Analytics, estos datos, junto con las métricas de recursos, se pueden usar para crear más fácilmente informes y paneles que representen la totalidad del clúster global.

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 permite el enrutamiento global de capa siete, ambos necesarios para esta arquitectura de referencia.

Configuración del clúster

A medida que se agregan instancias regionales de AKS, la instancia de Application Gateway implementada junto con el clúster de Kubernetes debe inscribirse como back-end de Front Door para el enrutamiento adecuado. 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. La canalización de implementaciones de referencia incluida utiliza un paso de la CLI de Azure distinto para esta operación.

Certificados

Front Door no admite certificados autofirmados incluso en entornos de desarrollo/pruebas. Para permitir el tráfico HTTPS, debe crear el certificado TLS/SSL firmado por una entidad de certificación (CA). La implementación de referencia usa Certbot para crear un certificado Let's Encrypt Authority X3. Al planear un clúster de producción, use el método preferido de su organización para adquirir certificados TLS.

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.

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 y acceso de 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 directorios de Azure. 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.

Con la implementación de referencia incluida, se crean dos grupos de Microsoft Entra para el acceso de administrador. Estos grupos se especifican en el momento de la implementación del stamp del clúster mediante el archivo de parámetros de implementación. Los miembros de cada grupo tienen acceso total al stamp del clúster correspondiente.

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 clúster distribuido globalmente de instancias 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. A medida que la carga de trabajo basada en estado se reparte por el clúster, ¿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 lograr de muchas maneras; sin embargo, puede ser complejo en un único clúster de Kubernetes. La complejidad aumenta al agregar varias instancias de Kubernetes agrupadas. 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.

La implementación de referencia de varios clústeres no incluye una demostración o una configuración para problemas de estado. Si ejecuta aplicaciones en instancias de AKS agrupadas, 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. 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 que esté diseñada para que los servicios de almacenamiento en caché sigan funcionando. Para ello, 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 costos de AKS para la asignación de costos de infraestructura de clúster pormenorizadas mediante construcciones específicas de Kubernetes.

Pasos siguientes