Editar

Compartir a través de

Arquitectura de microservicios en Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

Esta arquitectura de referencia muestra una aplicación de microservicios implementada en Azure Kubernetes Service (AKS). Describe una configuración básica de AKS que puede ser el punto de partida para la mayoría de las implementaciones. En este artículo se da por supuesto un conocimiento básico de Kubernetes. El artículo se centra principalmente en la infraestructura y las consideraciones sobre DevOps de la ejecución de una arquitectura de microservicios en AKS. Para obtener instrucciones sobre cómo diseñar microservicios, consulte Creación de microservicios en Azure.

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

Architecture

Diagrama que muestra la arquitectura de referencia de AKS.

Descargue un archivo Visio de esta arquitectura.

Si prefiere ver un ejemplo de microservicios más avanzado que se basa en la arquitectura de línea de base de AKS, consulte Arquitectura de microservicios avanzada de Azure Kubernetes Service (AKS).

Flujo de trabajo

La arquitectura consta de los siguientes componentes:

Azure Kubernetes Service (AKS). AKS es un clúster de Kubernetes administrado hospedado en la nube de Azure. Azure administra el servicio de API de Kubernetes, y usted solo necesita administrar los nodos del agente.

Red virtual. De manera predeterminada, AKS crea una red virtual a la que se conectan los nodos del agente. Para escenarios más avanzados, puede crear primero la red virtual, lo que le permite controlar cosas como la configuración de las subredes, la conectividad local y el direccionamiento IP. Para más información, consulte Configuración de redes avanzadas en Azure Kubernetes Service (AKS).

Entrada. Un servidor de entrada expone las rutas HTTP(S) a los servicios dentro del clúster. Para más información, consulte la sección Puerta de enlace de API a continuación.

Azure Load Balancer. Después de crear un clúster de AKS; este está listo para usar el equilibrador de carga. Luego, una vez que se ha implementado el servicio NGINX, el equilibrador de carga se configurará con una nueva dirección IP pública que se pondrá al frente del controlador de entrada. De este modo, el equilibrador de carga enruta el tráfico de Internet a la entrada.

Almacenes de datos externos. Normalmente, los microservicios no tienen estado y escriben el estado en almacenes de datos externos, como Azure SQL Database o Azure Cosmos DB.

Microsoft Entra ID. AKS usa una identidad de Microsoft Entra para crear y administrar otros recursos de Azure, como los equilibradores de carga de Azure. Microsoft Entra ID también se recomienda para la autenticación de usuarios en aplicaciones cliente.

Azure Container Registry. Utilice Container Registry para almacenar imágenes de Docker privadas, que se implementan en el clúster. AKS puede autenticarse con Container Registry mediante su identidad de Microsoft Entra. AKS no requiere Azure Container Registry. Puede usar otros registros de contenedor, como Docker Hub. Tan solo asegúrese de que el registro de contenedor coincida o supere el acuerdo de nivel de servicio (SLA) de la carga de trabajo.

Azure Pipelines. Azure Pipelines forma parte de Azure DevOps Services y ejecuta compilaciones, pruebas e implementaciones automatizadas. También puede usar soluciones de CI/CD de terceros como Jenkins.

Helm. Helm es un administrador de paquetes para Kubernetes, una manera de agrupar y generalizar objetos de Kubernetes en una sola unidad que se puede publicar, implementar, versionar y actualizar.

Azure Monitor. Azure Monitor recopila y almacena métricas y registros, telemetría de aplicaciones y métricas de plataformas para los servicios de Azure. Use estos datos para supervisar la aplicación, configurar alertas y paneles, y realizar el análisis de causa principal de los errores. Azure Monitor se integra en AKS para recopilar métricas de controladores, nodos y contenedores.

Consideraciones

Diseño

Esta arquitectura de referencia se centra en las arquitecturas de microservicios, aunque muchos de los procedimientos recomendados se aplican a otras cargas de trabajo que se ejecutan en AKS.

Microservicios

Un microservicio es una unidad de código de acoplamiento flexible que se puede implementar de forma independiente. Los microservicios normalmente se comunican mediante API bien definidas y son detectables por algún tipo de detección de servicios. El servicio siempre debe ser accesible, incluso cuando los pods se mueven. El objeto de Kubernetes Service es una manera natural para modelar microservicios en Kubernetes.

Puerta de enlace de API

Las puertas de enlace de API son un patrón de diseño de microservicios general. Una puerta de enlace de API se encuentra entre los clientes externos y los microservicios. Actúa como un proxy inverso, enrutando las solicitudes de los clientes a los microservicios. También puede cumplir diversas tareas transversales como la autenticación, la terminación SSL y la limitación de velocidad. Para obtener más información, consulte:

En Kubernetes, la funcionalidad de una puerta de enlace de API se controla principalmente mediante un controlador de entrada. Las consideraciones se describen en la sección Entrada.

Almacenamiento de datos

En una arquitectura de microservicios, los servicios no deben compartir soluciones de almacenamiento de datos. Cada servicio debe administrar su propio conjunto de datos para evitar dependencias ocultas entre servicios. La separación de los datos ayuda a evitar el acoplamiento involuntario entre servicios, lo que puede suceder cuando los servicios comparten los mismos esquemas de datos subyacentes. Además, cuando los servicios administran sus propios almacenes de datos, pueden usar el almacén de datos adecuado para sus requisitos particulares.

Para más información, consulte Diseño de microservicios: consideraciones sobre los datos.

Evite almacenar datos permanentes en el almacenamiento del clúster local, ya que esto ata los datos al nodo. En su lugar, use un servicio externo, como Azure SQL Database o Azure Cosmos DB. Otra opción es montar un volumen de datos persistente en una solución mediante Azure Disks o Azure Files.

Para obtener más información, consulte Opciones de almacenamiento de aplicaciones en Azure Kubernetes Service.

Objeto de servicio

El objeto de Kubernetes Service proporciona un conjunto de funcionalidades que coinciden con los requisitos de detección del servicio de los microservicios:

  • Dirección IP. El objeto del servicio proporciona una dirección IP interna estática para un grupo de pods (conjunto de réplicas). A medida que los pods se crean o se mueven, el servicio siempre está accesible en esta dirección IP interna.

  • Equilibrio de carga. La carga del tráfico enviado a la dirección IP del servicio se equilibra en los pods.

  • Detección de servicios. El servicio DNS de Kubernetes asigna entradas DNS internas a los servicios. Esto significa que la puerta de enlace de API puede llamar a un servicio de back-end con el nombre DNS. Se puede usar el mismo mecanismo para la comunicación de servicio a servicio. Las entradas DNS están organizadas por espacio de nombres, por lo que si los espacios de nombres se corresponden con contextos limitados, el nombre DNS de un servicio se asignará de forma natural al dominio de aplicación.

El diagrama siguiente muestra la relación conceptual entre servicios y pods. La asignación real a los puertos y las direcciones IP del punto de conexión se realiza mediante kube-proxy, el proxy de red de Kubernetes.

Diagrama que muestra servicios y pods.

Entrada

En Kubernetes, el controlador de entrada podría implementar el patrón de puerta de enlace de API. En ese caso, la entrada y el controlador de entrada funcionan en conjunto para proporcionar estas características:

  • Enrute las solicitudes de cliente a los servicios de back-end correctos. Este enrutamiento 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 de los servicios de back-end, como la terminación SSL, la autenticación, las restricciones de IP o la limitación de velocidad del cliente.

La entrada abstrae las opciones de configuración de un servidor proxy. También necesita un controlador de entrada, que proporciona la implementación subyacente de la entrada. Hay controladores de entrada para Nginx, HAProxy, Traefik y Azure Application Gateway, entre otros.

El recurso de entrada se puede cumplimentar con diferentes tecnologías. Para trabajar en conjunto, deben implementarse como controladores de entrada dentro del clúster. Este funcionará como enrutador perimetral o proxy inverso. Un servidor proxy inverso es un posible cuello de botella o un único punto de error, por lo que siempre debe implementar al menos dos réplicas para la alta disponibilidad.

A menudo, la configuración del servidor proxy requiere archivos complejos, lo que puede ser difícil de optimizar si no es un experto. Por lo tanto, el controlador de entrada proporciona una abstracción adecuada. El controlador de entrada también tiene acceso a la API de Kubernetes, por lo que puede tomar decisiones inteligentes sobre enrutamiento y equilibrio de carga. Por ejemplo, el controlador de entrada Nginx omite al proxy de red kube-proxy.

Por otro lado, si necesita control absoluto sobre la configuración, puede omitir esta abstracción y configurar manualmente el servidor proxy. Para más información, consulte Implementación de Nginx o HAProxy en Kubernetes.

Nota

En el caso de AKS, también puede usar Azure Application Gateway mediante el controlador de entrada de Application Gateway (AGIC). Azure Application Gateway puede realizar el enrutamiento de nivel 7 y la terminación SSL. También tiene compatibilidad integrada con Web Application Firewall. Si el clúster de AKS usa redes de CNI, Application Gateway se puede implementar en una subred de la red virtual del clúster, o se puede implementar en una red virtual diferente de la red virtual de AKS. Sin embargo, las dos redes virtuales deben estar emparejadas. Además, AGIC admite el complemento de redes de Kubenet. Al usar el modo de Kubenet, el controlador de entrada tiene que administrar una tabla de enrutamiento en la subred del Application Gateway para dirigir el tráfico a las direcciones IP de los pods. Para obtener más información, consulte Configuración de redes entre Application Gateway y AKS.

Para obtener información sobre los servicios de equilibrio de cargas en Azure, consulte Información general sobre las opciones de equilibrio de carga en Azure.

Cifrado TLS/SSL

En las implementaciones comunes, el controlador de entrada se usa para la terminación SSL. Por lo tanto, como parte de la implementación del controlador de entrada, debe crear un certificado TLS. Los certificados autofirmados son solo para fines de desarrollo/pruebas. Para más información, consulte Creación de un controlador de entrada HTTPS y uso de sus propios certificados TLS en Azure Kubernetes Service (AKS).

Para cargas de trabajo de producción, obtenga certificados firmados de entidades de certificación (CA) de confianza. Para obtener información sobre cómo generar y configurar los certificados de Let's Encrypt, consulte Creación de un controlador de entrada con una dirección IP pública estática en Azure Kubernetes Service (AKS).

Es posible que también deba rotar los certificados según las directivas de la organización. Para obtener información, consulte Rotación de certificados en Azure Kubernetes Service (AKS).

Espacios de nombres

Use espacios de nombres para organizar los servicios dentro del clúster. Todos los objetos de un clúster de Kubernetes pertenecen a un espacio de nombres. De forma predeterminada, cuando se crea un nuevo objeto, este se coloca en el espacio de nombres default. Pero es una buena práctica crear espacios de nombres más descriptivos para ayudar a organizar los recursos del clúster.

En primer lugar, los espacios de nombres ayudar a evitar colisiones de nomenclatura. Cuando varios equipos implementan microservicios en el mismo clúster, posiblemente con cientos de microservicios, se hace difícil de administrar si todos se incluyen en el mismo espacio de nombres. Además, los espacios de nombres permiten:

  • Aplicar restricciones de recursos a un espacio de nombres para que el conjunto total de pods asignados a ese espacio de nombres no pueda superar la cuota de recursos del espacio de nombres.

  • Aplicar directivas en el nivel de espacio de nombres, incluidas las directivas de RBAC y seguridad.

Para una arquitectura de microservicios, considere la organización de los microservicios en contextos limitados y la creación de espacios de nombres para cada contexto limitado. Por ejemplo, todos los microservicios relacionados con el contexto limitado "Pedidos" podrían ir en el mismo espacio de nombres. Como alternativa, cree un espacio de nombres para cada equipo de desarrollo.

Coloque los servicios auxiliares en su propio espacio de nombres independiente. Por ejemplo, podría implementar Elasticsearch o Prometheus para la supervisión de clústeres o Tiller para Helm.

Sondeos de estado

Kubernetes define dos tipos de sondeo de mantenimiento que puede exponer un pod:

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

  • Sondeo de ejecución: indica a Kubernetes si se debería quitar un pod e iniciar una nueva instancia.

Al pensar en los sondeos, es útil recordar cómo funciona un servicio en Kubernetes. Un servicio tiene un selector de etiqueta que coincide con un conjunto de pods (cero o más). Kubernetes equilibra el tráfico a los pods que coinciden con el selector. Solo los pods que se iniciaron correctamente y que están en buen estado recibirán tráfico. Si se bloquea un contenedor, Kubernetes elimina el pod y programa un reemplazo.

En ocasiones, un pod puede no estar listo para recibir tráfico aunque el pod se inició correctamente. Por ejemplo, puede haber tareas de inicialización, en las que la aplicación que se ejecuta en el contenedor carga elementos en la memoria o lee datos de configuración. Para indicar que un pod está correcto pero no está listo para recibir tráfico, defina un sondeo de preparación.

Los sondeos de ejecución controlan el caso de un pod que sigue en ejecución, pero está en mal estado y se debe reciclar. Por ejemplo, suponga que un contenedor da servicio a solicitudes HTTP, pero se bloquea por algún motivo. El contenedor no se bloquea, pero ha dejado de servir solicitudes. Si define un sondeo de ejecución HTTP, el sondeo dejará de responder y esto informa a Kubernetes para reiniciar el pod.

Estas son algunas consideraciones al diseñar los sondeos:

  • Si el código tiene un tiempo de inicio elevado, hay un riesgo de que un sondeo de ejecución notifique un error antes de que finalice el inicio. Para evitar este error de sondeo, use el valor initialDelaySeconds, que retrasa el inicio del sondeo.

  • Un sondeo de ejecución no ayuda a menos que reiniciar el pod lo restaure a un estado correcto. Puede usar un sondeo de ejecución para mitigar bloqueos inesperados o fugas de memoria, pero no hay ningún interés en reiniciar un pod que va a producir inmediatamente un nuevo error.

  • A veces se usan sondeos de preparación para comprobar los servicios dependientes. Por ejemplo, si un pod tiene una dependencia en una base de datos, el sondeo podría comprobar la conexión de base de datos. Sin embargo, este enfoque puede crear problemas inesperados. Un servicio externo podría no estar disponible temporalmente por algún motivo. Esto hará que el sondeo de preparación genere un error para todos los pods del servicio, causando la eliminación de todos ellos del equilibrio de carga y así crear errores en cascada ascendentes. Un enfoque mejor consiste en implementar un control de reintentos en el servicio, para que el servicio se pueda recuperar correctamente de errores transitorios.

Restricciones de recursos

La contención de recursos puede afectar a la disponibilidad de un servicio. Defina restricciones de recursos para los contenedores, para que un único contenedor no pueda sobrecargar los recursos de clúster (memoria y CPU). Para recursos que no están en contenedores, como los subprocesos o las conexiones de red, considere el uso del patrón Bulkhead para aislar los recursos.

Utilice cuotas de recursos para limitar los recursos totales permitidos para un espacio de nombres. De este modo, el front-end no puede dejar sin recursos a los servicios de back-end o viceversa.

Seguridad

Control de acceso basado en roles (RBAC)

Kubernetes y Azure tienen mecanismos de control de acceso basado en rol (RBAC):

  • El control de acceso basado en rol de Azure controla el acceso a los recursos de Azure, incluida la capacidad de crear nuevos recursos de Azure. Los permisos se pueden asignar a usuarios, grupos o entidades de servicio. (Una entidad de servicio es una identidad de seguridad utilizada por las aplicaciones).

  • El control de acceso basado en rol de Kubernetes controla los permisos para la API de Kubernetes. Por ejemplo, la creación de pods y la enumeración de pods son acciones que se pueden autorizar (o denegar) a un usuario mediante RBAC de Kubernetes. Para asignar permisos de Kubernetes a los usuarios, puede crear roles y enlaces de rol:

    • Un rol es un conjunto de permisos que se aplican dentro de un espacio de nombres. Los permisos se definen como verbos (obtener, actualizar, crear, eliminar) en los recursos (pods, implementaciones, etc).

    • Un enlace de rol asigna usuarios o grupos a un rol.

    • También hay un objeto ClusterRole, que es similar a Role, pero se aplica a todo el clúster en todos los espacios de nombres. Para asignar usuarios o grupos a un objeto ClusterRole, cree un objeto ClusterRoleBinding.

AKS integra estos dos mecanismos de RBAC. Al crear un clúster de AKS, puede configurarlo para que use Microsoft Entra ID para la autenticación de usuario. Para obtener detalles sobre cómo configurar esto, consulte Integrar Microsoft Entra ID con Azure Kubernetes Service.

Una vez configurado, un usuario que quiera acceder a la API de Kubernetes (por ejemplo, a través de kubectl) debe iniciar sesión con sus credenciales de Microsoft Entra.

De forma predeterminada, un usuario de Microsoft Entra no tiene acceso al clúster. Para otorgar acceso, el administrador del clúster crea RoleBindings que hacen referencia a usuarios o grupos de Microsoft Entra. Si un usuario no tiene permisos para una operación determinada, se producirá un error.

Si los usuarios no tienen acceso de forma predeterminada, ¿cómo tiene permisos el administrador del clúster para crear los enlaces de rol en primer lugar? Un clúster de AKS realmente tiene dos tipos de credenciales para llamar al servidor de API de Kubernetes: usuario del clúster y administrador del clúster. Las credenciales de administrador del clúster otorgan acceso completo al clúster. El comando az aks get-credentials --admin de la CLI de Azure descarga las credenciales de administrador del clúster y las guarda en el archivo kubeconfig. El administrador del clúster puede utilizar este archivo kubeconfig para crear roles y enlaces de rol.

En lugar de administrar objetos Role y RoleBinding de clústeres de Kubernetes de forma nativa en Kubernetes, se prefiere el uso de la autorización de Azure RBAC para Kubernetes. Esto permite la administración y control de acceso unificados en los recursos de Azure, AKS y Kubernetes. Estas asignaciones de roles de Azure RBAC pueden tener como destino el clúster o los espacios de nombres dentro del clúster para un control de acceso más específico. Azure RBAC admite un conjunto limitado de permisos predeterminados, y pueden combinarse con el mecanismo nativo de Kubernetes de administración de Role y RoleBindings para admitir patrones de acceso avanzados o más específicos. Cuando esté habilitado, las entidades principales de Microsoft Entra serán validadas exclusivamente por Azure RBAC, mientras que los usuarios habituales de Kubernetes y las cuentas de servicio serán validadas exclusivamente por Kubernetes RBAC.

Dado que las credenciales de administrador del clúster son muy potentes, utilice RBAC de Azure para restringir su acceso:

  • El "rol de administrador del clúster de Azure Kubernetes Service" tiene permisos para descargar las credenciales de administrador del clúster. Solo se debe asignar este rol a los administradores del clúster.

  • El "rol de usuario del clúster de Azure Kubernetes Service" tiene permisos para descargar las credenciales de usuario del clúster. Se puede asignar este rol a los usuarios que no son administradores. Este rol no otorga permisos específicos sobre los recursos de Kubernetes dentro del clúster; simplemente permite que un usuario se conecte al servidor de API.

Al definir las directivas de RBAC (en Kubernetes y Azure), piense en los roles de la organización:

  • ¿Quién puede crear o eliminar un clúster de AKS y descargar las credenciales de administrador?
  • ¿Quién puede administrar un clúster?
  • ¿Quién puede crear o actualizar los recursos de un espacio de nombres?

Es una buena práctica delimitar el ámbito de los permisos de RBAC de Kubernetes por espacio de nombres, mediante roles y enlaces de roles, en lugar de utilizar objetos ClusterRoles y ClusterRoleBindings.

Por último, queda la pregunta de qué permisos tiene el clúster de AKS para crear y administrar los recursos de Azure, como equilibradores de carga, redes o almacenamiento. Para autenticarse con las API de Azure, el clúster usa una entidad de servicio de Microsoft Entra. Si no se especifica una entidad de servicio al crear el clúster, se crea una automáticamente. Sin embargo, es una buena práctica de seguridad crear la entidad de servicio en primer lugar y asignarle permisos de RBAC mínimos. Para más información, consulte Entidades de servicio con Azure Kubernetes Service.

Administración de secretos y credenciales de aplicaciones

Las aplicaciones y los servicios a menudo necesitan credenciales para conectarse a servicios externos, como Azure Storage o SQL Database. El desafío consiste en proteger estas credenciales y que no se filtren.

Para los recursos de Azure, una opción es usar identidades administradas. La idea de una identidad administrada es que una aplicación o servicio tiene una identidad almacenada en Microsoft Entra ID y usa esta identidad para autenticarse con un servicio de Azure. La aplicación o servicio tiene una entidad de servicio creada para él en Microsoft Entra ID y se autentica mediante tokens OAuth 2.0. El código de proceso en ejecución puede obtener de forma transparente el token que se va a usar. De este modo, no es necesario almacenar contraseñas ni cadenas de conexión. Puede usar identidades administradas en AKS mediante la asignación de identidades de Microsoft Entra a pods individuales mediante el id. de carga de trabajo de Microsoft Entra (versión preliminar).

Actualmente, no todos los servicios de Azure admiten la autenticación con identidades administradas. Para obtener una lista, consulte los servicios de Azure que admiten la autenticación de Microsoft Entra.

Incluso con identidades administradas, probablemente necesitará almacenar algunas credenciales u otros secretos de aplicación, ya sea para servicios de Azure que no admiten identidades administradas, servicios de terceros o claves de API. Estas son algunas opciones para almacenar secretos de forma segura:

El uso de un sistema como HashiCorp Vault o Azure Key Vault proporciona varias ventajas, como:

  • Control centralizado de los secretos.
  • Garantías de que todos los secretos se cifran en reposo.
  • Administración de claves centralizada.
  • Control de acceso a los secretos.
  • Auditoría

Seguridad de contenedores y de Orchestrator

Estos son los procedimientos recomendados para proteger pods y contenedores:

  • Supervisión de amenazas: Utilice Microsoft Defender para contenedores (o cualquier funcionalidad de terceros) para supervisar las amenazas. Si hospeda contenedores en una VM, use Microsoft Defender para servidores o una funcionalidad de algún tercero. Además, puede integrar registros desde la solución de supervisión de contenedores de Azure Monitor en Microsoft Sentinel o en una solución SIEM existente.

  • Supervisión de vulnerabilidades: Supervise de manera continua las vulnerabilidades conocidas en imágenes y en contenedores mediante Microsoft Defender for Cloud o una solución de terceros disponible en Azure Marketplace.

  • Automatización de la aplicación de revisiones mediante ACR Tasks, una característica de Azure Container Registry. Una imagen de contenedor se compone de capas. Las capas de base incluyen la imagen del sistema operativo y las imágenes del marco de trabajo de la aplicación, como ASP.NET Core o Node.js. Los desarrolladores de aplicaciones normalmente crean de modo ascendente las imágenes de base y otros desarrolladores del proyecto las mantienen. Cuando se aplican revisiones de modo ascendente a estas imágenes, es importante actualizar, probar y volver a implementar las propias imágenes para no dejar vulnerabilidades de seguridad conocidas. ACR Tasks puede ayudar a automatizar este proceso.

  • Almacene las imágenes en un registro privado de confianza, como Azure Container Registry o Docker Trusted Registry. Use un webhook de validación de admisión en Kubernetes para asegurarse de que los pods solo pueden extraer imágenes desde el registro de confianza.

  • Aplicación del principio de privilegio mínimo

    • No ejecute contenedores en modo con privilegios. El modo con privilegios otorga a un contenedor acceso a todos los dispositivos del host.
    • Cuando sea posible, evite ejecutar procesos como root dentro de los contenedores. Los contenedores no proporcionan un aislamiento completo desde la perspectiva de la seguridad, por lo que es mejor ejecutar un proceso de contenedor como un usuario sin privilegios.

DevOps

Esta arquitectura de referencia proporciona una plantilla de Azure Resource Manager para aprovisionar los recursos en la nube y sus dependencias. Con el uso de las [plantillas de Azure Resource Manager][arm-template] puede usar Azure DevOps Services para aprovisionar distintos entornos en minutos, por ejemplo, para replicar escenarios de producción. Esto permite ahorrar costos y aprovisionar el entorno de pruebas de carga solo cuando es necesario.

Considere la posibilidad de seguir los criterios de aislamiento de la carga de trabajo para estructurar la plantilla de Resource Manager; normalmente, una carga de trabajo se define como una unidad arbitraria de funcionalidad. Por ejemplo, puede tener una plantilla independiente para el clúster y, a continuación, otra para los servicios dependientes. El aislamiento de la carga de trabajo permite a DevOps realizar la integración continua y la entrega continua (CI/CD), ya que el equipo correspondiente de DevOps asocia y administra todas las cargas de trabajo.

Consideraciones de implementación (CI/CD)

Estos son algunos objetivos de un proceso de CI/CD sólido para una arquitectura de microservicios:

  • Cada equipo puede compilar e implementar los servicios que posee de forma independiente, sin afectar ni interrumpir a otros equipos.
  • Antes de implementar en producción una nueva versión de un servicio, se implementa en entornos de desarrollo, pruebas y control de calidad para su validación. Se aplican pruebas de calidad en cada fase.
  • Se puede implementar una nueva versión de un servicio en paralelo con la versión anterior.
  • Hay en vigor directivas de control de acceso suficientes.
  • En el caso de las cargas de trabajo en contenedor, puede confiar en las imágenes de contenedor que se implementan en producción.

Para obtener más información sobre los desafíos, consulte CI/CD para las arquitecturas de microservicios.

Para obtener recomendaciones específicas y procedimientos recomendados, consulte CI/CD para microservicios en Kubernetes.

Optimización de costos

Puede usar la calculadora de precios de Azure para calcular los costos. Se describen otras consideraciones en la sección Costo de Marco de buena arquitectura de Microsoft Azure.

Estos son algunos puntos que se deben tener en cuenta para algunos de los servicios que se usan en esta arquitectura.

Azure Kubernetes Service (AKS)

No hay ningún costo asociado con AKS para la implementación, administración y operaciones del clúster de Kubernetes. Solo deberá pagar por las instancias de máquina virtual, el almacenamiento y los recursos de red que use el clúster de Kubernetes.

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

Azure Load Balancer

Se le cobrará solo el número de reglas de equilibrio de carga y de salida configuradas. Las reglas NAT de entrada son gratuitas. Cuando no hay configurada ninguna regla, la instancia de Standard Load Balancer no se cobra por hora.

Para obtener más información, consulte los precios de Azure Load Balancer.

Azure Pipelines

Esta arquitectura de referencia solo usa Azure Pipelines. Azure ofrece la instancia de Azure Pipelines como servicio individual. Tiene permitido un trabajo gratuito hospedado en Microsoft con 1800 minutos al mes para CI/CD y un trabajo autohospedado con minutos ilimitados cada mes (los trabajos adicionales conllevan cargos). Para más información, consulte Precios de Azure DevOps Services.

Azure Monitor

Por Log Analytics de Azure Monitor, se le cobra por la ingesta y la retención de datos. Para más información, consulte Precios de Azure Monitor.

Implementación de este escenario

Para implementar la solución de referencia de esta arquitectura, siga los pasos del repositorio de GitHub.

Implementación de la referencia de microservicios de AKS

Pasos siguientes