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 de base de AKS, que actúa 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 de base de AKS antes de continuar con el contenido de los microservicios.

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

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.
La aplicación web de ingesta genera un mensaje y lo envía a la cola de mensajes de Azure Service Bus.
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 externo de Azure Managed 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 Azure DocumentDB.
- Las políticas avanzadas de servicios de redes de contenedores (Cilium NetworkPolicy) rigen el tráfico de servicio a servicio dentro del clúster, y el plano de datos aplica de manera transparente el cifrado opcional de pods entre nodos (WireGuard). Advanced Container Networking Services no está habilitado de forma predeterminada. Captura los datos de nivel de nodo y pod y los ingiere en Azure Monitor para obtener visibilidad de un extremo a otro.
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.
El microservicio de entrega lee los datos de Azure Managed Redis.

Componentes

AKS es una plataforma de Kubernetes administrada que ofrece clústeres administrados para implementar y escalar aplicaciones en contenedores. Cuando se usa AKS, Azure administra el servidor de API de Kubernetes. El operador de clúster puede acceder a los nodos o grupos de nodos de Kubernetes y administrarlos. Esta arquitectura usa las siguientes características de infraestructura de AKS:
- El Microsoft Entra ID administrado por AKS para el control de acceso basado en rol de Azure (Azure RBAC) es una característica que integra Microsoft Entra ID con AKS para aplicar el control de acceso a través de identidades. En esta arquitectura, garantiza una autenticación y autorización seguras y centralizadas para los usuarios y cargas de trabajo del clúster.
- Azure CNI con tecnología de Cilium es la solución de red recomendada para conectarse directamente a una red virtual de Azure. En esta arquitectura, asigna direcciones IP de la red virtual a los pods a la vez que proporciona funcionalidades de directivas de red integradas y visibilidad del tráfico.
- Advanced Container Networking Services es un conjunto de funcionalidades de red administradas para AKS que proporciona observabilidad de red y seguridad mejorada en el clúster:
  - La observabilidad de la red de contenedores usa herramientas basadas en el filtro de paquetes de Berkeley extendido (eBPF), como Hubble y Retina, para recopilar consultas del sistema de nombres de dominio (DNS), flujos de pod a pod y pod a servicio, caídas de paquetes y otras métricas. Funciona en planos de datos de Cilium y de Linux que no utilizan Cilium. También se integra con el servicio administrado de Azure Monitor para Prometheus y Azure Managed Grafana para la visualización y las alertas. En esta arquitectura, la observabilidad de red de contenedor diagnostica errores de configuración de directivas, latencia o errores de DNS y desequilibrios de tráfico entre microservicios.
  - Container Network Security se aplica a los clústeres que usan Azure CNI con tecnología de Cilium. Aplica recursos de NetworkPolicy de Cilium, incluido el filtrado de salida basado en nombre de dominio completo (FQDN), para implementar la segmentación de red de confianza cero y reducir la sobrecarga operativa. En esta arquitectura, las directivas de FQDN en clúster funcionan con Azure Firewall o Azure NAT Gateway para aplicar la salida con privilegios mínimos al tiempo que simplifican el mantenimiento de directivas.
- El complemento de Azure Policy para AKS es una extensión integrada que aporta controles de gobernanza y cumplimiento directamente a los clústeres de AKS. Aplica reglas de gobernanza en los recursos de AKS mediante Azure Policy. En esta arquitectura, aplica el cumplimiento mediante la validación de configuraciones y la restricción de implementaciones no autorizadas.
- La entrada NGINX administrada con el complemento de enrutamiento de aplicaciones es una característica de AKS que le ayuda a exponer las aplicaciones a Internet mediante el tráfico HTTP o HTTPS. Proporciona un controlador de entrada NGINX preconfigurado para AKS. En esta arquitectura, gestiona el enrutamiento del tráfico hacia los servicios y facilita la visibilidad de los pods al Gateway de Aplicación.
- La separación del grupo de nodos de usuario y del sistema es una práctica arquitectónica que divide los nodos de clúster en dos tipos distintos de grupos de nodos y aísla los componentes de infraestructura de AKS de las cargas de trabajo de aplicación. En esta arquitectura, la seguridad y la eficiencia de los recursos se mejoran dedicando grupos de nodos a roles operativos específicos.
- El identificador de carga de trabajo es una manera segura y escalable de que las cargas de trabajo de Kubernetes accedan a los recursos de Azure mediante el identificador de Entra de Microsoft sin necesidad de secretos ni credenciales almacenadas en el clúster. El identificador de carga de trabajo permite que las cargas de trabajo de AKS accedan de forma segura a los recursos de Azure mediante la identidad federada. En esta arquitectura, elimina la necesidad de secretos y mejora la posición de seguridad mediante el acceso basado en identidades.
Application Gateway es un servicio administrado por Azure que proporciona funcionalidades de equilibrio de carga de nivel 7 y firewall de aplicaciones web (WAF). En esta arquitectura, expone el microservicio de ingesta como un punto de conexión público y equilibra el tráfico web entrante a la aplicación.
Azure Firewall es un servicio administrado por Azure que ofrece seguridad de red nativa de nube inteligente y protección contra amenazas. En esta arquitectura, controla las comunicaciones salientes de los microservicios a recursos externos, lo que solo permite FQDN aprobados como tráfico de salida.
Azure Private Link es un servicio administrado por Azure que permite la conectividad privada a las ofertas de plataforma como servicio (PaaS) de Azure a través de la red troncal de Microsoft. En esta arquitectura, asigna direcciones IP privadas para acceder a Azure Container Registry y Azure Key Vault desde grupos de nodos de AKS a través de puntos de conexión privados.
Azure Virtual Network es un servicio administrado por Azure que proporciona entornos aislados y seguros para ejecutar aplicaciones y máquinas virtuales (VM). En esta arquitectura, usa una topología en estrella tipo hub-spoke emparejada. La red de concentrador hospeda Azure Firewall y Azure Bastion. La red radial contiene subredes del grupo de nodos de usuario y del sistema de AKS, junto con la subred de Application Gateway.

Almacenamiento externo y otros componentes

Azure Managed Redis es un servicio administrado por Azure que proporciona un almacén de datos en memoria de alto rendimiento para el almacenamiento en caché, el almacenamiento de sesión y el acceso a datos en tiempo real. Además del almacenamiento en caché tradicional, incluye compatibilidad con tipos de datos avanzados y características como el almacenamiento de documentos JSON, la búsqueda de texto completo y el procesamiento de secuencias. En esta arquitectura, el microservicio de entrega usa Azure Managed Redis como almacén de estado y caché lateral para mejorar la velocidad y la capacidad de respuesta durante el tráfico pesado.
Container Registry es un servicio administrado por Azure que almacena imágenes de contenedor privadas para la implementación en AKS. En esta arquitectura, almacena las imágenes de contenedores para microservicios, y AKS realiza la autenticación mediante su identidad administrada de Microsoft Entra. También puede usar otros registros, como Docker Hub.
Azure Cosmos DB es un servicio de base de datos noSQL, relacional y vectorial distribuido globalmente y administrado por Azure. En esta arquitectura, Azure Cosmos DB y Azure DocumentDB sirven como almacenes de datos externos para cada microservicio.
Key Vault es un servicio administrado por Azure que almacena y administra de forma segura secretos, claves y certificados. En esta arquitectura, Key Vault almacena las credenciales que usan los microservicios para acceder a Azure Cosmos DB y Azure Managed Redis.
Azure Monitor es una plataforma de observabilidad administrada por Azure que recopila métricas, registros y telemetría entre servicios. En esta arquitectura, habilita la supervisión de la aplicación, las alertas, los paneles y el análisis de la causa principal de los errores en AKS y los servicios integrados.

La observabilidad de la red de contenedores para servicios avanzados de redes de contenedores usa Hubble para la visibilidad del flujo y Retina para la telemetría de red curada. Estas herramientas se integran con plataformas de observabilidad gestionadas, como Azure Monitor, servicio gestionado para Prometheus y Azure Managed Grafana, para la solución de problemas y la elaboración de informes sobre los objetivos de nivel de servicio (SLO).
Service Bus es un servicio de mensajería administrado por Azure que admite la comunicación confiable y asincrónica entre aplicaciones distribuidas. En esta arquitectura, Service Bus actúa como la capa de cola entre los microservicios de ingesta y flujo de trabajo, lo que permite el intercambio de mensajes desacoplado y escalable.

Otras operaciones admiten componentes del sistema

Flux es una solución de entrega continua extensible, de código abierto y compatible con Azure para Kubernetes que habilita GitOps en AKS. En esta arquitectura, Flux automatiza las implementaciones mediante la sincronización de archivos de manifiesto de aplicación desde un repositorio de Git, lo que garantiza una entrega coherente y declarativa de microservicios al clúster de AKS.
Helm es un administrador de paquetes nativo de Kubernetes que agrupa objetos de Kubernetes en una sola unidad para publicar, implementar, versionar y actualizar. En esta arquitectura, Helm se usa para empaquetar e implementar microservicios en el clúster de AKS.
Proveedor del controlador Key Vault Secrets Store CSI es un controlador integrado de Azure que permite a los clústeres de AKS montar secretos desde Key Vault utilizando volúmenes CSI. En esta arquitectura, los secretos se montan directamente en contenedores de microservicios, lo que permite la recuperación segura de credenciales para Azure Cosmos DB y Azure Managed Redis.

Alternativas

En lugar de usar un complemento de enrutamiento de aplicaciones, puede usar alternativas como Application Gateway para contenedores y el 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. Flux y ArgoCD están disponibles como extensiones de clúster.

En lugar de almacenar credenciales para Azure Cosmos DB y Azure Managed 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 Managed Redis también admite la autenticación mediante identidades administradas.

Detalles del escenario

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. El cliente puede realizar un seguimiento de la ubicación del dron y ver una hora estimada de llegada actualizada continuamente mientras la entrega está en curso.

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 DNS privadas 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.

Configure 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. Configure todos los microservicios para usar nombres de dominio personalizados y certificados SSL, que protege la comunicación entre microservicios dentro del clúster de AKS.

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.

Redes y directiva de red

Use Azure CNI con tecnología de Cilium. El plano de datos eBPF tiene un rendimiento de enrutamiento adecuado y admite cualquier clúster de tamaño. Cilium aplica de forma nativa NetworkPolicy de Kubernetes y proporciona una observabilidad de tráfico enriquecida. Para más información, consulte Configuración de Azure CNI con tecnología de Cilium en AKS.

Importante

Si necesita nodos de Windows en la arquitectura de microservicios, revise la limitación actual de Solo Linux de Cilium y planee adecuadamente los grupos de sistemas operativos mixtos. Para más información, consulte Limitaciones de Azure CNI con tecnología de Cilium.

Para necesidades específicas de administración de direcciones IP, Azure CNI impulsado por Cilium admite tanto modelos de IP de pod enrutados mediante la red virtual como de superposición. Para más información, consulte Azure CNI con tecnología de Cilium.

Directivas de red de cero confianza

Las directivas de red especifican cómo se comunican los pods de AKS 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. Defina y aplique Kubernetes NetworkPolicy (implementada por Advanced Container Networking Services/Cilium) para segmentar el tráfico entre microservicios y restringir el tráfico de salida solo a los FQDN permitidos.

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: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

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 de Cilium 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: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - 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. Para conocer los procedimientos recomendados para las directivas de red en AKS, consulte Uso de directivas de red en AKS.

Cuando se usa Azure CNI con tecnología de Cilium, Cilium aplica Kubernetes NetworkPolicy. Para conocer los requisitos especializados, Azure proporciona otros motores de directivas de red, como Azure Network Policy Manager y Calico. Se recomienda Cilium como motor de directivas de red predeterminado.

Cuotas de recursos

Los administradores usan cuotas de recursos para reservar y limitar 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 unidades de procesamiento central (CPU), unidades de procesamiento de memoria y gráficos (GPU)
Recursos de almacenamiento, incluido el número de volúmenes o la cantidad de espacio en disco para una clase de almacenamiento específica
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 obtener más información sobre las cuotas de recursos, consulte los siguientes artículos:

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, la ENTIDAD de certificación 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 del clúster:

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 la ENTIDAD de certificación:

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.

La ENTIDAD de certificación y la 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 CA 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, el 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 impulsado por eventos de Kubernetes

El complemento Kubernetes Event-Driven Autoscaling (KEDA) permite el escalado automático basado en eventos para escalar tus microservicios y satisfacer la demanda de manera 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 escenario 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 inician correctamente y que están en buen estado reciben 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 sirve solicitudes HTTP se cuelga, el contenedor no se bloquea, pero deja de servir las solicitudes. El sondeo de ejecución HTTP deja de responder, que alerta a Kubernetes para reiniciar el pod.

A veces, es posible que un pod no esté listo para recibir tráfico, aunque el pod se inicie correctamente. Por ejemplo, la aplicación que se ejecuta en el contenedor podría realizar 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

La supervisión es esencial en una arquitectura de microservicios para detectar anomalías, diagnosticar problemas y comprender las dependencias del servicio. Application Insights, parte de Azure Monitor, proporciona supervisión del rendimiento de aplicaciones (APM) para aplicaciones escritas en .NET, Node.js, Java y muchos otros lenguajes. Azure proporciona varias funcionalidades integradas para la visibilidad de un extremo a otro:

El servicio administrado de Azure Monitor para Prometheus recopila y alertas sobre las métricas de infraestructura y carga de trabajo.
La función Datos en tiempo real de Container Insights supervisa los clústeres, nodos y contenedores de AKS para la salud y el uso de recursos.
Azure Managed Grafana visualiza métricas y paneles para clústeres y microservicios.

La observabilidad avanzada de Container Networking Services complementa estas herramientas al proporcionar visibilidad profunda basada en eBPF en el comportamiento de red de los clústeres de AKS. Captura la latencia de DNS, los flujos de pod a pod y servicio, las caídas de directivas de red y las métricas de protocolo de nivel 7, como los códigos de estado HTTP y los tiempos de respuesta. Esta telemetría se integra con el servicio administrado de Azure Monitor para Prometheus para métricas y Azure Managed Grafana para paneles. El plano de datos de Cilium eBPF proporciona visibilidad y solución de problemas de nivel de flujo. Cuando se combina con Advanced Container Networking Services y Azure Monitor, esta funcionalidad ofrece observabilidad de red de un extremo a otro. Esta integración permite detectar cuellos de botella en la red, configuraciones erróneas de políticas y problemas de comunicación que los APM tradicionales podrían no detectar.

Sugerencia

Combine datos de red avanzados de Container Networking Services con telemetría de Azure Monitor para obtener una vista completa del estado de la aplicación y de la infraestructura. También puede integrar Application Insights con AKS sin realizar cambios en el código para correlacionar el rendimiento de la aplicación con el clúster y la información de red.

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 microservicio se le debe asignar una identidad de carga de trabajo única para facilitar las asignaciones de RBAC de Azure con privilegios mínimos. Asigne solo identidades a servicios que los 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 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. Proporciona administración centralizada, control de acceso, cifrado en reposo y auditoría para 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.

Advanced Container Networking Services proporciona segmentación de red en clúster y controles de confianza cero para clústeres de AKS. Use directivas de red de Cilium en Azure CNI con tecnología de Cilium para implementar la segmentación de nivel 3 y 4 en el clúster. La seguridad avanzada de Container Networking Services amplía esta base agregando funcionalidades avanzadas:

Filtrado de salida basado en FQDN para restringir el tráfico saliente a dominios aprobados.
Directivas con reconocimiento de nivel 7 para protocolos como HTTP y llamada a procedimiento remoto gRPC (gRPC) para validar y controlar la comunicación a nivel de aplicación.
Cifrado de WireGuard para proteger el tráfico de pod a pod y proteger los datos confidenciales en tránsito.

Estas características funcionan junto con defensas perimetrales, como grupos de seguridad de red (NSG) y Azure Firewall para ofrecer un enfoque de seguridad en capas que aplica el control de tráfico desde el clúster.
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.

Plano de datos de red y motores de directivas

Cilium en AKS se admite actualmente para los nodos Linux y aplica NetworkPolicy en el plano de control de datos. Tenga en cuenta las advertencias de políticas, como el uso de ipBlock con direcciones IP de nodo y direcciones IP de pod, y que los pods con red de host utilizan la identidad del host. Las políticas de nivel de pod no se aplican. Alinee las versiones de AKS y Cilium con la matriz de versiones admitida. Para más información, consulte Limitaciones de Azure CNI con tecnología de Cilium.

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 mediante una canalización de implementación automatizada, como los flujos de trabajo de GitHub Actions.
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. Si los usuarios y un escalador automático intentan cambiar el número de réplicas, puede producirse un comportamiento inesperado. Cuando el 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 desalojar con frecuencia cuando la aplicación se escala verticalmente o horizontalmente. Para mitigar estos efectos, se recomienda llevar a cabo las acciones siguientes:
- 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 de salida desde el microservicio, considere la posibilidad de usar puertas de enlace de traducción de direcciones de red (NAT) para evitar el agotamiento de puertos de traducción de direcciones de red de origen (SNAT).
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, consulte Adición de grupos de nodos que tienen 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 Azure CNI con redes de superposición para conservar el espacio de direcciones de red.

Pasos siguientes

Comentarios

¿Le ha resultado útil esta página?