Arquitectura de microservicios avanzada de Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Virtual Network

Esta arquitectura de referencia detalla varias configuraciones que se deben tener en cuenta al ejecutar microservicios en Azure Kubernetes Services. Entre los temas se incluyen la configuración de directivas de red, el escalado automático de pods y el seguimiento distribuido en una aplicación basada en microservicios.

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 Azure Kubernetes Service (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 sobre los microservicios.

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

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Si prefiere empezar con un ejemplo de microservicios más básico en AKS, consulte Arquitectura de microservicios en AKS.

Flujo de trabajo

Este flujo de solicitud implementa los patrones de diseño de nube publicador y suscriptor, consumidores de la competenciay Gateway Routing. El flujo de mensajería avanza de la siguiente manera:

1. Se envía una solicitud HTTPS para programar la recogida con un dron. Las solicitudes pasan por Azure Application Gateway hasta la aplicación web de ingesta, que se ejecuta como microservicio en clúster en AKS.

2. La aplicación web de ingesta genera un mensaje y lo envía a la cola de mensajes de Service Bus.

3. El sistema back-end asigna un dron y notifica al usuario. El flujo de trabajo:

   • Consume información de mensajes de la cola de mensajes de Service Bus.
   • Envía una solicitud HTTPS al microservicio Entrega, que pasa datos al almacenamiento de datos externo de Azure Cache for Redis.
   • Envía una solicitud HTTPS al microservicio Programador de drones.
   • Envía una solicitud HTTPS al microservicio Empaquetado, que pasa datos al almacenamiento de datos externo de MongoDB.

4. Se usa una solicitud HTTPS GET para devolver el estado de entrega. Esta solicitud pasa por Application Gateway hasta el microservicio Entrega.

5. El microservicio Entrega lee datos de Azure Cache for Redis.

Componentes

Esta arquitectura utiliza los siguientes componentes de Azure:

Azure Kubernetes Service es una oferta de Azure que brinda un clúster de Kubernetes administrado. Al usar AKS, Azure administra el servidor de API de Kubernetes. Es posible acceder a los nodos o grupos de nodos de Kubernetes, y el operador del clúster puede administrarlos.

Entre las características de infraestructura de AKS que se usan en esta arquitectura se incluyen:

• Separación del grupo de nodos del sistema y del usuario
• Identificador de Microsoft Entra ID administrado por AKS para el control de acceso basado en rol (RBAC)
• Microsoft Entra Workload ID
• Complemento de Azure Policy para AKS
• Interfaz de red de contenedor de Azure (CNI)
• Conclusiones de contenedor de Azure Monitor

Las redes virtuales de Azure son entornos aislados y altamente seguros para ejecutar máquinas virtuales y aplicaciones. Esta arquitectura de referencia usa una topología de red en estrella tipo hub-and-spoke emparejada. La red virtual del centro contiene la instancia de Azure Firewall y subredes de Azure Bastion. La red virtual de radio contiene las subredes del grupo de nodos del sistema y de usuario de AKS, y la subred de Azure Application Gateway.

Azure Private Link asigna direcciones IP privadas específicas para acceder Azure Container Registry y Key Vault desde puntos de conexión privados dentro de la subred del grupo de nodos del sistema y de usuario de AKS.

Azure Application Gateway con firewall de aplicaciones web (WAF) expone rutas HTTP(S) al clúster de AKS y equilibra la carga del tráfico web a la aplicación web. Esta arquitectura usa el controlador de entrada de Azure Application Gateway (AGIC) como controlador de entrada de Kubernetes.

Azure Bastion proporciona acceso seguro de Protocolo de escritorio remoto (RDP) y de Secure Shell (SSH) a las VM de las redes virtuales mediante una capa de sockets seguros (SSL), sin necesidad de exponer las VM a través de direcciones IP públicas.

Azure Firewall es un servicio de seguridad de red que protege todos los recursos de Azure Virtual Network. El firewall solo permite servicios aprobados y nombres de dominio completos (FQDN) como tráfico de salida.

Almacenamiento externo y otros componentes:

Azure Key Vault almacena y administra las claves de seguridad de los servicios de AKS.

Azure Container Registry almacena imágenes de contenedor privadas que se pueden ejecutar en el clúster de AKS. AKS se autentica en Container Registry con su identidad administrada de Microsoft Entra. También puede usar otros registros de contenedor, como Docker Hub.

Azure Cosmos DB almacena datos mediante Azure Cosmos DB for MongoDB de código abierto. Los microservicios son normalmente sin estado y escriben el estado en almacenes de datos externos. Azure Cosmos DB es una base de datos NoSQL con API de código abierto para MongoDB y Cassandra.

Azure Service Bus ofrece mensajería como servicio e integración híbrida sencilla en la nube. Service Bus admite patrones de mensajería asincrónica que son comunes en las aplicaciones de microservicios.

Azure Cache for Redis agrega una capa de almacenamiento en caché a la arquitectura de la aplicación para mejorar la velocidad y el rendimiento de las cargas de tráfico intensas.

Azure Monitor recopila y almacena métricas y registros, incluida la telemetría de las aplicaciones y las métricas de la plataforma y de servicios de Azure. Puede usar estos datos para supervisar la aplicación, configurar alertas y paneles, y realizar el análisis de causa principal de los errores.

Otros componentes del sistema de soporte de operaciones (OSS):

Helm , administrador de paquetes para Kubernetes, que agrupa objetos de Kubernetes en una sola unidad que se puede publicar, implementar, versionar y actualizar.

proveedor CSI del Almacén secreto de Azure Key Vault obtiene secretos almacenados en Azure Key Vault y usa la interfaz de del controlador CSI del almacén secreto de para montarlos en pods de Kubernetes.

Flux , solución de entrega continua abierta y extensible para Kubernetes, con tecnología del kit de herramientas de GitOps.

Detalles del escenario

En el ejemplo de aplicación de entrega con drones de Fabrikam que se muestra en el diagrama anterior se implementan los componentes y las prácticas de arquitectura que se tratan en este artículo. En este ejemplo, Fabrikam, Inc., una empresa ficticia, administra una flota de drones. Las empresas se registran en el servicio y los usuarios pueden solicitar que un dron recoja los bienes para la entrega. Cuando un cliente programa una recogida, un sistema back-end asigna un dron y notifica al usuario con una hora de entrega estimada. Mientras la entrega está en curso, el cliente puede hacer un seguimiento del dron, con una fecha estimada que se actualiza constantemente.

Posibles casos de uso

Esta solución es perfecta para los sectores de aeronaves, aeroespaciales y de aeronaves.

Recomendaciones

Implemente estas recomendaciones al implementar arquitecturas avanzadas de microservicios de AKS.

Controlador de entrada de Application Gateway (AGIC)

La API Gateway Routing es un patrón de diseño de microservicios general. Una puerta de enlace de API actúa como proxy inverso que enruta las solicitudes de los clientes a los microservicios. El recurso de entrada y el controlador de entrada de Kubernetes controlan la mayor parte de la funcionalidad de la puerta de enlace de API mediante:

El enrutamiento de solicitudes de cliente a los servicios back-end correctos proporciona un único punto de conexión para los clientes y ayuda a desacoplar los clientes de los servicios.

• Agregue varias solicitudes en una sola solicitud, para reducir el intercambio de mensajes entre el cliente y el back-end.
• Descargue funcionalidades, como la terminación SSL, la autenticación, las restricciones de IP o la limitación de velocidad del cliente, de los servicios de back-end.

El estado del clúster de AKS se traduce a una configuración específica de Application Gateway y se aplica a través de Azure Resource Manager.

Los controladores de entrada externos simplifican la ingesta de tráfico en clústeres de AKS, mejoran la seguridad y el rendimiento, y ahorran recursos. Esta arquitectura usa el controlador de entrada de Azure Application Gateway (AGIC) para el control de entrada. El uso de Application Gateway para controlar todo el tráfico elimina la necesidad de un equilibrador de carga adicional. Dado que los pods establecen conexiones directas con Application Gateway, se reduce el número de saltos necesarios, con lo que se logra un mejor rendimiento.

Application Gateway tiene integradas funcionalidades de escalado automático, a diferencia de los controladores de entrada en clústeres, que se deben escalar horizontalmente si consumen una cantidad excesiva de recursos de proceso. Application Gateway puede realizar enrutamiento de nivel 7 y terminación SSL, y tiene Seguridad de la capa de transporte (TLS) de un extremo a otro integrada en un firewall de aplicaciones web (WAF) integrado.

Para la opción de entrada AGIC, tiene que habilitar las redes de CNI al configurar el clúster de AKS, ya que Application Gateway se implementa en una subred de la red virtual de AKS. Las cargas de trabajo multiinquilino, o un único clúster que admita entornos de desarrollo y pruebas, podrían requerir más controladores de entrada.

Directivas de red de confianza cero

Las directivas de red especifican cómo se permite que los pods de AKS se comuniquen entre sí y con otros puntos de conexión de red. De manera predeterminada, todo el tráfico de entrada y salida se permite hacia los pods y desde estos. Al diseñar cómo se comunican los microservicios entre sí y con otros puntos de conexión, considere la posibilidad de seguir un principio de confianza cero, donde el acceso a cualquier servicio, dispositivo, aplicación o repositorio de datos requiere una configuración explícita.

Una estrategia para implementar una directiva de confianza cero es crear una directiva de red que deniegue todo el tráfico de entrada y de salida a todos los pods dentro del espacio de nombres de destino. En el ejemplo siguiente se muestra una "directiva de denegar todo" que se aplicaría a todos los pods ubicados en el espacio de nombres backend-dev.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Una vez que se haya puesto en práctica una directiva restrictiva, comience a definir reglas de red específicas para permitir el tráfico de entrada y de salida de cada pod en el microservicio. En el ejemplo siguiente, la directiva de red se aplica a cualquier pod del espacio de nombres backend-dev con una etiqueta que coincida con app.kubernetes.io/component: backend. La política deniega cualquier tráfico a menos que provenga de un pod con una etiqueta que coincida con app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Para obtener más información sobre las directivas de red de Kubernetes y ejemplos adicionales de posibles directivas predeterminadas, consulte Directivas de red en la documentación de Kubernetes.

Cuotas de recursos

Las cuotas de recursos son una manera para que los administradores reserven y limiten los recursos a través de un proyecto o equipo de desarrollo. Puede establecer cuotas de recursos en un espacio de nombres y usarlas para establecer límites en lo siguiente:

• Recursos de proceso, como CPU y memoria, o GPU.
• Recursos de almacenamiento, incluido el número total de volúmenes o la cantidad de espacio en disco para una clase de almacenamiento determinada.
• Recuento de objetos, como el número máximo de secretos, servicios o trabajos que se pueden crear.

Una vez que el total acumulado de solicitudes o límites de recursos supera la cuota asignada, ya no se permiten más implementaciones.

Las cuotas de recursos garantizan que el conjunto total de pods asignados al espacio de nombres no pueda superar la cuota de recursos del espacio de nombres. El front-end no puede dejar sin recursos a los servicios de back-end ni viceversa.

Al definir las cuotas de recursos, todos los pods creados en el espacio de nombres deben proporcionar límites o recursos en sus especificaciones de pods. Si no proporcionan estos valores, se rechaza la implementación.

En el ejemplo siguiente se muestra una especificación de pods que establece los límites y las solicitudes de cuotas de recursos:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Para más información sobre las cuotas de recursos, consulte:

• Aplicación de cuotas de recursos
• Cuotas de recursos

Escalado automático

Kubernetes admite el escalado automático para aumentar el número de pods asignados a una implementación o aumentar los nodos del clúster para aumentar el total de recursos de proceso disponibles. El escalado automático es un sistema autónomo de retroalimentación que se corrige a sí mismo. Si bien puede escalar pods y nodos manualmente, el escalado automático minimiza la posibilidad de que los servicios se queden sin recursos con cargas elevadas. Una estrategia de escalado automático debe tienen en cuenta los pods y los nodos.

Escalado automático del clúster

El escalador automático del clúster escala el número de nodos. Suponga que no se pueden programar pods debido a restricciones de recursos, el escalador automático del clúster aprovisiona más nodos. Defina un número mínimo de nodos para mantener operativo el clúster de AKS y las cargas de trabajo, y un número máximo de nodos para el tráfico pesado. El escalador automático del clúster comprueba cada pocos segundos si hay pods pendientes o nodos vacíos, y escala el clúster de AKS correctamente.

En el ejemplo siguiente se muestra la configuración del escalador automático del clúster de la plantilla de ARM:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Las líneas siguientes de la plantilla de ARM establecen el mínimo y máximo de nodos de ejemplo para el escalador automático del clúster:

"minCount": 2,
"maxCount": 5,

Escalado automático de pods

Horizontal Pod Autoscaler (HPA) escala los pods en función de la CPU y la memoria observadas o de métricas personalizadas. Para configurar el escalado horizontal de pods, especifique las métricas de destino y el número mínimo y máximo de réplicas en la especificación de los pods de la implementación de Kubernetes. Haga una prueba de carga de los servicios para determinar estos números.

El escalador automático del clúster y HPA funcionan bien juntos, así que habilite ambas opciones de escalador automático en el clúster de AKS. HPA escala la aplicación, mientras que el escalador automático del clúster escala la infraestructura.

En el ejemplo siguiente se establecen las métricas de recursos para HPA:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA examina los recursos reales consumidos u otras métricas a partir de los pods en ejecución, pero el escalador automático del clúster aprovisiona nodos para pods que no están programados todavía. Por lo tanto, el escalador automático del clúster examina los recursos solicitados, tal como se especifica en la especificación de los pods. Use las pruebas de carga para ajustar estos valores.

Sondeos de estado

Kubernetes equilibra la carga del tráfico a los pods que coinciden con un selector de etiquetas para un servicio. Solo los pods que se iniciaron correctamente y que están en buen estado recibirán tráfico. Si se bloquea un contenedor, Kubernetes quita el pod y programa un reemplazo.

En Kubernetes, un pod puede exponer dos tipos de sondeo de estado:

• El sondeo de ejecución indica a Kubernetes si un pod se inició correctamente y es correcto.
• El sondeo de preparación indica a Kubernetes si un pod está listo para aceptar solicitudes.

Los sondeos de ejecución controlan los pods que todavía se están ejecutando, pero que son incorrectos y deben reciclarse. Por ejemplo, si un contenedor que atiende solicitudes HTTP se cuelga, el contenedor no se bloquea, pero deja de atender las solicitudes. El sondeo de ejecución HTTP deja de responder, lo que informa a Kubernetes que reinicie el pod.

En ocasiones, un pod puede no estar listo para recibir tráfico, aunque el pod se haya iniciado correctamente. Por ejemplo, la aplicación que se ejecuta en el contenedor podría estar realizando tareas de inicialización. El sondeo de preparación indica si el pod está listo para recibir tráfico.

Los microservicios deben exponer puntos de conexión en su código que faciliten los sondeos de estado, donde el retraso y el tiempo de espera estén adaptados específicamente a las comprobaciones que realizan. La fórmula de HPA controla casi exclusivamente la fase de preparación en un pod, por lo que es fundamental que los sondeos de estado existan y sean precisos.

Supervisión

En una aplicación de microservicios, la supervisión de Administración del rendimiento de las aplicaciones (APM) es fundamental para detectar anomalías, diagnosticar problemas y comprender rápidamente las dependencias entre los servicios. Application Insights, que forma parte de Azure Monitor, proporciona supervisión de APM para aplicaciones en directo escritas en .NET Core, Node.js, Java y muchos otros lenguajes de aplicación.

Información de la aplicación:

• Registra las solicitudes HTTP, incluida la latencia y el código de resultado.
• Habilita el seguimiento distribuido de manera predeterminada.
• Incluye un identificador de operación en los seguimientos, por lo que usted puede hacer coincidir todos los seguimientos para una operación determinada.
• A menudo incluye información contextual adicional en los seguimientos.

Para contextualizar la telemetría de los servicios con el mundo de Kubernetes, integre la telemetría de Azure Monitor en AKS para recopilar métricas de controladores, nodos y contenedores, así como registros de contenedores y de nodos. Si usa .NET, la biblioteca Application Insights for Kubernetes enriquece la telemetría de Application Insights con información de imágenes, contenedores, nodos, pods, etiquetas y conjuntos de réplicas.

En el diagrama siguiente se muestra un ejemplo del mapa de dependencias de aplicación que Application Insights genera para un seguimiento de la telemetría de microservicios de AKS:

Para obtener más información sobre las opciones para instrumentar lenguajes comunes para la integración de Application Insights, consulte Supervisión de aplicaciones para Kubernetes.

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.

Seguridad

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

Tenga en cuenta los siguientes puntos al planificar la seguridad.

• Un pod de AKS se autentica a sí mismo mediante una identidad de carga de trabajo almacenada en Microsoft Entra ID. Es preferible usar una identidad de carga de trabajo porque no requiere un secreto de cliente.

• Con las identidades administradas, el proceso de ejecución puede obtener rápidamente tokens OAuth 2.0 de Azure Resource Manager; no es necesario usar contraseñas ni cadenas de conexión. En AKS, puede asignar identidades a pods individuales mediante el identificador de carga de trabajo de Microsoft Entra.

• A cada servicio de la aplicación de microservicios se le debe asignar una única identidad de carga de trabajo para facilitar las asignaciones de RBAC con privilegios mínimos. Solo debe asignar identidades a los servicios que las requieran.

• En los casos en los que un componente de aplicación requiera acceso a la API de Kubernetes, asegúrese de que los pods de aplicación estén configurados para usar una cuenta de servicio con acceso de API con un ámbito adecuado. Para obtener más información sobre cómo configurar y administrar la cuenta de servicio de Kubernetes, consulte Administración de cuentas de servicio de Kubernetes.

• No todos los servicios de Azure admiten la autenticación del plano de datos mediante Microsoft Entra ID. Para almacenar credenciales o secretos de aplicación para esos servicios, para servicios de terceros o para claves de API, use Azure Key Vault. Azure Key Vault ofrece administración centralizada, control de acceso, cifrado en reposo y auditoría de todas las claves y secretos.

• En AKS, puede montar uno o más secretos de Key Vault como un volumen. Luego, el pod puede leer los secretos de Key Vault al igual que en un volumen normal. Para obtener más información, consulte el proyecto secrets-store-csi-driver-provider-azure en GitHub.

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.

• En la sección de costos del Marco de buena arquitectura de Microsoft Azure se describen las consideraciones sobre los costos. Use la Calculadora de precios de Azure para calcular los costos para su escenario específico.

• AKS no tiene ningún costo asociado con la implementación, administración y operaciones del clúster de Kubernetes. Solo paga por las instancias de VM, el almacenamiento y los recursos de red que use el clúster. El escalado automático del clúster puede reducir significativamente el costo del clúster al eliminar los nodos vacíos o sin usar.

• Para calcular el costo de los recursos necesarios, consulte la calculadora de servicios de contenedor.

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

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, vea Lista de comprobación de revisión de diseño para la excelencia operativa.

Tenga en cuenta los siguientes puntos al planificar la capacidad de administración.

• Administre la infraestructura del clúster de AKS a través de una canalización de implementación automatizada. La implementación de referencia de esta arquitectura proporciona un flujo de trabajo deAcciones de GitHub al que puede hacer referencia al crear la canalización.

• El archivo de flujo de trabajo implementa solo la infraestructura, no la carga de trabajo, en la red virtual y la configuración de Microsoft Entra ya existentes. La implementación de la infraestructura y la carga de trabajo por separado le permiten abordar distintos problemas operativos y del ciclo de vida.

• Considere el flujo de trabajo como un mecanismo para implementar en otra región si se produce un error regional. Compile la canalización de modo que pueda implementar un nuevo clúster en una nueva región con modificaciones en los parámetros y entradas.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar a fin de satisfacer las demandas que los usuarios ponen en ella de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Tenga en cuenta los siguientes puntos al planificar la escalabilidad.

• No combine el escalado automático y la administración imperativa ni declarativa del número de réplicas. Si tanto los usuarios como un escalador automático intentan modificar el número de réplicas, pueden provocar un comportamiento inesperado. Cuando HPA esté habilitado, reduzca el número de réplicas al número mínimo que quiera implementar.

• Un efecto secundario del escalado automático de pods es que estos podrían crearse o expulsarse con frecuencia, a medida que se producen eventos de escalado horizontal y reducción horizontal. Para mitigar estos efectos:

  • Use sondeos de preparación para que Kubernetes sepa cuándo está listo un pod nuevo para aceptar tráfico.
  • Use presupuestos de interrupciones de pods para limitar el número de pods que se puede expulsar de un servicio a la vez.

• No se puede cambiar el tamaño de VM después de crear un clúster, así que realice el planeamiento de capacidad inicial para elegir un tamaño de VM adecuado para los nodos de agente cuando cree el clúster.

• Las cargas de trabajo multiinquilino u otras cargas de trabajo avanzadas pueden tener requisitos de aislamiento del grupo de nodos que exigen más y probablemente subredes más pequeñas. Para obtener más información sobre cómo crear grupos de nodos con subredes únicas, consulte Adición de un grupo de nodos con una subred única. Las organizaciones tienen estándares diferentes para sus implementaciones de hub-and-spoke. Asegúrese de seguir las directrices de su organización.

Pasos siguientes

• Introducción a Azure Kubernetes Service
• ¿Qué es Azure Virtual Network?
• ¿Qué es Azure Private Link?
• ¿Qué es Azure Application Gateway?
• ¿Qué es Azure Bastion?
• Acerca de Azure Key Vault
• Introducción a Azure Container Registry
• Bienvenido a Azure Cosmos DB
• Introducción a Azure Monitor

Recursos relacionados

• Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)
• Diseño, compilación y funcionamiento de microservicios en Azure con Kubernetes
• Arquitectura de microservicios en AKS
• Creación de una canalización de CI/CD para microservicios en Kubernetes

Esta arquitectura de referencia detalla varias configuraciones que se deben tener en cuenta al ejecutar microservicios en Azure Kubernetes Services. Entre los temas se incluyen la configuración de directivas de red, el escalado automático de pods y el seguimiento distribuido en una aplicación basada en microservicios.

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 Azure Kubernetes Service (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 sobre los microservicios.

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

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Si prefiere empezar con un ejemplo de microservicios más básico en AKS, consulte Arquitectura de microservicios en AKS.

Flujo de trabajo

Este flujo de solicitud implementa los patrones de diseño de nube publicador y suscriptor, consumidores de la competenciay Gateway Routing. El flujo de mensajería avanza de la siguiente manera:

1. Se envía una solicitud HTTPS para programar la recogida con un dron. Las solicitudes pasan por Azure Application Gateway hasta la aplicación web de ingesta, que se ejecuta como microservicio en clúster en AKS.

2. La aplicación web de ingesta genera un mensaje y lo envía a la cola de mensajes de Service Bus.

3. El sistema back-end asigna un dron y notifica al usuario. El flujo de trabajo:

   • Consume información de mensajes de la cola de mensajes de Service Bus.
   • Envía una solicitud HTTPS al microservicio Entrega, que pasa datos al almacenamiento de datos externo de Azure Cache for Redis.
   • Envía una solicitud HTTPS al microservicio Programador de drones.
   • Envía una solicitud HTTPS al microservicio Empaquetado, que pasa datos al almacenamiento de datos externo de MongoDB.

4. Se usa una solicitud HTTPS GET para devolver el estado de entrega. Esta solicitud pasa por Application Gateway hasta el microservicio Entrega.

5. El microservicio Entrega lee datos de Azure Cache for Redis.

Componentes

Esta arquitectura utiliza los siguientes componentes de Azure:

Azure Kubernetes Service es una oferta de Azure que brinda un clúster de Kubernetes administrado. Al usar AKS, Azure administra el servidor de API de Kubernetes. Es posible acceder a los nodos o grupos de nodos de Kubernetes, y el operador del clúster puede administrarlos.

Entre las características de infraestructura de AKS que se usan en esta arquitectura se incluyen:

• Separación del grupo de nodos del sistema y del usuario
• Identificador de Microsoft Entra ID administrado por AKS para el control de acceso basado en rol (RBAC)
• Microsoft Entra Workload ID
• Complemento de Azure Policy para AKS
• Interfaz de red de contenedor de Azure (CNI)
• Conclusiones de contenedor de Azure Monitor

Las redes virtuales de Azure son entornos aislados y altamente seguros para ejecutar máquinas virtuales y aplicaciones. Esta arquitectura de referencia usa una topología de red en estrella tipo hub-and-spoke emparejada. La red virtual del centro contiene la instancia de Azure Firewall y subredes de Azure Bastion. La red virtual de radio contiene las subredes del grupo de nodos del sistema y de usuario de AKS, y la subred de Azure Application Gateway.

Azure Private Link asigna direcciones IP privadas específicas para acceder Azure Container Registry y Key Vault desde puntos de conexión privados dentro de la subred del grupo de nodos del sistema y de usuario de AKS.

Azure Application Gateway con firewall de aplicaciones web (WAF) expone rutas HTTP(S) al clúster de AKS y equilibra la carga del tráfico web a la aplicación web. Esta arquitectura usa el controlador de entrada de Azure Application Gateway (AGIC) como controlador de entrada de Kubernetes.

Azure Bastion proporciona acceso seguro de Protocolo de escritorio remoto (RDP) y de Secure Shell (SSH) a las VM de las redes virtuales mediante una capa de sockets seguros (SSL), sin necesidad de exponer las VM a través de direcciones IP públicas.

Azure Firewall es un servicio de seguridad de red que protege todos los recursos de Azure Virtual Network. El firewall solo permite servicios aprobados y nombres de dominio completos (FQDN) como tráfico de salida.

Almacenamiento externo y otros componentes:

Azure Key Vault almacena y administra las claves de seguridad de los servicios de AKS.

Azure Container Registry almacena imágenes de contenedor privadas que se pueden ejecutar en el clúster de AKS. AKS se autentica en Container Registry con su identidad administrada de Microsoft Entra. También puede usar otros registros de contenedor, como Docker Hub.

Azure Cosmos DB almacena datos mediante Azure Cosmos DB for MongoDB de código abierto. Los microservicios son normalmente sin estado y escriben el estado en almacenes de datos externos. Azure Cosmos DB es una base de datos NoSQL con API de código abierto para MongoDB y Cassandra.

Azure Service Bus ofrece mensajería como servicio e integración híbrida sencilla en la nube. Service Bus admite patrones de mensajería asincrónica que son comunes en las aplicaciones de microservicios.

Azure Cache for Redis agrega una capa de almacenamiento en caché a la arquitectura de la aplicación para mejorar la velocidad y el rendimiento de las cargas de tráfico intensas.

Azure Monitor recopila y almacena métricas y registros, incluida la telemetría de las aplicaciones y las métricas de la plataforma y de servicios de Azure. Puede usar estos datos para supervisar la aplicación, configurar alertas y paneles, y realizar el análisis de causa principal de los errores.

Otros componentes del sistema de soporte de operaciones (OSS):

Helm , administrador de paquetes para Kubernetes, que agrupa objetos de Kubernetes en una sola unidad que se puede publicar, implementar, versionar y actualizar.

proveedor CSI del Almacén secreto de Azure Key Vault obtiene secretos almacenados en Azure Key Vault y usa la interfaz de del controlador CSI del almacén secreto de para montarlos en pods de Kubernetes.

Flux , solución de entrega continua abierta y extensible para Kubernetes, con tecnología del kit de herramientas de GitOps.

Detalles del escenario

En el ejemplo de aplicación de entrega con drones de Fabrikam que se muestra en el diagrama anterior se implementan los componentes y las prácticas de arquitectura que se tratan en este artículo. En este ejemplo, Fabrikam, Inc., una empresa ficticia, administra una flota de drones. Las empresas se registran en el servicio y los usuarios pueden solicitar que un dron recoja los bienes para la entrega. Cuando un cliente programa una recogida, un sistema back-end asigna un dron y notifica al usuario con una hora de entrega estimada. Mientras la entrega está en curso, el cliente puede hacer un seguimiento del dron, con una fecha estimada que se actualiza constantemente.

Posibles casos de uso

Esta solución es perfecta para los sectores de aeronaves, aeroespaciales y de aeronaves.

Recomendaciones

Implemente estas recomendaciones al implementar arquitecturas avanzadas de microservicios de AKS.

Controlador de entrada de Application Gateway (AGIC)

La API Gateway Routing es un patrón de diseño de microservicios general. Una puerta de enlace de API actúa como proxy inverso que enruta las solicitudes de los clientes a los microservicios. El recurso de entrada y el controlador de entrada de Kubernetes controlan la mayor parte de la funcionalidad de la puerta de enlace de API mediante:

El enrutamiento de solicitudes de cliente a los servicios back-end correctos proporciona un único punto de conexión para los clientes y ayuda a desacoplar los clientes de los servicios.

• Agregue varias solicitudes en una sola solicitud, para reducir el intercambio de mensajes entre el cliente y el back-end.
• Descargue funcionalidades, como la terminación SSL, la autenticación, las restricciones de IP o la limitación de velocidad del cliente, de los servicios de back-end.

El estado del clúster de AKS se traduce a una configuración específica de Application Gateway y se aplica a través de Azure Resource Manager.

Los controladores de entrada externos simplifican la ingesta de tráfico en clústeres de AKS, mejoran la seguridad y el rendimiento, y ahorran recursos. Esta arquitectura usa el controlador de entrada de Azure Application Gateway (AGIC) para el control de entrada. El uso de Application Gateway para controlar todo el tráfico elimina la necesidad de un equilibrador de carga adicional. Dado que los pods establecen conexiones directas con Application Gateway, se reduce el número de saltos necesarios, con lo que se logra un mejor rendimiento.

Application Gateway tiene integradas funcionalidades de escalado automático, a diferencia de los controladores de entrada en clústeres, que se deben escalar horizontalmente si consumen una cantidad excesiva de recursos de proceso. Application Gateway puede realizar enrutamiento de nivel 7 y terminación SSL, y tiene Seguridad de la capa de transporte (TLS) de un extremo a otro integrada en un firewall de aplicaciones web (WAF) integrado.

Para la opción de entrada AGIC, tiene que habilitar las redes de CNI al configurar el clúster de AKS, ya que Application Gateway se implementa en una subred de la red virtual de AKS. Las cargas de trabajo multiinquilino, o un único clúster que admita entornos de desarrollo y pruebas, podrían requerir más controladores de entrada.

Directivas de red de confianza cero

Las directivas de red especifican cómo se permite que los pods de AKS se comuniquen entre sí y con otros puntos de conexión de red. De manera predeterminada, todo el tráfico de entrada y salida se permite hacia los pods y desde estos. Al diseñar cómo se comunican los microservicios entre sí y con otros puntos de conexión, considere la posibilidad de seguir un principio de confianza cero, donde el acceso a cualquier servicio, dispositivo, aplicación o repositorio de datos requiere una configuración explícita.

Una estrategia para implementar una directiva de confianza cero es crear una directiva de red que deniegue todo el tráfico de entrada y de salida a todos los pods dentro del espacio de nombres de destino. En el ejemplo siguiente se muestra una "directiva de denegar todo" que se aplicaría a todos los pods ubicados en el espacio de nombres backend-dev.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Una vez que se haya puesto en práctica una directiva restrictiva, comience a definir reglas de red específicas para permitir el tráfico de entrada y de salida de cada pod en el microservicio. En el ejemplo siguiente, la directiva de red se aplica a cualquier pod del espacio de nombres backend-dev con una etiqueta que coincida con app.kubernetes.io/component: backend. La política deniega cualquier tráfico a menos que provenga de un pod con una etiqueta que coincida con app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Para obtener más información sobre las directivas de red de Kubernetes y ejemplos adicionales de posibles directivas predeterminadas, consulte Directivas de red en la documentación de Kubernetes.

Cuotas de recursos

Las cuotas de recursos son una manera para que los administradores reserven y limiten los recursos a través de un proyecto o equipo de desarrollo. Puede establecer cuotas de recursos en un espacio de nombres y usarlas para establecer límites en lo siguiente:

• Recursos de proceso, como CPU y memoria, o GPU.
• Recursos de almacenamiento, incluido el número total de volúmenes o la cantidad de espacio en disco para una clase de almacenamiento determinada.
• Recuento de objetos, como el número máximo de secretos, servicios o trabajos que se pueden crear.

Una vez que el total acumulado de solicitudes o límites de recursos supera la cuota asignada, ya no se permiten más implementaciones.

Las cuotas de recursos garantizan que el conjunto total de pods asignados al espacio de nombres no pueda superar la cuota de recursos del espacio de nombres. El front-end no puede dejar sin recursos a los servicios de back-end ni viceversa.

Al definir las cuotas de recursos, todos los pods creados en el espacio de nombres deben proporcionar límites o recursos en sus especificaciones de pods. Si no proporcionan estos valores, se rechaza la implementación.

En el ejemplo siguiente se muestra una especificación de pods que establece los límites y las solicitudes de cuotas de recursos:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Para más información sobre las cuotas de recursos, consulte:

• Aplicación de cuotas de recursos
• Cuotas de recursos

Escalado automático

Kubernetes admite el escalado automático para aumentar el número de pods asignados a una implementación o aumentar los nodos del clúster para aumentar el total de recursos de proceso disponibles. El escalado automático es un sistema autónomo de retroalimentación que se corrige a sí mismo. Si bien puede escalar pods y nodos manualmente, el escalado automático minimiza la posibilidad de que los servicios se queden sin recursos con cargas elevadas. Una estrategia de escalado automático debe tienen en cuenta los pods y los nodos.

Escalado automático del clúster

El escalador automático del clúster escala el número de nodos. Suponga que no se pueden programar pods debido a restricciones de recursos, el escalador automático del clúster aprovisiona más nodos. Defina un número mínimo de nodos para mantener operativo el clúster de AKS y las cargas de trabajo, y un número máximo de nodos para el tráfico pesado. El escalador automático del clúster comprueba cada pocos segundos si hay pods pendientes o nodos vacíos, y escala el clúster de AKS correctamente.

En el ejemplo siguiente se muestra la configuración del escalador automático del clúster de la plantilla de ARM:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Las líneas siguientes de la plantilla de ARM establecen el mínimo y máximo de nodos de ejemplo para el escalador automático del clúster:

"minCount": 2,
"maxCount": 5,

Escalado automático de pods

Horizontal Pod Autoscaler (HPA) escala los pods en función de la CPU y la memoria observadas o de métricas personalizadas. Para configurar el escalado horizontal de pods, especifique las métricas de destino y el número mínimo y máximo de réplicas en la especificación de los pods de la implementación de Kubernetes. Haga una prueba de carga de los servicios para determinar estos números.

El escalador automático del clúster y HPA funcionan bien juntos, así que habilite ambas opciones de escalador automático en el clúster de AKS. HPA escala la aplicación, mientras que el escalador automático del clúster escala la infraestructura.

En el ejemplo siguiente se establecen las métricas de recursos para HPA:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA examina los recursos reales consumidos u otras métricas a partir de los pods en ejecución, pero el escalador automático del clúster aprovisiona nodos para pods que no están programados todavía. Por lo tanto, el escalador automático del clúster examina los recursos solicitados, tal como se especifica en la especificación de los pods. Use las pruebas de carga para ajustar estos valores.

Sondeos de estado

Kubernetes equilibra la carga del tráfico a los pods que coinciden con un selector de etiquetas para un servicio. Solo los pods que se iniciaron correctamente y que están en buen estado recibirán tráfico. Si se bloquea un contenedor, Kubernetes quita el pod y programa un reemplazo.

En Kubernetes, un pod puede exponer dos tipos de sondeo de estado:

• El sondeo de ejecución indica a Kubernetes si un pod se inició correctamente y es correcto.
• El sondeo de preparación indica a Kubernetes si un pod está listo para aceptar solicitudes.

Los sondeos de ejecución controlan los pods que todavía se están ejecutando, pero que son incorrectos y deben reciclarse. Por ejemplo, si un contenedor que atiende solicitudes HTTP se cuelga, el contenedor no se bloquea, pero deja de atender las solicitudes. El sondeo de ejecución HTTP deja de responder, lo que informa a Kubernetes que reinicie el pod.

En ocasiones, un pod puede no estar listo para recibir tráfico, aunque el pod se haya iniciado correctamente. Por ejemplo, la aplicación que se ejecuta en el contenedor podría estar realizando tareas de inicialización. El sondeo de preparación indica si el pod está listo para recibir tráfico.

Los microservicios deben exponer puntos de conexión en su código que faciliten los sondeos de estado, donde el retraso y el tiempo de espera estén adaptados específicamente a las comprobaciones que realizan. La fórmula de HPA controla casi exclusivamente la fase de preparación en un pod, por lo que es fundamental que los sondeos de estado existan y sean precisos.

Supervisión

En una aplicación de microservicios, la supervisión de Administración del rendimiento de las aplicaciones (APM) es fundamental para detectar anomalías, diagnosticar problemas y comprender rápidamente las dependencias entre los servicios. Application Insights, que forma parte de Azure Monitor, proporciona supervisión de APM para aplicaciones en directo escritas en .NET Core, Node.js, Java y muchos otros lenguajes de aplicación.

Información de la aplicación:

• Registra las solicitudes HTTP, incluida la latencia y el código de resultado.
• Habilita el seguimiento distribuido de manera predeterminada.
• Incluye un identificador de operación en los seguimientos, por lo que usted puede hacer coincidir todos los seguimientos para una operación determinada.
• A menudo incluye información contextual adicional en los seguimientos.

Para contextualizar la telemetría de los servicios con el mundo de Kubernetes, integre la telemetría de Azure Monitor en AKS para recopilar métricas de controladores, nodos y contenedores, así como registros de contenedores y de nodos. Si usa .NET, la biblioteca Application Insights for Kubernetes enriquece la telemetría de Application Insights con información de imágenes, contenedores, nodos, pods, etiquetas y conjuntos de réplicas.

En el diagrama siguiente se muestra un ejemplo del mapa de dependencias de aplicación que Application Insights genera para un seguimiento de la telemetría de microservicios de AKS:

Para obtener más información sobre las opciones para instrumentar lenguajes comunes para la integración de Application Insights, consulte Supervisión de aplicaciones para Kubernetes.

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.

Seguridad

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

Tenga en cuenta los siguientes puntos al planificar la seguridad.

• Un pod de AKS se autentica a sí mismo mediante una identidad de carga de trabajo almacenada en Microsoft Entra ID. Es preferible usar una identidad de carga de trabajo porque no requiere un secreto de cliente.

• Con las identidades administradas, el proceso de ejecución puede obtener rápidamente tokens OAuth 2.0 de Azure Resource Manager; no es necesario usar contraseñas ni cadenas de conexión. En AKS, puede asignar identidades a pods individuales mediante el identificador de carga de trabajo de Microsoft Entra.

• A cada servicio de la aplicación de microservicios se le debe asignar una única identidad de carga de trabajo para facilitar las asignaciones de RBAC con privilegios mínimos. Solo debe asignar identidades a los servicios que las requieran.

• En los casos en los que un componente de aplicación requiera acceso a la API de Kubernetes, asegúrese de que los pods de aplicación estén configurados para usar una cuenta de servicio con acceso de API con un ámbito adecuado. Para obtener más información sobre cómo configurar y administrar la cuenta de servicio de Kubernetes, consulte Administración de cuentas de servicio de Kubernetes.

• No todos los servicios de Azure admiten la autenticación del plano de datos mediante Microsoft Entra ID. Para almacenar credenciales o secretos de aplicación para esos servicios, para servicios de terceros o para claves de API, use Azure Key Vault. Azure Key Vault ofrece administración centralizada, control de acceso, cifrado en reposo y auditoría de todas las claves y secretos.

• En AKS, puede montar uno o más secretos de Key Vault como un volumen. Luego, el pod puede leer los secretos de Key Vault al igual que en un volumen normal. Para obtener más información, consulte el proyecto secrets-store-csi-driver-provider-azure en GitHub.

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.

• En la sección de costos del Marco de buena arquitectura de Microsoft Azure se describen las consideraciones sobre los costos. Use la Calculadora de precios de Azure para calcular los costos para su escenario específico.

• AKS no tiene ningún costo asociado con la implementación, administración y operaciones del clúster de Kubernetes. Solo paga por las instancias de VM, el almacenamiento y los recursos de red que use el clúster. El escalado automático del clúster puede reducir significativamente el costo del clúster al eliminar los nodos vacíos o sin usar.

• Para calcular el costo de los recursos necesarios, consulte la calculadora de servicios de contenedor.

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

Excelencia operativa

La excelencia operativa abarca los procesos de operaciones que implementan una aplicación y lo mantienen en ejecución en producción. Para obtener más información, vea Lista de comprobación de revisión de diseño para la excelencia operativa.

Tenga en cuenta los siguientes puntos al planificar la capacidad de administración.

• Administre la infraestructura del clúster de AKS a través de una canalización de implementación automatizada. La implementación de referencia de esta arquitectura proporciona un flujo de trabajo deAcciones de GitHub al que puede hacer referencia al crear la canalización.

• El archivo de flujo de trabajo implementa solo la infraestructura, no la carga de trabajo, en la red virtual y la configuración de Microsoft Entra ya existentes. La implementación de la infraestructura y la carga de trabajo por separado le permiten abordar distintos problemas operativos y del ciclo de vida.

• Considere el flujo de trabajo como un mecanismo para implementar en otra región si se produce un error regional. Compile la canalización de modo que pueda implementar un nuevo clúster en una nueva región con modificaciones en los parámetros y entradas.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar a fin de satisfacer las demandas que los usuarios ponen en ella de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Tenga en cuenta los siguientes puntos al planificar la escalabilidad.

• No combine el escalado automático y la administración imperativa ni declarativa del número de réplicas. Si tanto los usuarios como un escalador automático intentan modificar el número de réplicas, pueden provocar un comportamiento inesperado. Cuando HPA esté habilitado, reduzca el número de réplicas al número mínimo que quiera implementar.

• Un efecto secundario del escalado automático de pods es que estos podrían crearse o expulsarse con frecuencia, a medida que se producen eventos de escalado horizontal y reducción horizontal. Para mitigar estos efectos:

  • Use sondeos de preparación para que Kubernetes sepa cuándo está listo un pod nuevo para aceptar tráfico.
  • Use presupuestos de interrupciones de pods para limitar el número de pods que se puede expulsar de un servicio a la vez.

• No se puede cambiar el tamaño de VM después de crear un clúster, así que realice el planeamiento de capacidad inicial para elegir un tamaño de VM adecuado para los nodos de agente cuando cree el clúster.

• Las cargas de trabajo multiinquilino u otras cargas de trabajo avanzadas pueden tener requisitos de aislamiento del grupo de nodos que exigen más y probablemente subredes más pequeñas. Para obtener más información sobre cómo crear grupos de nodos con subredes únicas, consulte Adición de un grupo de nodos con una subred única. Las organizaciones tienen estándares diferentes para sus implementaciones de hub-and-spoke. Asegúrese de seguir las directrices de su organización.

Pasos siguientes

• Introducción a Azure Kubernetes Service
• ¿Qué es Azure Virtual Network?
• ¿Qué es Azure Private Link?
• ¿Qué es Azure Application Gateway?
• ¿Qué es Azure Bastion?
• Acerca de Azure Key Vault
• Introducción a Azure Container Registry
• Bienvenido a Azure Cosmos DB
• Introducción a Azure Monitor

Recursos relacionados

• Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)
• Diseño, compilación y funcionamiento de microservicios en Azure con Kubernetes
• Arquitectura de microservicios en AKS
• Creación de una canalización de CI/CD para microservicios en Kubernetes