Compartir a través de

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 describe varias configuraciones que se deben tener en cuenta al ejecutar microservicios en Azure Kubernetes Service (AKS). En este artículo se describe 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 base de AKS, que Microsoft recomienda como punto de partida para la infraestructura de AKS. La línea de base de AKS describe características infraestructurales como el identificador de carga de trabajo de Microsoft Entra, las restricciones de entrada y salida, los límites de recursos y otras configuraciones de infraestructura de AKS seguras. Estas características no se tratan en este artículo. Se recomienda familiarizarse con la arquitectura de línea base de AKS antes de continuar con el contenido de los microservicios.

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

Arquitectura

Diagrama de red que muestra una red en estrella tipo hub-spoke que tiene dos redes virtuales emparejadas y los recursos de Azure que usa esta implementación.

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 siguiente flujo de trabajo corresponde al diagrama anterior:

  1. Se envía una solicitud HTTPS para programar la recogida con un dron. La solicitud pasa a través de Azure Application Gateway a la aplicación web de ingesta, que se ejecuta como un 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 Azure Service Bus.

  3. El sistema back-end asigna un dron y notifica al usuario. El microservicio de flujo de trabajo realiza las siguientes tareas:

    • Consume información de mensajes de la cola de mensajes de Service Bus
    • Envía una solicitud HTTPS al microservicio de entrega, que pasa datos al almacenamiento de datos externos de Azure Cache for Redis.
    • Envía una solicitud HTTPS al microservicio del programador de drones
    • Envía una solicitud HTTPS al microservicio del paquete, que pasa datos al almacenamiento de datos externos de MongoDB.

  4. La arquitectura usa una solicitud HTTPS GET para devolver el estado de entrega. Esta solicitud pasa a través de Application Gateway al microservicio de entrega.

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

Componentes

Almacenamiento externo y otros componentes

  • Key Vault almacena y administra claves de seguridad, valores secretos y certificados para los servicios de Azure. En esta arquitectura, los almacenes de claves de Azure almacenan credenciales para Azure Cosmos DB y Azure Cache for Redis.

  • Container Registry almacena imágenes de contenedor privadas que se pueden ejecutar en el clúster de AKS. AKS se autentica con Container Registry mediante su identidad administrada de Microsoft Entra. También puede usar otros registros de contenedor, como Docker Hub. En esta arquitectura, Container Registry almacena las imágenes de contenedor para los microservicios.

  • Azure Cosmos DB es una base de datos NoSQL, relacional y vectorial totalmente administrada. Los microservicios son normalmente sin estado y escriben el estado en almacenes de datos externos. Azure Cosmos DB tiene API de código abierto para MongoDB, PostgreSQL y Cassandra. En esta arquitectura, Azure Cosmos DB y Azure Cosmos DB para MongoDB sirven como almacenes de datos para cada microservicio.

  • Service Bus proporciona mensajería en la nube confiable como servicio e integración híbrida sencilla. Service Bus admite patrones de mensajería asincrónica que son comunes en las aplicaciones de microservicios. En esta arquitectura, Service Bus actúa como la capa de cola asincrónica entre los microservicios de ingesta y flujo de trabajo.

  • 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 intensivo. En esta arquitectura, el microservicio de entrega usa Azure Cache for Redis como almacén de estado y caché lateral.

  • 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. En esta arquitectura, puede usar estos datos para supervisar la aplicación, configurar alertas y paneles y realizar el análisis de la causa principal de los errores.

Otras operaciones admiten componentes del sistema

  • Helm es un administrador de paquetes para Kubernetes que agrupa objetos de Kubernetes en una sola unidad que puede publicar, implementar, actualizar y actualizar. En esta arquitectura, use comandos de Helm para empaquetar e implementar microservicios en el clúster de AKS.

  • Proveedor de controladores CSI del almacén de secretos de Key Vault El proveedor de Key Vault para secrets Store CSI Driver permite la integración de un almacén de claves como almacén de secretos con un clúster de AKS a través de un volumen CSI. En esta arquitectura, los secretos del almacén de claves se montan como un volumen en contenedores de microservicios para que los microservicios puedan recuperar las credenciales de Azure Cosmos DB, Azure Cache for Redis y Service Bus.

  • Flux es una solución de entrega continua abierta y extensible para Kubernetes que habilita GitOps en AKS.

Alternativas

En lugar de usar un complemento de enrutamiento de aplicaciones, puede usar alternativas como Application Gateway para contenedores e complemento de puerta de enlace de Istio. Para obtener una comparación de las opciones de entrada en AKS, consulte Entrada en AKS. Application Gateway para contenedores es una evolución del controlador de entrada de Application Gateway y proporciona características adicionales, como la división del tráfico y el equilibrio de carga round robin ponderado.

Puede usar ArgoCD como herramienta de GitOps en lugar de Flux v2. Flux v2 y ArgoCD están disponibles como extensiones de clúster.

En lugar de almacenar credenciales para Azure Cosmos DB y Azure Cache for Redis en almacenes de claves, se recomienda usar identidades administradas para autenticarse porque los mecanismos de autenticación sin contraseña son más seguros. Para más información, consulte Uso de identidades administradas para conectarse a Azure Cosmos DB desde una máquina virtual de Azure y Autenticar una identidad administrada mediante el identificador de Entra de Microsoft para acceder a los recursos de Service Bus. Azure Cache for Redis también admite la autenticación mediante identidades administradas.

Detalles del escenario

En el ejemplo fabrikam Drone Delivery Shipping App que se muestra en el diagrama anterior se implementan los componentes y procedimientos arquitectónicos que se describen 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, el sistema back-end asigna un dron y notifica al usuario un tiempo de entrega estimado. Mientras la entrega está en curso, el cliente puede realizar un seguimiento de la ubicación del dron y ver una hora estimada de llegada actualizada continuamente.

Recomendaciones

Puede aplicar las siguientes recomendaciones a la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

Entrada NGINX administrada con complemento de enrutamiento de aplicaciones

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

  • Enrutamiento de solicitudes de cliente a los servicios back-end correctos para proporcionar un único punto de conexión para los clientes y ayudar a desacoplar clientes de servicios

  • Agregación de varias solicitudes en una sola solicitud para reducir el chatter entre el cliente y el back-end

  • Descarga de funcionalidades como la terminación de capa de sockets seguros (SSL), la autenticación, las restricciones de direcciones IP y la limitación o limitación de velocidad de cliente de los servicios back-end

Los controladores de entrada simplifican la ingesta de tráfico en clústeres de AKS, mejoran la seguridad y el rendimiento y ahorran recursos. Esta arquitectura usa la entrada NGINX administrada con el complemento de enrutamiento de aplicaciones para el control de entrada.

Se recomienda usar el controlador de entrada con una dirección IP interna (privada) y un equilibrador de carga interno e integrarlo en zonas del sistema de nombres de dominio privados de Azure para la resolución de nombres de host de microservicios. Configure la dirección IP privada o el nombre de host del controlador de entrada como la dirección del grupo de back-end en Application Gateway. Application Gateway recibe tráfico en el punto de conexión público, realiza inspecciones de WAF y enruta el tráfico a la dirección IP privada de entrada.

Debe configurar el controlador de entrada con un nombre de dominio personalizado y un certificado SSL para que el tráfico esté cifrado de un extremo a otro. Application Gateway recibe tráfico en el agente de escucha HTTPS. Después de las inspecciones de WAF, Application Gateway enruta el tráfico al punto de conexión HTTPS del controlador de entrada. Todos los microservicios deben configurarse con nombres de dominio personalizados y certificados SSL para que la comunicación entre microservicios dentro del clúster de AKS también esté protegida mediante SSL.

Las cargas de trabajo multiinquilino o un único clúster que admita entornos de desarrollo y pruebas pueden requerir más controladores de entrada. El complemento de enrutamiento de aplicaciones admite configuraciones avanzadas y personalizaciones, incluidos varios controladores de entrada dentro del mismo clúster de AKS y el uso de anotaciones para configurar recursos 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 deniega todo el tráfico de entrada y salida a todos los pods del espacio de nombres de destino. En el ejemplo siguiente se muestra una directiva deny all que se aplica a todos los pods ubicados en el backend-dev espacio de nombres.

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 implementado una directiva restrictiva, empiece a definir reglas de red específicas para permitir el tráfico hacia y fuera de cada pod del microservicio. En el ejemplo siguiente, la directiva de red se aplica a cualquier pod del backend-dev espacio de nombres que tenga una etiqueta que coincida con app.kubernetes.io/component: backend. La directiva deniega cualquier tráfico a menos que se origine desde un pod que tenga 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 más información sobre las directivas de red de Kubernetes y más ejemplos de posibles directivas predeterminadas, consulte Directivas de red en la documentación de Kubernetes.

Azure proporciona tres motores de directivas de red para aplicar directivas de red:

  • Cilium para clústeres de AKS que usan Azure CNI Powered by Cilium
  • Administrador de directivas de red de Azure
  • Calico, una solución de seguridad de red y red de código abierto

Se recomienda usar Cilium como motor de directivas de red.

Cuotas de recursos

Los administradores usan cuotas de recursos para reservar y limitar los recursos en un equipo de desarrollo o proyecto. Puede establecer cuotas de recursos en un espacio de nombres y usarlas para establecer límites en los siguientes recursos:

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

Después de que el total acumulado de solicitudes o límites de recursos supere la cuota asignada, no se realiza correctamente ninguna implementación adicional.

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 usar todos los recursos para los servicios back-end y el back-end no puede usar todos los recursos para los servicios front-end.

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 pod que establece las solicitudes y límites de cuota de recursos:

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

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

Escalado automático

Kubernetes admite el escalado automático para aumentar el número de pods asignados a una implementación o para 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. Puede escalar los pods y los nodos manualmente, pero el escalado automático minimiza las posibilidades de que los servicios alcancen los límites de recursos en cargas elevadas. Una estrategia de escalado automático debe tener en cuenta los pods y los nodos.

Escalado automático del clúster

Cluster Autoscaler (CA) escala el número de nodos. Si los pods no se pueden programar 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 de ca de la plantilla de Bicep:

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 siguientes líneas de la plantilla de Bicep establecen un ejemplo mínimo y máximo de nodos para el escalador automático del clúster:

minCount: 2
maxCount: 5

Escalado automático de pods horizontal

Horizontal Pod Autoscaler (HPA) escala los pods en función de las métricas observadas de CPU, memoria o 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 del pod de implementación de Kubernetes. Prueba de carga de los servicios para determinar estos números.

CA y HPA funcionan conjuntamente, por lo 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/v2
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
        target:
          type: Utilization
          averageUtilization: 70

HPA examina los recursos reales consumidos u otras métricas de los pods en ejecución. La ENTIDAD de certificación aprovisiona nodos para pods que aún no están programados. Como resultado, la ENTIDAD de certificación examina los recursos solicitados, tal como se especifica en la especificación del pod. Use pruebas de carga para ajustar estos valores.

Para obtener más información, consulte Opciones de escalado para aplicaciones en AKS.

Escalado vertical automático de pods

Vertical Pod Autoscaler (VPA) ajusta automáticamente las solicitudes de CPU y memoria de los pods para que coincidan con los patrones de uso de las cargas de trabajo. Cuando se configura, el VPA establece automáticamente las solicitudes de recursos y los límites de los contenedores para cada carga de trabajo en función del uso pasado. El VPA pone la CPU y la memoria disponibles para otros pods y ayuda a garantizar el uso eficaz de los clústeres de AKS.

En esta arquitectura, VPA aumenta las solicitudes de CPU y memoria y los límites de los microservicios en función de su uso anterior. Por ejemplo, si el microservicio de flujo de trabajo consume más CPU en comparación con otros microservicios, el VPA puede supervisar este uso y aumentar los límites de CPU para el microservicio de flujo de trabajo.

Escalado automático controlado por eventos de Kubernetes

El complemento Escalador automático controlado por eventos (KEDA) de Kubernetes permite el escalado automático controlado por eventos para escalar el microservicio para satisfacer la demanda de forma sostenible y rentable. Por ejemplo, KEDA puede escalar verticalmente microservicios cuando el número de mensajes de la cola de Service Bus supera los umbrales específicos.

En el ejemplo de entrega de drones de Fabrikam, KEDA escala horizontalmente el microservicio de flujo de trabajo en función de la profundidad de la cola de Service Bus y en función de la salida del microservicio de ingesta. Para obtener una lista de los escaladores keda para los servicios de Azure, consulte Integraciones con KEDA en AKS.

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.

Kubernetes define tres tipos de sondeos de estado que un pod puede exponer:

  • El sondeo de preparación indica a Kubernetes si el pod está listo para aceptar solicitudes.

  • El sondeo de ejecución indica a Kubernetes si se debe quitar un pod y se debe iniciar una nueva instancia.

  • El sondeo de inicio indica a Kubernetes si se inicia el pod.

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, que alerta a Kubernetes para reiniciar 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 facilitan los sondeos de estado, con retraso y tiempo de espera adaptados específicamente a las comprobaciones que realizan. La fórmula HPA se basa en la fase lista del pod, por lo que es fundamental que existan sondeos de estado y sean precisos.

Supervisión

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

Azure proporciona varios mecanismos para supervisar cargas de trabajo de microservicios:

  • Prometheus Administrado para la recopilación de métricas. Use Prometheus para supervisar y alertar sobre el rendimiento de la infraestructura y las cargas de trabajo.

  • El servicio administrado de Azure Monitor para Prometheus y Container Insights funcionan conjuntamente para una supervisión completa del entorno de Kubernetes.

  • Grafana administrado para la visualización de clústeres y microservicios.

Para contextualizar la telemetría del servicio en Kubernetes, integre la telemetría de Azure Monitor con AKS para recopilar métricas de controladores, nodos, contenedores y registros de contenedores y nodos. Puede integrar Application Insights con AKS sin cambios en el código.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, vea Well-Architected Framework.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido 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.

Tenga en cuenta los siguientes puntos cuando planee la seguridad.

  • Use medidas de seguridad de implementación en el clúster de AKS. Las medidas de seguridad de implementación aplican los procedimientos recomendados de Kubernetes en el clúster de AKS mediante controles de Azure Policy.

  • Integre el análisis de seguridad en las canalizaciones de implementación y compilación de microservicios. Administre el entorno de DevOps mediante la seguridad de Microsoft Defender for Cloud DevOps. Use el análisis de código sin agente y ejecute herramientas de análisis de código estático como parte de las canalizaciones de integración continua e implementación continua (CI/CD) para que pueda identificar y abordar las vulnerabilidades del código de microservicio como parte de los procesos de compilación e implementación.

  • Un pod de AKS se autentica mediante una identidad de carga de trabajo almacenada en el identificador de Microsoft Entra. Debe usar una identidad de carga de trabajo porque no requiere un secreto de cliente.

  • Cuando se usan identidades administradas, la aplicación puede obtener rápidamente tokens de OAuth 2.0 de Azure Resource Manager cuando se ejecuta. No necesita contraseñas ni cadenas de conexión. En AKS, puede asignar identidades a pods individuales mediante el identificador de carga de trabajo.

  • 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 más información, consulte Administración de cuentas de servicio de Kubernetes.

  • No todos los servicios de Azure admiten el uso de Microsoft Entra ID para la autenticación del plano de datos. Para almacenar credenciales o secretos de aplicación para esos servicios, para servicios que no son de Microsoft o para claves de API, use Key Vault. Key Vault proporciona 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 más información, consulte Uso del proveedor de Key Vault para el controlador CSI del almacén de secretos en un clúster de AKS. Se recomienda mantener almacenes de claves independientes para cada microservicio. La implementación de referencia usa almacenes de claves independientes para cada microservicio.

  • Si el microservicio necesita comunicarse con recursos, como direcciones URL externas, fuera del clúster, controle el acceso a través de Azure Firewall. Si el microservicio no necesita realizar ninguna llamada saliente, use clústeres aislados de red.

  • Habilite Microsoft Defender para contenedores para proporcionar administración de la posición de seguridad, evaluación de vulnerabilidades para microservicios, protección contra amenazas en tiempo de ejecución y otras características de seguridad.

Optimización de costos

La optimización de costos se centra en 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 Optimización de costos de Well-Architected Framework se describen las consideraciones de costos.

  • Use la Calculadora de precios de Azure para calcular los costos para su escenario específico.

  • En el nivel Gratis, AKS no tiene ningún costo asociado a la implementación, la administración y las operaciones del clúster de Kubernetes. Solo paga por las instancias de máquina virtual, el almacenamiento y los recursos de red que consume 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.

  • Considere la posibilidad de usar el nivel Gratis de AKS para cargas de trabajo de desarrollo y use los niveles Estándar y Premium para cargas de trabajo de producción.

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

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 planear 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 de Acciones de GitHub al que puede hacer referencia al compilar 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 permite abordar distintos problemas operativos y de 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 para que pueda implementar un nuevo clúster en una nueva región con cambios de entrada y parámetros.

Eficiencia del rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios 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 planear la escalabilidad.

  • No combine el escalado automático y la administración imperativa ni declarativa del número de réplicas. Los usuarios y 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 desea implementar.

  • Un efecto secundario del escalado automático de pods es que los pods se pueden crear o expulsar con frecuencia a medida que la aplicación se escala o se escala horizontalmente. Para mitigar estos efectos, realice las siguientes acciones:

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

  • Si hay un gran número de flujos salientes desde el microservicio, considere la posibilidad de usar puertas de enlace de traducción de direcciones de red para evitar el agotamiento de puertos de traducción de direcciones de red de origen.

  • 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 más información, consulte Adición de grupos de nodos con subredes únicas. Las organizaciones tienen estándares diferentes para sus implementaciones de hub-and-spoke. Asegúrese de seguir las directrices de su organización.

  • Considere la posibilidad de usar CNI con redes superpuestas para conservar el espacio de direcciones de red.

Pasos siguientes