Arquitectura de microservicios en Azure Kubernetes Service (AKS)Microservices architecture on Azure Kubernetes Service (AKS)

Esta arquitectura de referencia muestra una aplicación de microservicios implementada en Azure Kubernetes Service (AKS).This reference architecture shows a microservices application deployed to 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.It describes a basic AKS configuration that can be the starting point for most deployments. En este artículo se da por supuesto un conocimiento básico de Kubernetes.This article assumes basic knowledge of 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.The article focuses mainly on the infrastructure and DevOps considerations of running a microservices architecture on AKS. Para obtener instrucciones sobre cómo diseñar microservicios, consulte crear microservicios en Azure.For guidance on how to design microservices, see Building microservices on Azure.

Logotipo de GitHub está disponible en una implementación de referencia de esta arquitectura GitHub.GitHub logo A reference implementation of this architecture is available on GitHub.

Arquitectura de referencia de AKS

Descargue un archivo Visio de esta arquitectura.Download a Visio file of this architecture.

ArquitecturaArchitecture

La arquitectura consta de los siguientes componentes:The architecture consists of the following components.

Azure Kubernetes Service (AKS).Azure Kubernetes Service (AKS). AKS es un servicio de Azure que implementa un clúster de Kubernetes administrado.AKS is an Azure service that deploys a managed Kubernetes cluster.

Clúster de Kubernetes.Kubernetes cluster. AKS es responsable de implementar el clúster de Kubernetes y de administrar los maestros de Kubernetes.AKS is responsible for deploying the Kubernetes cluster and for managing the Kubernetes masters. Solo debe administrar los nodos de agente.You only manage the agent nodes.

Red virtual.Virtual network. De forma predeterminada, AKS crea una red virtual para implementar en ella los nodos de agente.By default, AKS creates a virtual network to deploy the agent nodes into. Para escenarios más avanzados, puede crear la red virtual en primer lugar, lo que le permite controlar elementos como la configuración de las subredes, la conectividad local y el direccionamiento IP.For more advanced scenarios, you can create the virtual network first, which lets you control things like how the subnets are configured, on-premises connectivity, and IP addressing. Para más información, consulte Configuración de redes avanzadas en Azure Kubernetes Service (AKS).For more information, see Configure advanced networking in Azure Kubernetes Service (AKS).

Entrada.Ingress. Una entrada expone rutas HTTP(S) a servicios dentro del clúster.An ingress exposes HTTP(S) routes to services inside the cluster. Para más información, consulte la sección Puerta de enlace de API a continuación.For more information, see the section API Gateway below.

Azure Load Balancer.Azure Load Balancer. Cuando se implementa el controlador de entrada NGINX, se crea un equilibrador de carga de Azure.An Azure Load Balancer is created when the NGINX ingress controller is deployed. El equilibrador de carga enruta el tráfico de internet a la entrada.The load balancer routes internet traffic to the ingress.

Almacenes de datos externos.External data stores. Los microservicios son normalmente sin estado y escriben el estado en almacenes de datos externos, como Azure SQL Database o Cosmos DB.Microservices are typically stateless and write state to external data stores, such as Azure SQL Database or Cosmos DB.

Azure Active Directory.Azure Active Directory. AKS usa una identidad de Azure Active Directory (Azure AD) para crear y administrar otros recursos de Azure, como los equilibradores de carga de Azure.AKS uses an Azure Active Directory (Azure AD) identity to create and manage other Azure resources such as Azure load balancers. Azure AD también se recomienda para la autenticación de usuario en aplicaciones cliente.Azure AD is also recommended for user authentication in client applications.

Azure Container Registry.Azure Container Registry. Utilice Container Registry para almacenar imágenes de Docker privadas, que se implementan en el clúster.Use Container Registry to store private Docker images, which are deployed to the cluster. AKS se puede autenticar con Container Registry con su identidad de Azure AD.AKS can authenticate with Container Registry using its Azure AD identity. Tenga en cuenta que AKS no requiere Azure Container Registry.Note that AKS does not require Azure Container Registry. Puede usar otros registros de contenedor, como Docker Hub.You can use other container registries, such as Docker Hub.

Azure Pipelines.Azure Pipelines. Pipelines es parte de Azure DevOps Services y ejecuta compilaciones, pruebas e implementaciones automatizadas.Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments. También puede usar soluciones de CI/CD de terceros como Jenkins.You can also use third-party CI/CD solutions such as Jenkins.

Helm.Helm. Helm es un administrador de paquetes para Kubernetes: una manera de agrupar objetos de Kubernetes en una sola unidad que se puede publicar, implementar, versionar y actualizar.Helm is as a package manager for Kubernetes — a way to bundle Kubernetes objects into a single unit that you can publish, deploy, version, and update.

Azure Monitor.Azure Monitor. Azure Monitor recopila y almacena métricas y registros, incluidas las métricas de plataforma para los servicios de Azure de la solución y los datos de telemetría de la aplicación.Azure Monitor collects and stores metrics and logs, including platform metrics for the Azure services in the solution and application telemetry. Use estos datos para supervisar la aplicación, configurar alertas y paneles y realizar el análisis de causa principal de los errores.Use this data to monitor the application, set up alerts and dashboards, and perform root cause analysis of failures. Azure Monitor se integra con AKS para recopilar métricas de controladores, nodos y contenedores, así como los registros de contenedor y los registros del nodo maestro.Azure Monitor integrates with AKS to collect metrics from controllers, nodes, and containers, as well as container logs and master node logs.

Consideraciones de diseñoDesign considerations

Esta arquitectura de referencia se centra en las arquitecturas de microservicios, aunque muchos de los procedimientos recomendados se aplicarán a otras cargas de trabajo que se ejecutan en AKS.This reference architecture is focused on microservices architectures, although many of the recommended practices will apply to other workloads running on AKS.

MicroserviciosMicroservices

El objeto de Kubernetes Service es una manera natural para modelar microservicios en Kubernetes.The Kubernetes Service object is a natural way to model microservices in Kubernetes. Un microservicio es una unidad de código de acoplamiento flexible que se puede implementar de forma independiente.A microservice is a loosely coupled, independently deployable unit of code. Los microservicios normalmente se comunican mediante API bien definidas y son detectables por algún tipo de detección de servicios.Microservices typically communicate through well-defined APIs, and are discoverable through some form of service discovery. El objeto de Kubernetes Service proporciona un conjunto de funcionalidades que coinciden con estos requisitos:The Kubernetes Service object provides a set of capabilities that match these requirements:

  • Dirección IP.IP address. El objeto del servicio proporciona una dirección IP interna estática para un grupo de pods (conjunto de réplicas).The Service object provides a static internal IP address for a group of pods (ReplicaSet). A medida que los pods se crean o se mueven, el servicio siempre está accesible en esta dirección IP interna.As pods are created or moved around, the service is always reachable at this internal IP address.

  • Equilibrio de carga.Load balancing. La carga del tráfico enviado a la dirección IP del servicio se equilibra en los pods.Traffic sent to the service's IP address is load balanced to the pods.

  • Detección de servicios.Service discovery. El servicio DNS de Kubernetes asigna entradas DNS internas a los servicios.Services are assigned internal DNS entries by the Kubernetes DNS service. Esto significa que la puerta de enlace de API puede llamar a un servicio de back-end con el nombre DNS.That means the API gateway can call a backend service using the DNS name. Se puede usar el mismo mecanismo para la comunicación de servicio a servicio.The same mechanism can be used for service-to-service communication. 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.The DNS entries are organized by namespace, so if your namespaces correspond to bounded contexts, then the DNS name for a service will map naturally to the application domain.

El diagrama siguiente muestra la relación conceptual entre servicios y pods.The following diagram show the conceptual relation between services and 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.The actual mapping to endpoint IP addresses and ports is done by kube-proxy, the Kubernetes network proxy.

Servicios y pods

API GatewayAPI Gateway

Una puerta de enlace de API es una puerta de enlace que se encuentra entre los clientes externos y los microservicios.An API gateway is a gateway that sits between external clients and the microservices. Actúa como un proxy inverso, enrutando las solicitudes de los clientes a los microservicios.It acts as a reverse proxy, routing requests from clients to microservices. También puede realizar diversas tareas transversales como la autenticación, la terminación SSL y la limitación de velocidad.It may also perform various cross-cutting tasks such as authentication, SSL termination, and rate limiting.

La funcionalidad proporcionada por una puerta de enlace se puede agrupar como sigue:Functionality provided by a gateway can be grouped as follows:

  • Enrutamiento de puerta de enlace: Enrutamiento de las solicitudes de cliente a los servicios de back-end correctos.Gateway Routing: Routing client requests to the right backend services. Esto proporciona un único punto de conexión para los clientes y ayuda a desacoplar los clientes de los servicios.This provides a single endpoint for clients, and helps to decouple clients from services.

  • Agregación de puerta de enlace: Agregación de varias solicitudes en una sola solicitud, para reducir el intercambio de mensajes entre el cliente y el back-end.Gateway Aggregation: Aggregation of multiple requests into a single request, to reduce chattiness between the client and the backend.

  • Descarga con puertas de enlace.Gateway Offloading. Una puerta de enlace puede descargar de funcionalidades a los servicios de back-end, como la terminación SSL, la autenticación, las listas de direcciones IP permitidas o la limitación de velocidad de cliente.A gateway can offload functionality from the backend services, such as SSL termination, authentication, IP whitelisting, or client rate limiting (throttling).

Las puertas de enlace de API son un patrón de diseño de microservicios general.API gateways are a general microservices design pattern. Se pueden implementar mediante una serie de tecnologías diferentes.They can be implemented using a number of different technologies. Probablemente la implementación más común es implementar un enrutador perimetral o un proxy inverso, como Nginx, HAProxy o Traefik, dentro del clúster.Probably the most common implementation is to deploy an edge router or reverse proxy, such as Nginx, HAProxy, or Traefik, inside the cluster.

Otras opciones incluyen:Other options include:

  • Azure Application Gateway o Azure API-Management, que son servicios administrados que residen fuera del clúster.Azure Application Gateway and/or Azure API-Management, which are both managed services that reside outside of the cluster. Actualmente está en versión beta un controlador de entrada de la puerta de enlace de aplicaciones.An Application Gateway Ingress Controller is currently in beta.

  • Azure Functions Proxies.Azure Functions Proxies. Los servidores proxy pueden modificar las solicitudes y las respuestas y enrutar las solicitudes en función de direcciones URL.Proxies can modify requests and responses and route requests based on URL.

El tipo de recurso Entrada de Kubernetes abstrae las opciones de configuración de un servidor proxy.The Kubernetes Ingress resource type abstracts the configuration settings for a proxy server. Funciona junto con un controlador de entrada, que proporciona la implementación subyacente de la entrada.It works in conjunction with an ingress controller, which provides the underlying implementation of the Ingress. Hay controladores de entrada para Nginx, HAProxy, Traefik y Application Gateway (versión preliminar), entre otros.There are ingress controllers for Nginx, HAProxy, Traefik, and Application Gateway (preview), among others.

El controlador de entrada controla la configuración del servidor proxy.The ingress controller handles configuring the proxy server. A menudo requieren archivos de configuración complejos, que pueden ser difíciles de ajustar si no es un experto, por lo que el controlador de entrada es una buena abstracción.Often these require complex configuration files, which can be hard to tune if you aren't an expert, so the ingress controller is a nice abstraction. Además, el controlador de entrada tiene acceso a la API de Kubernetes, por lo que puede tomar decisiones inteligentes sobre enrutamiento y equilibrio de carga.In addition, the Ingress Controller has access to the Kubernetes API, so it can make intelligent decisions about routing and load balancing. Por ejemplo, el controlador de entrada Nginx omite al proxy de red kube-proxy.For example, the Nginx ingress controller bypasses the kube-proxy network proxy.

Por otro lado, si necesita control absoluto sobre la configuración, puede omitir esta abstracción y configurar manualmente el servidor proxy.On the other hand, if you need complete control over the settings, you may want to bypass this abstraction and configure the proxy server manually.

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 reverse proxy server is a potential bottleneck or single point of failure, so always deploy at least two replicas for high availability.

Almacenamiento de datosData storage

En una arquitectura de microservicios, los servicios no deben compartir el almacenamiento de datos.In a microservices architecture, services should not share data storage. Cada servicio debe ser propietario de sus propios datos privados en un almacenamiento lógico independiente, para evitar dependencias ocultas entre servicios.Each service should own its own private data in a separate logical storage, to avoid hidden dependencies among services. La razón es evitar el acoplamiento involuntario entre servicios, lo que puede suceder cuando los servicios comparten los mismos esquemas de datos subyacentes.The reason is to avoid unintentional coupling between services, which can happen when services share the same underlying data schemas. Además, cuando los servicios administran sus propios almacenes de datos, pueden usar el almacén de datos adecuado para sus requisitos particulares.Also, when services manage their own data stores, they can use the right data store for their particular requirements. Para más información, consulte Diseño de microservicios: consideraciones sobre los datos.For more information, see Designing microservices: Data considerations.

Evite almacenar datos permanentes en el almacenamiento del clúster local, ya que esto ata los datos al nodo.Avoid storing persistent data in local cluster storage, because that ties the data to the node. En su lugar:Instead,

  • Use un servicio externo como Azure SQL Database o Cosmos DB. O bien,Use an external service such as Azure SQL Database or Cosmos DB, or

  • Monte un volumen persistente con discos de Azure o Azure Files.Mount a persistent volume using Azure Disks or Azure Files. Use Azure Files si el mismo volumen debe ser compartido por varios pods.Use Azure Files if the same volume needs to be shared by multiple pods.

Espacios de nombresNamespaces

Use espacios de nombres para organizar los servicios dentro del clúster.Use namespaces to organize services within the cluster. Todos los objetos de un clúster de Kubernetes pertenecen a un espacio de nombres.Every object in a Kubernetes cluster belongs to a namespace. De forma predeterminada, cuando se crea un nuevo objeto, este se coloca en el espacio de nombres default.By default, when you create a new object, it goes into the default namespace. Pero es una buena práctica crear espacios de nombres más descriptivos para ayudar a organizar los recursos del clúster.But it's a good practice to create namespaces that are more descriptive to help organize the resources in the cluster.

En primer lugar, los espacios de nombres ayudar a evitar colisiones de nomenclatura.First, namespaces help prevent naming collisions. 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.When multiple teams deploy microservices into the same cluster, with possibly hundreds of microservices, it gets hard to manage if they all go into the same namespace. Además, los espacios de nombres permiten:In addition, namespaces allow you to:

  • 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.Apply resource constraints to a namespace, so that the total set of pods assigned to that namespace cannot exceed the resource quota of the namespace.

  • Aplicar directivas en el nivel de espacio de nombres, incluidas las directivas de RBAC y seguridad.Apply policies at the namespace level, including RBAC and security policies.

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.For a microservices architecture, considering organizing the microservices into bounded contexts, and creating namespaces for each bounded context. Por ejemplo, todos los microservicios relacionados con el contexto limitado "Pedidos" podrían ir en el mismo espacio de nombres.For example, all microservices related to the "Order Fulfillment" bounded context could go into the same namespace. Como alternativa, cree un espacio de nombres para cada equipo de desarrollo.Alternatively, create a namespace for each development team.

Coloque los servicios auxiliares en su propio espacio de nombres independiente.Place utility services into their own separate namespace. Por ejemplo, podría implementar Elasticsearch o Prometheus para la supervisión de clústeres o Tiller para Helm.For example, you might deploy Elasticsearch or Prometheus for cluster monitoring, or Tiller for Helm.

Consideraciones sobre escalabilidadScalability considerations

Kubernetes admite el escalado horizontal en dos niveles:Kubernetes supports scale-out at two levels:

  • Escalado del número de pods que se asigna a una implementación.Scale the number of pods allocated to a deployment.
  • Escalado de los nodos del clúster, para aumentar los recursos de proceso totales disponibles para el clúster.Scale the nodes in the cluster, to increase the total compute resources available to the cluster.

Aunque puede escalar horizontalmente los pods y los nodos manualmente, se recomienda usar el escalado automático para minimizar la posibilidad de que los servicios se queden con recursos escasos en cargas elevadas.Although you can scale out pods and nodes manually, we recommend using autoscaling, to minimize the chance that services will become resource starved under high load. Una estrategia de escalado automático debe tienen en cuenta los pods y los nodos.An autoscaling strategy must take both pods and nodes into account. Si solo escala horizontalmente los pods, podría alcanzar los límites de recursos de los nodos.If you just scale out the pods, eventually you will reach the resource limits of the nodes.

Escalado automático de podsPod autoscaling

Horizontal Pod Autoscaler (HPA) escala los pods en función de la CPU y la memoria observadas o de métricas personalizadas.The Horizontal Pod Autoscaler (HPA) scales pods based on observed CPU, memory, or custom metrics. Para configurar el escalado horizontal de pods, especifique una métrica de destino (por ejemplo, el 70% de CPU) y el número mínimo y máximo de réplicas.To configure horizontal pod scaling, you specify a target metric (for example, 70% of CPU), and the minimum and maximum number of replicas. Debe realizar una prueba de carga de los servicios para averiguar estas cifras.You should load test your services to derive these numbers.

Un efecto secundario del escalado automático es que los pods podrían crearse o expulsarse con más frecuencia, a medida que se producen eventos de escalado horizontal y reducción horizontal.A side-effect of autoscaling is that pods may be created or evicted more frequently, as scale-out and scale-in events happen. Para mitigar los efectos de esto:To mitigate the effects of this:

  • Use sondeos de preparación para que Kubernetes sepa cuándo está listo un pod nuevo para aceptar tráfico.Use readiness probes to let Kubernetes know when a new pod is ready to accept traffic.
  • Use presupuestos de interrupciones de pods para limitar el número de pods que se puede expulsar de un servicio a la vez.Use pod disruption budgets to limit how many pods can be evicted from a service at a time.

Escalado automático del clústerCluster autoscaling

El escalador automático del clúster escala el número de nodos.The cluster autoscaler scales the number of nodes. Si no se pueden programar pods debido a restricciones de recursos, el escalador automático del clúster aprovisionará más nodos.If pods can't be scheduled because of resource constraints, the cluster autoscaler will provision more nodes. (Nota: La integración entre AKS y el escalador automático del clúster está actualmente en versión preliminar).(Note: Integration between AKS and the cluster autoscaler is currently in preview.)

Mientras que HPA examina los recursos reales consumidos u otras métricas de la ejecución de pods, el escalador automático del clúster aprovisiona nodos para pods que no están programados todavía.Whereas HPA looks at actual resources consumed or other metrics from running pods, the cluster autoscaler is provisioning nodes for pods that aren't scheduled yet. Por lo tanto, examina los recursos solicitados, como se especifica en la especificación de pods de Kubernetes para una implementación.Therefore, it looks at the requested resources, as specified in the Kubernetes pod spec for a deployment. Use pruebas de carga para ajustar estos valores.Use load testing to fine-tune these values.

No se puede cambiar el tamaño de máquina virtual después de crear el clúster, por lo que debe realizar algún planeamiento inicial de capacidad para elegir un tamaño de máquina virtual adecuado para los nodos de agente cuando se crea el clúster.You can't change the VM size after you create the cluster, so you should do some initial capacity planning to choose an appropriate VM size for the agent nodes when you create the cluster.

Consideraciones sobre disponibilidadAvailability considerations

Sondeos de estadoHealth probes

Kubernetes define dos tipos de sondeo de mantenimiento que puede exponer un pod:Kubernetes defines two types of health probe that a pod can expose:

  • Sondeo de preparación: indica a Kubernetes si el pod está listo para aceptar solicitudes.Readiness probe: Tells Kubernetes whether the pod is ready to accept requests.

  • Sondeo de ejecución: indica a Kubernetes si se debería quitar un pod e iniciar una nueva instancia.Liveness probe: Tells Kubernetes whether a pod should be removed and a new instance started.

Al pensar en los sondeos, es útil recordar cómo funciona un servicio en Kubernetes.When thinking about probes, it's useful to recall how a service works in Kubernetes. Un servicio tiene un selector de etiqueta que coincide con un conjunto de pods (cero o más).A service has a label selector that matches a set of (zero or more) pods. Kubernetes equilibra el tráfico a los pods que coinciden con el selector.Kubernetes load balances traffic to the pods that match the selector. Solo los pods que se iniciaron correctamente y que están en buen estado recibirán tráfico.Only pods that started successfully and are healthy receive traffic. Si se bloquea un contenedor, Kubernetes elimina el pod y programa un reemplazo.If a container crashes, Kubernetes kills the pod and schedules a replacement.

En ocasiones, un pod puede no estar listo para recibir tráfico aunque el pod se inició correctamente.Sometimes, a pod may not be ready to receive traffic, even though the pod started successfully. 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.For example, there may be initialization tasks, where the application running in the container loads things into memory or reads configuration data. Para indicar que un pod está correcto pero no está listo para recibir tráfico, defina un sondeo de preparación.To indicate that a pod is healthy but not ready to receive traffic, define a readiness probe.

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.Liveness probes handle the case where a pod is still running, but is unhealthy and should be recycled. Por ejemplo, suponga que un contenedor da servicio a solicitudes HTTP, pero se bloquea por algún motivo.For example, suppose that a container is serving HTTP requests but hangs for some reason. El contenedor no se bloquea, pero ha dejado de servir solicitudes.The container doesn't crash, but it has stopped serving any requests. Si define un sondeo de ejecución HTTP, el sondeo dejará de responder y esto informa a Kubernetes para reiniciar el pod.If you define an HTTP liveness probe, the probe will stop responding and that informs Kubernetes to restart the pod.

Estas son algunas consideraciones al diseñar los sondeos:Here are some considerations when designing probes:

  • 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.If your code has a long startup time, there is a danger that a liveness probe will report failure before the startup completes. Para evitar esto, use la configuración initialDelaySeconds, que retrasa el inicio del sondeo.To prevent this, use the initialDelaySeconds setting, which delays the probe from starting.

  • Un sondeo de ejecución no ayuda a menos que reiniciar el pod lo restaure a un estado correcto.A liveness probe doesn't help unless restarting the pod is likely to restore it to a healthy state. 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.You can use a liveness probe to mitigate against memory leaks or unexpected deadlocks, but there's no point in restarting a pod that's going to immediately fail again.

  • A veces se usan sondeos de preparación para comprobar los servicios dependientes.Sometimes readiness probes are used to check dependent services. Por ejemplo, si un pod tiene una dependencia en una base de datos, el sondeo de ejecución podría comprobar la conexión de base de datos.For example, if a pod has a dependency on a database, the liveness probe might check the database connection. Sin embargo, este enfoque puede crear problemas inesperados.However, this approach can create unexpected problems. Un servicio externo podría no estar disponible temporalmente por algún motivo.An external service might be temporarily unavailable for some reason. 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.That will cause the readiness probe to fail for all the pods in your service, causing all of them to be removed from load balancing, and thus creating cascading failures upstream. Un enfoque mejor consiste en implementar un control de reintentos en el servicio, para que el servicio se pueda recuperar correctamente de errores transitorios.A better approach is to implement retry handling within your service, so that your service can recover correctly from transient failures.

Restricciones de recursosResource constraints

La contención de recursos puede afectar a la disponibilidad de un servicio.Resource contention can affect the availability of a service. Defina restricciones de recursos para los contenedores, para que un único contenedor no pueda sobrecargar los recursos de clúster (memoria y CPU).Define resource constraints for containers, so that a single container cannot overwhelm the cluster resources (memory and 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.For non-container resources, such as threads or network connections, consider using the Bulkhead Pattern to isolate resources.

Utilice cuotas de recursos para limitar los recursos totales permitidos para un espacio de nombres.Use resource quotas to limit the total resources allowed for a namespace. De este modo, el front-end no puede dejar sin recursos a los servicios de back-end o viceversa.That way, the front end can't starve the backend services for resources or vice-versa.

Consideraciones sobre la seguridadSecurity considerations

Control de acceso basado en roles (RBAC)Role based access control (RBAC)

Kubernetes y Azure tienen mecanismos de control de acceso basado en rol (RBAC):Kubernetes and Azure both have mechanisms for role-based access control (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.Azure RBAC controls access to resources in Azure, including the ability to create new Azure resources. Los permisos se pueden asignar a usuarios, grupos o entidades de servicio.Permissions can be assigned to users, groups, or service principals. (Una entidad de servicio es una identidad de seguridad utilizada por las aplicaciones).(A service principal is a security identity used by applications.)

  • El control de acceso basado en rol de Kubernetes controla los permisos para la API de Kubernetes.Kubernetes RBAC controls permissions to the Kubernetes API. 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.For example, creating pods and listing pods are actions that can be authorized (or denied) to a user through RBAC. Para asignar permisos de Kubernetes a los usuarios, puede crear roles y enlaces de rol:To assign Kubernetes permissions to users, you create roles and role bindings:

    • Un rol es un conjunto de permisos que se aplican dentro de un espacio de nombres.A Role is a set of permissions that apply within a namespace. Los permisos se definen como verbos (obtener, actualizar, crear, eliminar) en los recursos (pods, implementaciones, etc).Permissions are defined as verbs (get, update, create, delete) on resources (pods, deployments, etc.).

    • Un enlace de rol asigna usuarios o grupos a un rol.A RoleBinding assigns users or groups to a Role.

    • También hay un objeto ClusterRole, que es similar a un rol, pero se aplica a todo el clúster en todos los espacios de nombres.There is also a ClusterRole object, which is like a Role but applies to the entire cluster, across all namespaces. Para asignar usuarios o grupos a un objeto ClusterRole, cree un objeto ClusterRoleBinding.To assign users or groups to a ClusterRole, create a ClusterRoleBinding.

AKS integra estos dos mecanismos de RBAC.AKS integrates these two RBAC mechanisms. Cuando se crea un clúster de AKS, puede configurarlo para usar Azure AD para la autenticación de usuario.When you create an AKS cluster, you can configure it to use Azure AD for user authentication. Para más información sobre cómo configurar esta opción, consulte Integración de Azure Active Directory con Azure Kubernetes Service.For details on how to set this up, see Integrate Azure Active Directory with Azure Kubernetes Service.

Una vez configurado, un usuario que desea acceder a la API de Kubernetes (por ejemplo, mediante kubectl) debe iniciar sesión con sus credenciales de Azure AD.Once this is configured, a user who wants to access the Kubernetes API (for example, through kubectl) must sign in using their Azure AD credentials.

De forma predeterminada, un usuario de Azure AD no tiene acceso al clúster.By default, an Azure AD user has no access to the cluster. Para conceder acceso, el administrador del clúster crea enlaces de rol que hacen referencia a usuarios o grupos de Azure AD.To grant access, the cluster administrator creates RoleBindings that refer to Azure AD users or groups. Si un usuario no tiene permisos para una operación determinada, se producirá un error.If a user doesn't have permissions for a particular operation, it will fail.

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?If users have no access by default, how does the cluster admin have permission to create the role bindings in the first place? 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.An AKS cluster actually has two types of credentials for calling the Kubernetes API server: cluster user and cluster admin. The cluster admin credentials grant full access to the cluster. 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.The Azure CLI command az aks get-credentials --admin downloads the cluster admin credentials and saves them into your kubeconfig file. El administrador del clúster puede utilizar este archivo kubeconfig para crear roles y enlaces de rol.The cluster administrator can use this kubeconfig to create roles and role bindings.

Dado que las credenciales de administrador del clúster son muy potentes, utilice RBAC de Azure para restringir su acceso:Because the cluster admin credentials are so powerful, use Azure RBAC to restrict access to them:

  • El "rol de administrador del clúster de Azure Kubernetes Service" tiene permisos para descargar las credenciales de administrador del clúster.The "Azure Kubernetes Service Cluster Admin Role" has permission to download the cluster admin credentials. Solo se debe asignar este rol a los administradores del clúster.Only cluster administrators should be assigned to this role.

  • El "rol de usuario del clúster de Azure Kubernetes Service" tiene permisos para descargar las credenciales de usuario del clúster.The "Azure Kubernetes Service Cluster User Role" has permission to download the cluster user credentials. Se puede asignar este rol a los usuarios que no son administradores.Non-admin users can be assigned to this role. Este rol no otorga permisos específicos sobre los recursos de Kubernetes del clúster; simplemente permite que un usuario se conecte al servidor de API.This role does not give any particular permissions on Kubernetes resources inside the cluster — it just allows a user to connect to the API server.

Al definir las directivas de RBAC (en Kubernetes y Azure), piense en los roles de la organización:When you define your RBAC policies (both Kubernetes and Azure), think about the roles in your organization:

  • ¿Quién puede crear o eliminar un clúster de AKS y descargar las credenciales de administrador?Who can create or delete an AKS cluster and download the admin credentials?
  • ¿Quién puede administrar un clúster?Who can administer a cluster?
  • ¿Quién puede crear o actualizar los recursos de un espacio de nombres?Who can create or update resources within a namespace?

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.It's a good practice to scope Kubernetes RBAC permissions by namespace, using Roles and RoleBindings, rather than ClusterRoles and ClusterRoleBindings.

Por último, queda la pregunta de qué permisos tiene el clúster de AKS para crear y administrar recursos de Azure, como equilibradores de carga, redes o almacenamiento.Finally, there is the question of what permissions the AKS cluster has to create and manage Azure resources, such as load balancers, networking, or storage. Para autenticarse a sí mismo con las API de Azure, el clúster usa a una entidad de servicio de Azure AD.To authenticate itself with Azure APIs, the cluster uses an Azure AD service principal. Si no se especifica una entidad de servicio al crear el clúster, se crea una automáticamente.If you don't specify a service principal when you create the cluster, one is created automatically. Sin embargo, es una buena práctica de seguridad crear la entidad de servicio en primer lugar y asignarle permisos de RBAC mínimos.However, it's a good security practice to create the service principal first and assign the minimal RBAC permissions to it. Para más información, consulte Entidades de servicio con Azure Kubernetes Service.For more information, see Service principals with Azure Kubernetes Service.

Administración de secretos y credenciales de aplicacionesSecrets management and application credentials

Las aplicaciones y los servicios a menudo necesitan credenciales para conectarse a servicios externos, como Azure Storage o SQL Database.Applications and services often need credentials that allow them to connect to external services such as Azure Storage or SQL Database. El desafío consiste en proteger estas credenciales y que no se filtren.The challenge is to keep these credentials safe and not leak them.

Para los recursos de Azure, una opción es usar identidades administradas.For Azure resources, one option is to use managed identities. La idea de una identidad administrada es que una aplicación o un servicio tienen una identidad que se almacena en Azure AD y usan esta identidad para autenticarse con un servicio de Azure.The idea of a managed identity is that an application or service has an identity stored in Azure AD, and uses this identity to authenticate with an Azure service. La aplicación o el servicio tienen una entidad de servicio creada en Azure AD y se autentican mediante tokens de OAuth 2.0.The application or service has a Service Principal created for it in Azure AD, and authenticates using OAuth 2.0 tokens. El proceso en ejecución llama a una dirección de host local para obtener el token.The executing process calls a localhost address to get the token. De este modo, no es necesario almacenar contraseñas ni cadenas de conexión.That way, you don't need to store any passwords or connection strings. Puede utilizar identidades administradas en AKS mediante la asignación de identidades a pods individuales, con el proyecto aad-pod-identity.You can use managed identities in AKS by assigning identities to individual pods, using the aad-pod-identity project.

Actualmente, no todos los servicios de Azure admiten la autenticación con identidades administradas.Currently, not all Azure services support authentication using managed identities. Para obtener una lista, consulte Servicios de Azure que admiten la autenticación de Azure AD.For a list, see Azure services that support Azure AD authentication.

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.Even with managed identities, you'll probably need to store some credentials or other application secrets, whether for Azure services that don't support managed identities, third-party services, API keys, and so on. Estas son algunas opciones para almacenar secretos de forma segura:Here are some options for storing secrets securely:

  • Azure Key Vault.Azure Key Vault. En AKS, puede montar uno o más secretos de Key Vault como un volumen.In AKS, you can mount one or more secrets from Key Vault as a volume. El volumen lee los secretos de Key Vault.The volume reads the secrets from Key Vault. El pod, a continuación, puede leer los secretos al igual que en un volumen normal.The pod can then read the secrets just like a regular volume. Para más información, consulte el proyecto Kubernetes-KeyVault-FlexVolume en GitHub.For more information, see the Kubernetes-KeyVault-FlexVolume project on GitHub.

    El pod se autentica mediante una identidad de pod (descrita anteriormente) o mediante el uso de una entidad de servicio de Azure AD junto con un secreto de cliente.The pod authenticates itself by using either a pod identity (described above) or by using an Azure AD Service Principal along with a client secret. Se recomienda el uso de identidades de pod porque el secreto de cliente no es necesario en ese caso.Using pod identities is recommended because the client secret isn't needed in that case.

  • HashiCorp Vault.HashiCorp Vault. Las aplicaciones de Kubernetes se pueden autenticar con HashiCorp Vault mediante identidades administradas de Azure AD.Kubernetes applications can authenticate with HashiCorp Vault using Azure AD managed identities. Consulte HashiCorp Vault speaks Azure Active Directory (HashiCorp Vault se comunica con Azure Active Directory).See HashiCorp Vault speaks Azure Active Directory. Puede implementar el propio almacén en Kubernetes, pero es aconsejable ejecutarlo en un clúster dedicado independiente del clúster de la aplicación.You can deploy Vault itself to Kubernetes, but it's recommend to run it in a separate dedicated cluster from your application cluster.

  • Secretos de Kubernetes.Kubernetes secrets. Otra opción es usar secretos de Kubernetes.Another option is simply to use Kubernetes secrets. Esta opción es la más fácil de configurar pero tiene algunos desafíos.This option is the easiest to configure but has some challenges. Los secretos se almacenan en etcd, que es un almacén distribuido de pares clave-valor.Secrets are stored in etcd, which is a distributed key-value store. AKS cifra etcd en reposo.AKS encrypts etcd at rest. Microsoft administra las claves de cifrado.Microsoft manages the encryption keys.

El uso de un sistema como HashiCorp Vault o Azure Key Vault proporciona varias ventajas, como:Using a system like HashiCorp Vault or Azure Key Vault provides several advantages, such as:

  • Control centralizado de los secretos.Centralized control of secrets.
  • Garantías de que todos los secretos se cifran en reposo.Ensuring that all secrets are encrypted at rest.
  • Administración de claves centralizada.Centralized key management.
  • Control de acceso a los secretos.Access control of secrets.
  • AuditoríaAuditing

Seguridad del pod y el contenedorPod and container security

Esta lista ciertamente no es exhaustiva, pero estos son algunos procedimientos recomendados para proteger los pods y los contenedores:This list is certainly not exhaustive, but here are some recommended practices for securing your pods and containers:

No ejecute contenedores en modo con privilegios.Don't run containers in privileged mode. El modo con privilegios otorga a un contenedor acceso a todos los dispositivos del host.Privileged mode gives a container access to all devices on the host. Puede establecer una directiva de seguridad del pod para no permitir que los contenedores se ejecuten en modo con privilegios.You can set Pod Security Policy to disallow containers from running in privileged mode.

Cuando sea posible, evite ejecutar procesos como root dentro de los contenedores.When possible, avoid running processes as root inside containers. 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.Containers do not provide complete isolation from a security standpoint, so it's better to run a container process as a non-privileged user.

Almacene las imágenes en un registro privado de confianza, como Azure Container Registry o Docker Trusted Registry.Store images in a trusted private registry, such as Azure Container Registry or 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.Use a validating admission webhook in Kubernetes to ensure that pods can only pull images from the trusted registry.

Buscar imágenes y contenedores de vulnerabilidades conocidas, mediante una solución de análisis como Twistlock y aguamarina, que están disponibles a través de Azure Marketplace en ejecución.Scan images and running containers for known vulnerabilities, using a scanning solution such as Twistlock and Aqua, which are available through the Azure Marketplace.

Automatice la aplicación de revisiones de imágenes con ACR Tasks, una característica de Azure Container Registry.Automate image patching using ACR Tasks, a feature of Azure Container Registry. Una imagen de contenedor se compone de capas.A container image is built up from layers. 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.The base layers include the OS image and application framework images, such as ASP.NET Core or Node.js. Los desarrolladores de aplicaciones normalmente crean de modo ascendente las imágenes de base y otros desarrolladores del proyecto las mantienen.The base images are typically created upstream from the application developers, and are maintained by other project maintainers. 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.When these images are patched upstream, it's important to update, test, and redeploy your own images, so that you don't leave any known security vulnerabilities. ACR Tasks puede ayudar a automatizar este proceso.ACR Tasks can help to automate this process.

Consideraciones de implementación (CI/CD)Deployment (CI/CD) considerations

Estos son algunos objetivos de un proceso de CI/CD sólido para una arquitectura de microservicios:Here are some goals of a robust CI/CD process for a microservices architecture:

  • Cada equipo puede compilar e implementar los servicios que posee de forma independiente, sin afectar ni interrumpir a otros equipos.Each team can build and deploy the services that it owns independently, without affecting or disrupting other teams.
  • 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.Before a new version of a service is deployed to production, it gets deployed to dev/test/QA environments for validation. Se aplican pruebas de calidad en cada fase.Quality gates are enforced at each stage.
  • Una nueva versión de un servicio puede implementarse en paralelo con la versión anterior.A new version of a service can be deployed side by side with the previous version.
  • Hay en vigor directivas de control de acceso suficientes.Sufficient access control policies are in place.
  • Para cargas de trabajo en contenedor, puede confiar en las imágenes de contenedor que se implementan en producción.For containerized workloads, you can trust the container images that are deployed to production.

Para obtener más información acerca de los desafíos, vea CI/CD para las arquitecturas de microservicios.To learn more about the challenges, see CI/CD for microservices architectures.

Para obtener recomendaciones específicas y procedimientos recomendados, consulte CI/CD para microservicios en Kubernetes.For specific recommendations and best practices, see CI/CD for microservices on Kubernetes.

Implementación de la soluciónDeploy the solution

Para implementar la implementación de referencia para esta arquitectura, siga los pasos descritos en la repositorio de GitHub.To deploy the reference implementation for this architecture, follow the steps in the GitHub repo.