Editar

Compartir a través de

Consideraciones sobre Azure Kubernetes Service (AKS) para el multiinquilinato

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) simplifica la implementación de un clúster de Kubernetes administrado en Azure, ya que descarga la sobrecarga operativa en la plataforma en la nube de Azure. Al ser un servicio de Kubernetes hospedado, Azure controla tareas críticas como la supervisión del estado y el mantenimiento. La plataforma Azure administra el plano de control de AKS, y usted solo paga los nodos de AKS que ejecutan sus aplicaciones.

Los clústeres de AKS se pueden compartir entre varios inquilinos en diferentes escenarios y de diferentes maneras. En algunos casos, se pueden ejecutar diversas aplicaciones en el mismo clúster. En otros casos, se pueden ejecutar varias instancias de la misma aplicación en el mismo clúster compartido, una para cada inquilino. Todos estos tipos de uso compartido se describen con frecuencia mediante el término paraguas multiinquilinato. Kubernetes no tiene un concepto de primera clase de usuarios finales o inquilinos. Aun así, proporciona varias características que le ayudarán a administrar diferentes requisitos de inquilinato.

En este artículo, se describen algunas de las características de AKS que resultan útiles al crear sistemas multiinquilino. Para obtener instrucciones generales y procedimientos recomendados para el multiinquilinato de Kubernetes, consulte Multiinquilinato en la documentación de Kubernetes.

Tipos de multiinquilinato

El primer paso para determinar cómo compartir un clúster de AKS entre varios inquilinos es evaluar los patrones y las herramientas a su disposición. En general, el multiinquilinato en clústeres de Kubernetes se divide en dos categorías principales, aunque son posibles muchas variantes. En la documentación de Kubernetes, se describen dos casos de uso comunes para el multiinquilinato: varios equipos y varios clientes.

Varios equipos

Una forma común de multiinquilinato es compartir un clúster entre varios equipos dentro de una organización. Cada equipo puede implementar, supervisar y operar una o varias soluciones. Estas cargas de trabajo suelen necesitar comunicarse entre sí y con otras aplicaciones internas o externas que se encuentran en el mismo clúster o en otras plataformas de hospedaje.

Además, estas cargas de trabajo deben comunicarse con servicios, como una base de datos relacional, un repositorio NoSQL o un sistema de mensajería, que se hospedan en el mismo clúster o se ejecutan como servicios PaaS en Azure.

En este escenario, los miembros de los equipos suelen tener acceso directo a los recursos de Kubernetes mediante herramientas como kubectl. O bien, los miembros tienen acceso indirecto mediante controladores de GitOps, como Flux y Argo CD, o mediante otros tipos de herramientas de automatización de versiones.

Para más información sobre este escenario, consulte Varios equipos en la documentación de Kubernetes.

Varios clientes

Otra forma común de multiinquilinato suele implicar a un proveedor de software como servicio (SaaS). O bien, un proveedor de servicios ejecuta varias instancias de una carga de trabajo para sus clientes, que se consideran inquilinos independientes. En este escenario, los clientes no tienen acceso directo al clúster de AKS, sino que solo tienen acceso a su aplicación. Es más, ni siquiera saben que su aplicación se ejecuta en Kubernetes. La optimización de costos suele ser un problema crítico. Los proveedores de servicios usan directivas de Kubernetes, como las cuotas de recursos y las directivas de red, para asegurarse de que las cargas de trabajo están fuertemente aisladas entre sí.

Para más información sobre este escenario, consulte Varios clientes en la documentación de Kubernetes.

Modelos de aislamiento

Según la documentación de Kubernetes, un clúster de Kubernetes multiinquilino lo comparten varios usuarios y cargas de trabajo que se conocen normalmente como inquilinos. Esta definición incluye los clústeres de Kubernetes que comparten diferentes equipos o divisiones dentro de una organización. También contiene clústeres compartidos por instancias por cliente de una aplicación de software como servicio (SaaS).

El uso de varios inquilinos de clústeres es una alternativa a la administración de muchos clústeres dedicados de un solo inquilino. Los operadores de un clúster de Kubernetes multiinquilino deben aislar los inquilinos entre sí. Este aislamiento minimiza el daño que un inquilino en peligro o malintencionado puede hacer al clúster y a otros inquilinos.

Cuando varios usuarios o equipos comparten el mismo clúster con un número fijo de nodos, existe la preocupación de que un equipo pueda usar más que su cuota equitativa de recursos. Cuotas de recursos es una herramienta para que los administradores solucionen este problema.

En función del nivel de seguridad proporcionado por el aislamiento, podemos distinguir entre multiinquilinato flexible y rígido.

  • El multiinquilinato flexible es adecuado dentro de una sola empresa en la que los inquilinos son equipos o departamentos diferentes que confían entre sí. En este escenario, el aislamiento tiene como objetivo garantizar la integridad de las cargas de trabajo, organizar los recursos del clúster en diferentes grupos de usuarios internos y defenderse frente a posibles ataques de seguridad.
  • El multiinquilinato rígido se usa para describir escenarios en los que inquilinos heterogéneos no confían entre sí, a menudo desde perspectivas de seguridad y uso compartido de recursos.

Al planear la creación de un clúster de Azure Kubernetes Service (AKS) multiinquilino, debe tener en cuenta las capas de aislamiento de recursos y el multiinquilinato que proporciona Kubernetes:

  • Clúster
  • Espacio de nombres
  • Grupo de nodos o nodo
  • Pod
  • Contenedor

Además, debe tener en cuenta las implicaciones de seguridad de compartir distintos recursos entre varios inquilinos. Por ejemplo, la programación de pods de distintos inquilinos en el mismo nodo podría reducir el número de máquinas necesarias en el clúster. Por otro lado, es posible que tenga que evitar que se coloquen determinadas cargas de trabajo. Por ejemplo, es posible que no permita que el código que no sea de confianza de fuera de la organización se ejecute en el mismo nodo que los contenedores que procesan información confidencial.

Aunque Kubernetes no puede garantizar un aislamiento perfectamente seguro entre inquilinos, ofrece características que pueden ser suficientes para casos de uso específicos. Como procedimiento recomendado, debe separar cada inquilino y sus recursos de Kubernetes en sus espacios de nombres. De esta forma, puede usar el control de acceso basado en rol de Kubernetes (RBAC) y las directivas de red para aplicar el aislamiento de inquilino. Por ejemplo, la imagen siguiente muestra el modelo de proveedor de SaaS típico que hospeda varias instancias de la misma aplicación en el mismo clúster, una para cada inquilino. Cada aplicación reside en un espacio de nombres independiente.

Diagrama que muestra un modelo de proveedor de SaaS que hospeda varias instancias de la misma aplicación en el mismo clúster.

Hay varias maneras de diseñar y crear soluciones multiinquilino con Azure Kubernetes Service (AKS). Cada uno de estos métodos incluye su propio conjunto de ventajas e inconvenientes, en términos de implementación de la infraestructura, topología de red y seguridad. Estos métodos afectan al nivel de aislamiento, el esfuerzo de implementación, la complejidad operativa y el costo. Puede aplicar el aislamiento de inquilinos en los planos de control y de datos, en función de los requisitos.

Aislamiento del plano de control

Si tiene aislamiento en el nivel del plano de control, se garantiza que los distintos inquilinos no puedan acceder a los recursos de los demás, como pods y servicios. Además, no pueden afectar al rendimiento de las aplicaciones de otros inquilinos. Para más información, consulte Aislamiento del plano de control en la documentación de Kubernetes. La mejor manera de implementar el aislamiento en el nivel del plano de control es separar la carga de trabajo de cada inquilino y sus recursos de Kubernetes en un espacio de nombres independiente.

Según la documentación de Kubernetes, un espacio de nombres es una abstracción que se usa para admitir el aislamiento de grupos de recursos dentro de un único clúster. Los espacios de nombres se pueden usar para aislar las cargas de trabajo de inquilino que comparten un clúster de Kubernetes:

  • Los espacios de nombres permiten que existan cargas de trabajo de inquilino distintas en su propia área de trabajo virtual, sin el riesgo de afectar al trabajo de los demás. Los equipos independientes de una organización pueden usar espacios de nombres para aislar sus proyectos entre sí, ya que pueden usar los mismos nombres de recursos en diferentes espacios de nombres sin el riesgo de superposición de nombres.
  • Los roles RBAC y los enlaces de roles son recursos con ámbito del espacio de nombres que los equipos pueden usar para limitar los usuarios y procesos del inquilino para acceder a los recursos y servicios solo de sus espacios de nombres. Los distintos equipos pueden definir roles para agrupar listas de permisos o capacidades con un solo nombre. A continuación, asignan estos roles a cuentas de usuario y cuentas de servicio, para asegurarse de que solo las identidades autorizadas tengan acceso a los recursos de un espacio de nombres determinado.
  • Las cuotas de recursos para CPU y memoria son objetos con espacio de nombres. Los equipos pueden usarlos para asegurarse de que las cargas de trabajo que comparten el mismo clúster estén fuertemente aisladas del consumo de recursos del sistema. Este método puede garantizar que todas las aplicaciones de inquilino que se ejecutan en un espacio de nombres independiente tengan los recursos que necesitan para ejecutarse y evitar el problema del vecino ruidoso, lo que podría afectar a otras aplicaciones de inquilino que comparten el mismo clúster.
  • Las directivas de red son objetos con espacio de nombres que los equipos pueden adoptar para aplicar qué tráfico de red se permite para una aplicación de inquilino determinada. Puede usar directivas de red para separar cargas de trabajo distintas que comparten el mismo clúster desde una perspectiva de red.
  • Las aplicaciones de equipo que se ejecutan en distintos espacios de nombres pueden usar diferentes cuentas de servicio para acceder a los recursos dentro del mismo clúster, aplicaciones externas o servicios administrados.
  • Use espacios de nombres para mejorar el rendimiento en el nivel de plano de control. Si las cargas de trabajo de un clúster compartido se organizan en varios espacios de nombres, la API de Kubernetes tiene menos elementos que buscar al ejecutar operaciones. Esta organización puede reducir la latencia de las llamadas al servidor de API y aumentar el rendimiento del plano de control.

Para más información sobre el aislamiento en el nivel de espacio de nombres, consulte los siguientes recursos en la documentación de Kubernetes:

Aislamiento del plano de datos

El aislamiento del plano de datos garantiza que los pods y las cargas de trabajo de inquilinos distintos estén suficientemente aislados entre sí. Para más información, consulte Aislamiento del plano de datos en la documentación de Kubernetes.

Aislamiento de red

Al ejecutar aplicaciones modernas basadas en microservicios en Kubernetes, con frecuenta querrá controlar qué componentes pueden comunicarse entre sí. De manera predeterminada, todos los pods de un clúster de AKS pueden enviar y recibir tráfico sin restricciones, incluidas otras aplicaciones que comparten el mismo clúster. Para mejorar la seguridad, puede definir reglas de red para controlar el flujo de tráfico. La directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación entre pods. Puede usar directivas de red para separar las comunicaciones entre las aplicaciones de inquilino que comparten el mismo clúster.

Azure Kubernetes Service (AKS) proporciona dos maneras de implementar directivas de red:

  1. Azure tiene su implementación para las directivas de red, llamadas directivas de red de Azure.
  2. Las directivas de red de Calico son una solución de seguridad de red y redes de código abierto fundada por Tigera.

Ambas implementaciones usan IPTables de Linux para aplicar las directivas especificadas. Las directivas de red se traducen en conjuntos de pares de direcciones IP permitidas y no permitidas. Después, estos pares se programan como reglas de filtro de IPTable. Solo puede usar directivas de red de Azure con clústeres de AKS configurados con el complemento de red de Azure CNI. Sin embargo, las directivas de red de Calico admiten tanto Azure CNI como kubenet. Para más información, consulte Protección del tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS).

Para más información, consulte Aislamiento de red en la documentación de Kubernetes.

Aislamiento del almacenamiento

Azure proporciona un amplio conjunto de repositorios de datos administrados como plataforma como servicio (PaaS), como Azure SQL Database y Azure Cosmos DB, y otros servicios de almacenamiento que puede usar como volúmenes persistentes para las cargas de trabajo. Las aplicaciones de inquilino que se ejecutan en un clúster de AKS compartido pueden compartir una base de datos o un almacén de archivos, o pueden usar un repositorio de datos y un recurso de almacenamiento dedicados. Para obtener más información sobre las diferentes estrategias y enfoques para administrar datos en un escenario multiinquilino, consulte Enfoques arquitectónicos para el almacenamiento y los datos en soluciones de multiinquilino.

Las cargas de trabajo que se ejecutan en Azure Kubernetes Service (AKS) también pueden usar volúmenes persistentes para almacenar los datos. En Azure, puede crear volúmenes persistentes como recursos de Kubernetes respaldados por Azure Storage. Puede crear manualmente volúmenes de datos y asignarlos a los pods directamente, o bien puede hacer que AKS los cree automáticamente mediante notificaciones de volumen persistente. AKS proporciona clases de almacenamiento integradas para crear volúmenes persistentes respaldados por discos de Azure, Azure Files y Azure NetApp Files. Para obtener más información, consulte Opciones de almacenamiento de aplicaciones en Azure Kubernetes Service (AKS). Por motivos de seguridad y resistencia, debe evitar el uso del almacenamiento local en los nodos de agente mediante emptyDir y hostPath.

Cuando las clases de almacenamiento integradas de AKS no son una buena opción para uno o varios inquilinos, puede crear clases de almacenamiento personalizadas para satisfacer los distintos requisitos de los inquilinos. Estos requisitos incluyen el tamaño del volumen, la SKU de almacenamiento, un contrato de nivel de servicio (SLA), las directivas de copia de seguridad y el plan de tarifa.

Por ejemplo, puede configurar una clase de almacenamiento personalizada para cada inquilino. Después, puede usarla para aplicar etiquetas a cualquier volumen persistente que se cree en su espacio de nombres para cargar sus costos. Para obtener más información sobre este escenario, consulte Uso de etiquetas de Azure en Azure Kubernetes Service (AKS).

Para más información, consulte Aislamiento del almacenamiento en la documentación de Kubernetes.

Aislamiento de nodos

Las cargas de trabajo de inquilino se pueden configurar para que se ejecuten en nodos de agente independientes para evitar el problema del vecino ruidoso y reducir el riesgo de divulgación de información. En AKS, puede crear un clúster independiente, o simplemente un grupo de nodos dedicado, para aquellos inquilinos que tengan requisitos estrictos en términos de aislamiento, seguridad, cumplimiento normativo y rendimiento.

Puede usar intolerancias, tolerancias, etiquetas de nodo, selectores de nodo y afinidad de nodo para restringir los pods de inquilinos, de modo que solo se ejecuten en un conjunto determinado de nodos o grupos de nodos.

En general, AKS proporciona aislamiento de carga de trabajo en varios niveles:

  • A nivel de kernel, mediante la ejecución de cargas de trabajo de inquilino en máquinas virtuales ligeras en nodos de agente compartidos y mediante el uso del espacio seguro para pods basado en contenedores kata.
  • A nivel físico, hospedando aplicaciones de inquilino en clústeres dedicados o grupos de nodos.
  • A nivel de hardware, mediante la ejecución de cargas de trabajo de inquilino en hosts dedicados de Azure que garantizan que las máquinas virtuales de nodo de agente ejecuten máquinas físicas dedicadas. El aislamiento de hardware garantiza que ninguna otra máquina virtual se coloque en los hosts dedicados, lo que proporciona una capa adicional de aislamiento para las cargas de trabajo de inquilino.

Puede combinar estas técnicas. Por ejemplo, puede ejecutar clústeres por inquilino y grupos de nodos en un grupo host dedicado de Azure para lograr la segregación de cargas de trabajo y el aislamiento físico a nivel de hardware. También puede crear grupos de nodos compartidos o por inquilino que admitan el Estándar federal de proceso de información (FIPS), Virtual Machines confidencial (CVM) o el cifrado basado en host.

El aislamiento de nodos permite asociar y cobrar fácilmente el costo de un conjunto de nodos o un grupo de nodos a un solo inquilino. Está estrictamente relacionado con el modelo de inquilinato adoptado por la solución.

Para más información, consulte Aislamiento de nodos en la documentación de Kubernetes.

Modelos de inquilinato

Azure Kubernetes Service (AKS) proporciona más tipos de aislamiento de nodos y modelos de inquilinato.

Implementaciones automatizadas de inquilino único

En un modelo de implementación automatizada de un solo inquilino, se implementa un conjunto dedicado de infraestructura para cada inquilino, como se muestra en este ejemplo:

Diagrama que muestra tres inquilinos, cada uno con implementaciones independientes.

Cada carga de trabajo de inquilino se ejecuta en un clúster de AKS dedicado y accede a un conjunto distinto de recursos de Azure. Normalmente, las soluciones multiinquilino que se crean con este modelo hacen un uso extenso de la infraestructura como código (IaC). Por ejemplo, Bicep, Azure Resource Manager, Terraform o las API REST de Azure Resource Manager ayudan a iniciar y coordinar la implementación a petición de recursos dedicados al inquilino. Puede usar este enfoque cuando necesite aprovisionar una infraestructura completamente independiente para cada uno de los clientes. Al planear la implementación, considere la posibilidad de utilizar el patrón de stamps de implementación.

Ventajas:

  • Una ventaja clave de este enfoque es que el servidor de API de cada clúster de AKS de inquilino es independiente. Este enfoque garantiza el aislamiento completo entre los inquilinos de un nivel de seguridad, redes y consumo de recursos. Un atacante que logre obtener el control de un contenedor solo tendrá acceso a los contenedores y volúmenes montados que pertenecen a un único inquilino. Un modelo de inquilinato de aislamiento completo es fundamental para algunos clientes con una sobrecarga de cumplimiento normativo alta.
  • Es poco probable que los inquilinos afecten al rendimiento del sistema de otro inquilino, lo que le permite evitar el problema del vecino ruidoso. Esta consideración incluye el tráfico en el servidor de API. El servidor de API es un componente compartido y crítico en cualquier clúster de Kubernetes. Los controladores personalizados, que generan tráfico no regulado y de gran volumen en el servidor de API, pueden provocar inestabilidad en el clúster. Esta inestabilidad conduce a errores de solicitud, tiempos de espera y tormentas de reintento de API. La característica de SLA (acuerdo de nivel de servicio) de tiempo de actividad permite escalar horizontalmente el plano de control de un clúster de AKS para satisfacer la demanda de tráfico. Sin embargo, el aprovisionamiento de un clúster dedicado puede ser una mejor solución para aquellos clientes con requisitos sólidos en términos de aislamiento de cargas de trabajo.
  • Las actualizaciones y los cambios se pueden implementar progresivamente en los inquilinos, lo que reduce la probabilidad de una interrupción en todo el sistema. Los costos de Azure se pueden cobrar fácilmente a los inquilinos, ya que un único inquilino usa todos los recursos.

Riesgos:

  • La rentabilidad es baja porque cada inquilino usa un conjunto dedicado de recursos.
  • Es probable que el mantenimiento continuo sea lento, ya que se debe replicar en varios clústeres de AKS, uno para cada inquilino. Considere la posibilidad de automatizar los procesos operativos y de aplicar los cambios progresivamente en los entornos. Esto le ayudará si también considera otras operaciones entre implementaciones, como informes y análisis en todo el patrimonio. Del mismo modo, asegúrese de planear cómo consultar y manipular los datos en varias implementaciones.

Implementaciones totalmente multiinquilino

En una implementación totalmente multiinquilino, una sola aplicación atiende las solicitudes de todos los inquilinos y se comparten todos los recursos de Azure, incluido el clúster de AKS. En este contexto, solo tiene un conjunto de infraestructura que implementar, supervisar y mantener. Todos los inquilinos usan el recurso, como se muestra en el diagrama siguiente:

Diagrama que muestra tres inquilinos, todos usan una sola implementación compartida.

Ventajas

  • Este modelo es atractivo debido al menor costo de operación de una solución con componentes compartidos. Al usar este modelo de inquilinato, es posible que tenga que implementar un clúster de AKS más grande y adoptar una SKU superior para cualquier repositorio de datos compartido para mantener el tráfico generado por todos los recursos de los inquilinos, como los repositorios de datos.

Riesgos:

  • En este contexto, una sola aplicación controla todas las solicitudes de los inquilinos. Debe diseñar e implementar medidas de seguridad para evitar que los inquilinos inunden la aplicación con llamadas. Estas llamadas podrían ralentizar todo el sistema y afectar a todos los inquilinos.
  • Si el perfil de tráfico es muy variable, debe configurar el escalador automático del clúster de AKS para variar el número de pods y los nodos de agente. Base la configuración en el uso de recursos del sistema, como CPU y memoria. Como alternativa, puede escalar horizontalmente y reducir horizontalmente el número de pods y nodos de clúster, en función de métricas personalizadas. Por ejemplo, puede explorar el número de solicitudes pendientes o las métricas de un sistema de mensajería externo que usa el escalado automático controlado por eventos de Kubernetes (KEDA).
  • Asegúrese de separar los datos de cada inquilino e implementar medidas de seguridad para evitar la filtración de datos entre distintos inquilinos.
  • Asegúrese de realizar un seguimiento y asociar los costos de Azure a los inquilinos individuales, en función de su uso real. Las soluciones de terceros, como kubecost, pueden ayudarle a calcular y desglosar los costos entre distintos equipos e inquilinos.
  • El mantenimiento puede ser más sencillo con una implementación única, ya que solo tiene que actualizar un conjunto de recursos de Azure y mantener una sola aplicación. Sin embargo, también suele ser más arriesgado, ya que cualquier cambio en la infraestructura o los componentes de la aplicación puede afectar a toda la base de clientes.
  • También debe tener en cuenta las limitaciones de escala. Es más probable que se alcancen los límites de escala de los recursos de Azure cuando se tiene un conjunto compartido de recursos. Para evitar alcanzar un límite de cuota de recursos, puede considerar la posibilidad de distribuir los inquilinos entre varias suscripciones de Azure.

Implementaciones con particiones horizontales

Como alternativa, puede considerar la posibilidad de crear particiones horizontales de la aplicación de Kubernetes multiinquilino. Este enfoque consiste en compartir algunos componentes de la solución entre todos los inquilinos e implementar recursos dedicados para inquilinos individuales. Por ejemplo, podría crear una única aplicación de Kubernetes multiinquilino y, a continuación, crear bases de datos individuales, una para cada inquilino, como se muestra en esta ilustración:

Diagrama que muestra tres inquilinos, cada uno con una base de datos dedicada y una única aplicación de Kubernetes compartida.

Ventajas:

  • Las implementaciones con particiones horizontales pueden ayudarle a mitigar el problema del vecino ruidoso. Tenga en cuenta este enfoque si ha identificado que la mayor parte de la carga de tráfico de la aplicación de Kubernetes se debe a componentes específicos, que puede implementar por separado para cada inquilino. Por ejemplo, las bases de datos pueden absorber la mayor parte de la carga del sistema, porque la carga de consultas es alta. Si un único inquilino envía un gran número de solicitudes a la solución, el rendimiento de una base de datos puede verse afectado negativamente, pero las bases de datos de otros inquilinos (y los componentes compartidos, como el nivel de aplicación) no se ven afectadas.

Riesgos:

  • Con una implementación con particiones horizontales, debe seguir teniendo en cuenta la implementación y administración automatizadas de los componentes, especialmente los componentes utilizados por un solo inquilino.
  • Es posible que este modelo no proporcione el nivel de aislamiento necesario para aquellos clientes que no puedan permitirse compartir recursos con otros inquilinos, por motivos de cumplimiento o directivas internas.

Implementaciones con particiones verticales

Puede aprovechar las ventajas de los modelos de inquilino único y multiinquilino total mediante el uso de un modelo híbrido que cree particiones verticales de los inquilinos en varios clústeres de AKS o grupos de nodos. Este enfoque proporciona las siguientes ventajas sobre los dos modelos de inquilinato anteriores:

  • Puede usar una combinación de implementaciones de inquilino único y multiinquilino. Por ejemplo, puede hacer que la mayoría de los clientes compartan un clúster de AKS y una base de datos en una infraestructura multiinquilino. Aun así, también puede implementar infraestructuras de inquilino único para aquellos clientes que requieran un mayor rendimiento y aislamiento.
  • Puede implementar inquilinos en varios clústeres de AKS regionales, potencialmente con diferentes configuraciones. Esta técnica es más eficaz cuando tiene inquilinos distribuidos en diferentes zonas geográficas.

Puede implementar diferentes variantes de este modelo de inquilinato. Por ejemplo, puede optar por ofrecer su solución multiinquilino con diferentes niveles de funcionalidad a un costo diferente. El modelo de precios podría proporcionar varias SKU, cada una de las cuales proporciona un nivel incremental de rendimiento y aislamiento, en términos de uso compartido de recursos, rendimiento, red y segregación de datos. Considere la posibilidad de utilizar los siguientes niveles:

  • Nivel Básico: una única aplicación de Kubernetes multiinquilino que se comparte con otros inquilinos atiende las solicitudes de los inquilinos. Los datos se almacenan en una o varias bases de datos compartidas por todos los inquilinos del nivel Básico.
  • Nivel Estándar: una aplicación dedicada de Kubernetes que se ejecuta en un espacio de nombres independiente, que proporciona límites de aislamiento en términos de seguridad, redes y consumo de recursos atiende las solicitudes de los inquilinos. Todas las aplicaciones de los inquilinos, una para cada inquilino, comparten el mismo clúster de AKS y el mismo grupo de nodos con otros clientes del nivel estándar.
  • Nivel Premium: la aplicación de inquilino se ejecuta en un grupo de nodos o en un clúster de AKS dedicados, para garantizar un mayor grado de nivel de servicio, rendimiento y aislamiento. Este nivel podría proporcionar un modelo de costes flexible basado en el número y la SKU de los nodos de agente que se usan para hospedar la aplicación de inquilino. Puede usar el espacio seguro para pods como solución alternativa para usar clústeres dedicados o grupos de nodos para aislar cargas de trabajo de inquilino distintas.

En el diagrama siguiente, se muestra un escenario en el que los inquilinos A y B se ejecutan en un clúster de AKS compartido, mientras que el inquilino C se ejecuta en un clúster de AKS independiente.

Diagrama que muestra tres inquilinos. Los inquilinos A y B comparten un clúster de AKS. El inquilino C tiene un clúster de AKS dedicado.

Del mismo modo, el diagrama siguiente muestra un escenario en el que los inquilinos A y B se ejecutan en el mismo grupo de nodos, mientras que el inquilino C se ejecuta en un grupo de nodos dedicado.

Diagrama que muestra tres inquilinos. Los inquilinos A y B comparten un grupo de nodos. El inquilino C tiene un grupo de nodos dedicado.

Este modelo también puede ofrecer contratos de nivel de servicio diferentes para los distintos niveles. Por ejemplo, el nivel Básico puede ofrecer un tiempo de actividad del 99,9 %, el nivel Estándar puede ofrecer un tiempo de actividad del 99,95 % y el nivel Premium puede ofrecer un 99,99 %. El Acuerdo de Nivel de Servicio (SLA) superior puede implementarse mediante servicios y características que permitan destinos de disponibilidad superiores.

Ventajas:

  • Puesto que sigue compartiendo la infraestructura, puede obtener algunas de las ventajas en los costos por tener implementaciones multiinquilino compartidas. Puede implementar clústeres y grupos de nodos que se compartan entre varias aplicaciones de inquilino de nivel Básico y de nivel Estándar, que usan un tamaño de máquina virtual más barato para los nodos de agente. Este enfoque garantiza una mejor densidad y ahorro de costos. En el caso de los clientes de nivel Premium, puede implementar clústeres de AKS y grupos de nodos con un tamaño de máquina virtual mayor y un número máximo de nodos y réplicas de pods a un precio superior.
  • Puede ejecutar los servicios del sistema, como CoreDNS, Konnectivity o el Controlador de entrada de Azure Application Gateway, en un grupo de nodos en modo sistema dedicado. Puede usar intolerancias, tolerancias, etiquetas de nodo, selectores de nodo y afinidad de nodo para ejecutar una aplicación de inquilino en uno o varios grupos de nodos en modo de usuario.
  • Puede usar intolerancias, tolerancias, etiquetas de nodo, selectores de nodo y afinidad de nodo para ejecutar los recursos compartidos. Por ejemplo, puede tener un controlador de entrada o un sistema de mensajería en un grupo de nodos dedicado, con un tamaño de máquina virtual específico, la configuración del escalador automático y la compatibilidad con zonas de disponibilidad.

Riesgos:

  • Debe diseñar la aplicación de Kubernetes para admitir implementaciones multiinquilino y de inquilino único.
  • Si planea permitir la migración entre infraestructuras, debe tener en cuenta cómo migrar los clientes de una implementación multiinquilino a su propia implementación de un solo inquilino.
  • Necesita una estrategia coherente y un único panel (un punto de vista) para supervisar y administrar más clústeres de AKS.

Escalado automático

Para mantenerse al día con la demanda de tráfico generada por las aplicaciones de inquilino, puede habilitar el escalador automático del clúster para escalar los nodos de agente de Azure Kubernetes Service (AKS). El escalado automático ayuda a los sistemas a seguir con capacidad de respuesta en las siguientes circunstancias:

  • La carga de tráfico aumenta durante horas de trabajo o períodos específicos del año.
  • Las cargas pesadas compartidas o de inquilino se implementan en un clúster.
  • Los nodos de agente dejan de estar disponibles debido a interrupciones de zona.

Al habilitar el escalado automático para un grupo de nodos, se especifica un número mínimo y máximo de nodos en función de los tamaños de carga de trabajo esperados. Al configurar un número máximo de nodos, puede garantizar suficiente espacio para todos los pods de inquilino del clúster, independientemente del espacio de nombres en el que se ejecuten.

Cuando aumenta el tráfico, el escalado automático del clúster agrega nuevos nodos de agente para evitar que los pods entren en un estado pendiente, debido a una escasez de recursos en términos de CPU y memoria.

Del mismo modo, cuando la carga disminuye, el escalado automático del clúster reduce el número de nodos de agente de un grupo de nodos en función de los límites especificados, lo que ayuda a reducir los costos operativos.

Puede usar el escalado automático de pods para escalar los pods automáticamente, en función de las demandas de recursos. Horizontal Pod Autoscaler (HPA) escala automáticamente el número de réplicas de pods en función del uso de CPU y memoria, o de métricas personalizadas. Con el Escalado automático controlado por eventos de Kubernetes (KEDA), puede controlar el escalado de cualquier contenedor de Kubernetes en función del número de eventos de los sistemas externos, como Azure Event Hubs o Azure Service Bus, utilizados por las aplicaciones de inquilino.

Mantenimiento

Para reducir el riesgo de tiempos de inactividad que puedan afectar a las aplicaciones de inquilino durante las actualizaciones del clúster o del grupo de nodos, programe el mantenimiento planeado de AKS para que se produzca durante las horas de poca actividad. El mantenimiento planeado permite programar ventanas de mantenimiento semanales para actualizar el plano de control de los clústeres de AKS que ejecutan aplicaciones de inquilino y grupos de nodos, lo que minimiza el impacto en la carga de trabajo. Puede programar una o varias ventanas de mantenimiento semanales en el clúster especificando un día o un intervalo de tiempo de un día específico. Todas las operaciones de mantenimiento se producirán durante las ventanas programadas.

Seguridad

Acceso al clúster

Cuando se comparte un clúster de AKS entre varios equipos dentro de una organización, debe implementar el principio de privilegios mínimos para aislar los diferentes inquilinos entre sí. Específicamente, debe asegurarse de que los usuarios solo tengan acceso a sus espacios de nombres y recursos de Kubernetes al usar herramientas como kubectl, Helm, Flux, Argo CD u otros tipos de herramientas.

Para más información sobre la autenticación y la autorización con AKS, consulte los siguientes artículos:

Identidad de carga de trabajo

Si hospeda varias aplicaciones de inquilino en un único clúster de AKS y cada una está en un espacio de nombres independiente, cada carga de trabajo debe usar una cuenta de servicio de Kubernetes y credenciales diferentes para acceder a los servicios de Azure del flujo descendente. Las cuentas de servicio son uno de los tipos de usuario principales en Kubernetes. La API de Kubernetes contiene y administra cuentas de servicio. Las credenciales de las cuentas de servicio se almacenan como secretos de Kubernetes, lo cual permite que los puedan usar los pods autorizados para comunicarse con el servidor de API. La mayoría de las solicitudes de API proporcionan un token de autenticación para una cuenta de servicio o una cuenta de usuario normal.

Las cargas de trabajo de inquilino implementadas en clústeres de AKS pueden usar credenciales de aplicación de Microsoft Entra ID para acceder a los recursos protegidos por Microsoft Entra ID, como Azure Key Vault y Microsoft Graph. La identidad de carga de trabajo de Microsoft Entra para Kubernetes se integra con las funcionalidades nativas de Kubernetes para federarse con cualquier proveedor de identidades externo.

Espacio seguro para pods

AKS incluye un mecanismo denominado espacio seguro para pods que proporciona un límite de aislamiento entre la aplicación contenedora y el kernel compartido y los recursos de proceso del host de contenedor, como CPU, memoria y redes. El espacio seguro para pods complementa otras medidas de seguridad o controles de protección de datos para ayudar a las cargas de trabajo de inquilinos a proteger la información confidencial y cumplir requisitos normativos, de la industria o de la gobernanza, como el Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (PCI DSS), la Organización Internacional de Normalización (ISO) 27001 y la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA) de los Estados Unidos.

La implementación de aplicaciones en clústeres o grupos de nodos independientes le permite aislar fuertemente las cargas de trabajo de inquilino de diferentes equipos o clientes. El uso de varios clústeres y grupos de nodos podría ser adecuado para los requisitos de aislamiento de muchas organizaciones y soluciones SaaS. Sin embargo, hay escenarios en los que un único clúster con grupos de nodos de máquina virtual compartidos es más eficaz, por ejemplo, cuando se ejecutan pods que no son de confianza y de confianza en el mismo nodo o se colocan conjuntamente DaemonSets y contenedores con privilegios en el mismo nodo para una comunicación local y agrupación funcional más rápidas. El espacio seguro para pods puede ayudarle a aislar efectivamente las aplicaciones de inquilino en los mismos nodos de clúster sin necesidad de ejecutar estas cargas de trabajo en clústeres o grupos de nodos independientes. Otros métodos requieren volver a compilar el código o causan problemas de compatibilidad, pero el espacio seguro para pods en AKS puede ejecutar cualquier contenedor no modificado dentro de un límite mejorado de máquina virtual de seguridad.

El espacio seguro para pods en AKS se basa en los contenedores kata que se ejecutan en el host de contenedor linux de Azure para la pila de AKS, con el fin de proporcionar un aislamiento aplicado por hardware. Los contenedores kata en AKS se basan en un hipervisor de Azure protegido por la seguridad. El aislamiento por pod se logra a través de una máquina virtual Kata ligera anidada que utiliza recursos de un nodo de máquina virtual primario. En este modelo, cada pod kata obtiene su propio kernel en una máquina virtual invitada kata anidada. Este modelo permite colocar muchos contenedores kata en una sola máquina virtual invitada mientras continúa ejecutando contenedores en la máquina virtual primaria. El modelo proporciona un límite de aislamiento sólido en un clúster de AKS compartido.

Para más información, consulte:

Azure Dedicated Host

Azure Dedicated Host es un servicio que proporciona servidores físicos dedicados a una sola suscripción de Azure y proporcionan aislamiento de hardware a nivel de servidor físico. Estos hosts dedicados se pueden aprovisionar dentro de una región, una zona de disponibilidad y un dominio de error, y puede colocar máquinas virtuales directamente en los hosts aprovisionados.

Puede lograr varias ventajas mediante el uso de Azure Dedicated Host con AKS, incluidos los siguientes:

  • El aislamiento de hardware garantiza que ninguna otra máquina virtual se coloque en los hosts dedicados, lo que proporciona una capa adicional de aislamiento para las cargas de trabajo de inquilino. Los hosts dedicados se implementan en los mismos centros de datos y comparten la misma red y la misma infraestructura de almacenamiento subyacente que otros hosts no aislados.

  • El host dedicado de Azure proporciona control sobre los eventos de mantenimiento que inicia la plataforma Azure. Puede elegir una ventana de mantenimiento para reducir el impacto en los servicios y ayudar a garantizar la disponibilidad y la privacidad de las cargas de trabajo de inquilino.

Azure Dedicated Host puede ayudar a los proveedores de SaaS a garantizar que las aplicaciones de inquilino cumplan los requisitos normativos, del sector y de cumplimiento de gobernanza para proteger la información confidencial. Para más información, consulte Agregar Azure Dedicated Host a un clúster de Azure Kubernetes Service (AKS).

Máquinas virtuales confidenciales

Puede usar Confidential Virtual Machines (CVM) para agregar uno o varios grupos de nodos al clúster de AKS y abordar los requisitos estrictos de aislamiento, privacidad y seguridad de los inquilinos. CVM usa un entorno de ejecución de confianza (TEE) basado en hardware. Virtualización cifrada segura de AMD: las máquinas virtuales confidenciales de paginación anidada segura (SEV-SNP) deniegan el hipervisor y otro código de administración de host a la memoria y el estado de la máquina virtual, lo que agrega una capa de protección en profundidad contra el acceso del operador. Para más información, consulte Uso de CVM en un clúster de AKS.

Estándares federales de procesamiento de la información (FIPS)

FIPS 140-3 es un estándar del gobierno de EE. UU. que define los requisitos mínimos de seguridad para los módulos criptográficos en sistemas y productos de tecnologías de la información. Al habilitar el cumplimiento de FIPS para grupos de nodos de AKS, puede mejorar el aislamiento, la privacidad y la seguridad de las cargas de trabajo del inquilino. El cumplimiento de FIPS garantiza el uso de módulos criptográficos validados para el cifrado, el hash y otras operaciones relacionadas con la seguridad. Con los grupos de nodos de AKS habilitados para FIPS, puede cumplir los requisitos normativos y de cumplimiento del sector mediante el empleo de sólidos algoritmos criptográficos y mecanismos. Azure proporciona documentación sobre cómo habilitar FIPS para grupos de nodos de AKS, lo que le permite reforzar la posición de seguridad de los entornos de AKS multiinquilino. Para más información, consulte Habilitación de FIPS para grupos de nodos de AKS.

Bring your own keys (BYOK) con discos de Azure

Azure Storage cifra todos los datos de una cuenta de almacenamiento en reposo, incluidos los discos de datos y del sistema operativo de un clúster de AKS. De manera predeterminada, los datos se cifran con claves administradas por Microsoft. Para tener más control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente y utilizarlas para el cifrado en reposo del sistema operativo y los discos de datos de los clústeres de AKS. Para más información, consulte:

Cifrado basado en host

El cifrado basado en host en AKS refuerza aún más el aislamiento de la carga de trabajo del inquilino, la privacidad y la seguridad. Al habilitar el cifrado basado en host, AKS cifra los datos en reposo en las máquinas host subyacentes, lo que ayuda a garantizar que la información confidencial del inquilino esté protegida contra el acceso no autorizado. Los discos temporales y los discos de SO efímeros se cifran en reposo con claves administradas por la plataforma al habilitar el cifrado de un extremo a otro.

De manera predeterminada, cuando se usa AKS, el sistema operativo y los discos de datos usan el cifrado del lado del servidor con claves administradas por la plataforma. Las memorias caché de estos discos se cifran en reposo con claves administradas por la plataforma. Puede especificar su propia clave de cifrado de clave (KEK) para cifrar la clave de protección de datos (DEK) mediante el cifrado de sobres, también conocido como ajuste. La memoria caché de los discos de datos y del sistema operativo también se cifra a través del BYOK que especifique.

El cifrado basado en host agrega una capa de seguridad para entornos multiinquilino. Cada dato de inquilino en las cachés del disco de datos y SO se cifra en reposo con claves administradas por el cliente o por la plataforma, según el tipo de cifrado de disco seleccionado. Para más información, consulte:

Redes

Restricción del acceso de red al servidor de API

En Kubernetes, el servidor de API recibe solicitudes para realizar acciones en el clúster, como crear recursos o escalar el número de nodos. Al compartir un clúster de AKS entre varios equipos de una organización, proteja el acceso al plano de control mediante una de las siguientes soluciones.

Clústeres privados de AKS

Mediante el uso de un clúster privado de AKS, puede asegurarse de que el tráfico de red entre el servidor de API y los grupos de nodos permanezca dentro de la red virtual. En un clúster privado de AKS, el plano de control y el servidor de API tienen una dirección IP interna que solo es accesible mediante un punto de conexión privado de Azure ubicado en la misma red virtual del clúster de AKS. Del mismo modo, cualquier máquina virtual de la misma red virtual puede comunicarse de forma privada con el plano de control mediante el punto de conexión privado. Para obtener más información, consulte Creación de un clúster privado de Azure Kubernetes Service.

Direcciones IP autorizadas

La segunda opción para mejorar la seguridad del clúster y minimizar los ataques es usar direcciones IP autorizadas. Este enfoque restringe el acceso al plano de control de un clúster de AKS público a una lista conocida de direcciones del protocolo de Internet (IP) y Enrutamiento de interdominios sin clases (CIDR). Cuando se usan direcciones IP autorizadas, se exponen públicamente, pero el acceso está limitado a un conjunto de intervalos IP. Para más información, consulte Protección del acceso al servidor de la API con intervalos de direcciones IP autorizadas en Azure Kubernetes Service (AKS).

Azure Private Link Service (PLS) es un componente de infraestructura que permite a las aplicaciones conectarse de forma privada a un servicio mediante un punto de conexión privado (PE) de Azure definido en una red virtual y conectado a la configuración IP de front-end de una instancia de Azure Load Balancer (ALB). Con Azure Private Link, los proveedores de servicios pueden proporcionar de forma segura sus servicios a sus inquilinos, quienes pueden conectarse desde Azure o desde el entorno local, sin riesgos de filtración de datos.

Puede usar la integración de Azure Private Link Service para proporcionar a los inquilinos conectividad privada a sus cargas de trabajo hospedadas en AKS de forma segura, sin necesidad de exponer ningún punto de conexión público en la red pública de Internet.

Para obtener instrucciones generales sobre cómo configurar Private Link para una solución multiinquilino hospedada en Azure, consulte Multiinquilino y Azure Private Link.

Proxies inversos

Un proxy inverso es un equilibrador de carga y una puerta de enlace de API que se usa normalmente delante de las aplicaciones de inquilino para proteger, filtrar y enviar las solicitudes entrantes. Los servidores proxy inversos populares admiten características como el equilibrio de carga, la terminación SSL y el enrutamiento de capa 7. Normalmente, los servidores proxy inversos se implementan para ayudar a aumentar la seguridad, el rendimiento y la confiabilidad. Entre los servidores proxy inversos populares para Kubernetes, se incluyen las siguientes implementaciones:

  • NGINX Ingress Controller es un popular servidor proxy inverso que admite características avanzadas, como el equilibrio de carga, la terminación SSL y el enrutamiento de capa 7.
  • El proveedor de entrada de Kubernetes Traefik es un controlador de entrada de Kubernetes que se puede usar para administrar el acceso a los servicios del clúster mediante la compatibilidad con la especificación de entrada.
  • HAProxy Kubernetes Ingress Controller es otro proxy inverso para Kubernetes, que admite características estándar como la terminación TLS, el enrutamiento basado en la ruta de acceso URL, etc.
  • El controlador de entrada de Azure Application Gateway (AGIC) es una aplicación de Kubernetes, lo que permite que los clientes de Azure Kubernetes Service (AKS) aprovechen las ventajas del equilibrador de carga L7 nativo de Azure Application Gateway para exponer las aplicaciones de inquilino a la red pública de Internet o internamente a otros sistemas que se ejecutan en una red virtual.

Al usar un proxy inverso hospedado en AKS para proteger y controlar las solicitudes entrantes para varias aplicaciones de inquilino, tenga en cuenta las siguientes recomendaciones:

  • Hospede el proxy inverso en un grupo de nodos dedicado configurado para usar un tamaño de máquina virtual con un ancho de banda de red alto y las redes aceleradas habilitadas.
  • Configure el grupo de nodos que hospeda el proxy inverso para el escalado automático.
  • Para evitar un aumento de la latencia y tiempos de espera en las aplicaciones de inquilino, defina una directiva de escalado automático para que el número de pods del controlador de entrada se pueda ampliar y contraer al instante para que coincida con las fluctuaciones del tráfico.
  • Considere la posibilidad de particionar el tráfico entrante a las aplicaciones de inquilino en varias instancias del controlador de entrada para aumentar el nivel de segregación y la escalabilidad.

Al usar el controlador de entrada de Azure Application Gateway (AGIC), considere la posibilidad de implementar los siguientes procedimientos recomendados:

  • Configure la instancia de Application Gateway que usa el controlador de entrada para el escalado automático. Con el escalado automático habilitado, las SKU v2 de Application Gateway y WAF se escalan o reducen horizontalmente en función de los requisitos del tráfico de la aplicación. Este modo ofrece una mayor elasticidad a su aplicación y elimina la necesidad de adivinar el tamaño de la puerta de enlace de aplicaciones o el número de instancias. Este modo también le permite ahorrar costos al no requerir que se ejecute la puerta de enlace a una capacidad máxima de aprovisionamiento para la carga de tráfico máxima prevista. Debe especificar un número de instancias mínimo y, opcionalmente, máximo.
  • Considere la posibilidad de implementar varias instancias del controlador de entrada de Application Gateway (AGIC), cada una asociada a una instancia independiente de Application Gateway, cuando el número de aplicaciones de inquilino supere la cantidad máxima de sitios. Suponiendo que cada aplicación de inquilino se ejecute en un espacio de nombres dedicado, use la compatibilidad con varios espacios de nombres para distribuir las aplicaciones de inquilino en más instancias del controlador de entrada de Application Gateway (AGIC).

Integración con Azure Front Door

Azure Front Door es un equilibrador de carga global de capa 7 y una red de entrega de contenido (CDN) moderna en la nube de Microsoft que proporciona acceso rápido, confiable y seguro entre usuarios y aplicaciones web en todo el mundo. Azure Front Door admite características como la aceleración de solicitudes, la terminación SSL, el almacenamiento en caché de las respuestas, WAF en el perímetro, el enrutamiento basado en direcciones URL, la reescritura y las redirecciones, que puede aprovechar al exponer aplicaciones multiinquilino hospedadas en AKS a la red pública de Internet.

Por ejemplo, es posible que quiera usar una aplicación multiinquilino hospedada en AKS para atender todas las solicitudes de los clientes. En este contexto, puede usar Azure Front Door para administrar varios dominios personalizados, uno para cada inquilino. Puede finalizar las conexiones SSL en el perímetro y enrutar todo el tráfico a la aplicación multiinquilino hospedada en AKS configurada con un único nombre de host.

Diagrama que muestra cómo se conectan Azure Front Door y AKS.

Puede configurar Azure Front Door para modificar el encabezado de host de origen de la solicitud para que coincida con el nombre de dominio de la aplicación de back-end. El encabezado Host original enviado por el cliente se propaga mediante el encabezado X-Forwarded-Host y el código de la aplicación multiinquilino puede usar esta información para asignar la solicitud al inquilino correcto.

Azure Web Application Firewall (WAF) en Azure Front Door proporciona protección centralizada para las aplicaciones web. Puede usar Azure WAF para defender las aplicaciones de inquilino hospedadas en AKS que exponen un punto de conexión público en Internet frente a ataques malintencionados.

Puede configurar Azure Front Door Premium para conectarse de forma privada a una o varias aplicaciones de inquilino que se ejecutan en un clúster de AKS, mediante un origen del equilibrador de carga interno con Azure Private Link Service. Para obtener más información, consulte Conexión de Azure Front Door Premium a un origen de equilibrador de carga interno con Private Link.

Conexiones de salida

Cuando las aplicaciones hospedadas en AKS se conectan a un gran número de bases de datos o servicios externos, el clúster podría estar en riesgo de agotamiento de puertos SNAT. Los puertos SNAT generan identificadores únicos que se usan para mantener flujos distintos que inician las aplicaciones que se ejecutan en el mismo conjunto de recursos de proceso. Al ejecutar varias aplicaciones de inquilino en un clúster compartido de Azure Kubernetes Service (AKS), podría realizar un gran número de llamadas salientes, lo que puede provocar un agotamiento de puertos SNAT. Un clúster de AKS puede controlar las conexiones salientes de tres maneras diferentes:

  • Azure Load Balancer público: de manera predeterminada, AKS aprovisiona una SKU Standard de Load Balancer que se va a configurar y usar para las conexiones de salida. Sin embargo, es posible que la configuración predeterminada no cumpla los requisitos de todos los escenarios si no se permiten direcciones IP públicas o se requieren saltos adicionales para la salida. De manera predeterminada, el equilibrador de carga público se crea con una dirección IP pública predeterminada que usan las reglas de salida. Las reglas de salida permiten definir de forma explícita la traducción de direcciones de red de origen (SNAT) para un equilibrador de carga público Estándar. Esta configuración permite usar las direcciones IP públicas del equilibrador de carga para proporcionar conectividad de Internet de salida a las instancias de back-end. Cuando sea necesario, para evitar el agotamiento de puertos SNAT, puede configurar las reglas de salida del equilibrador de carga público para usar direcciones IP públicas adicionales. Para más información, consulte Uso de la dirección IP de front-end de un equilibrador de carga para la salida mediante reglas de salida.
  • Azure NAT Gateway: puede configurar un clúster de AKS para usar Azure NAT Gateway para enrutar el tráfico de salida desde las aplicaciones de inquilino. NAT Gateway permite hasta 64 512 flujos de tráfico UDP y TCP de salida por dirección IP pública con un máximo de 16 direcciones IP. Para evitar el riesgo de agotamiento de puertos SNAT al usar una instancia de NAT Gateway para controlar las conexiones salientes desde un clúster de AKS, puede asociar más direcciones IP públicas o un prefijo de dirección IP pública a la puerta de enlace. Para más información, consulte Consideraciones de Azure NAT Gateway para la administración multiinquilino.
  • Ruta definida por el usuario (UDR): puede personalizar una ruta de salida de un clúster de AKS para admitir escenarios de red personalizados, como los que no permiten direcciones IP públicas y requieren que el clúster se encuentre detrás de un dispositivo virtual de red (NVA). Al configurar un clúster para el enrutamiento definido por el usuario, AKS no configurará automáticamente las rutas de acceso de salida. El usuario debe encargarse de la configuración de salida. Por ejemplo, enrutaría el tráfico de salida mediante Azure Firewall. El clúster de AKS se debe implementar en una red virtual existente con una subred que se haya configurado previamente. Cuando no se usa una arquitectura de Standard Load Balancer (SLB), debe establecer salidas explícitas. Por lo tanto, esta arquitectura requiere el envío explícito del tráfico de salida a un dispositivo, como un firewall, una puerta de enlace o un proxy. O bien, la arquitectura permite que la traducción de direcciones de red (NAT) se realice mediante una dirección IP pública asignada al dispositivo o la instancia de Standard Load Balancer.

Supervisión

Puede usar Azure Monitor y Container Insights para supervisar las aplicaciones de inquilino que se ejecutan en un clúster de AKS compartido y para calcular los desgloses de costos de los espacios de nombres individuales. Azure Monitor le permite supervisar el estado y el rendimiento de Azure Kubernetes Service (AKS). Incluye la recopilación de registros y métricas, análisis de telemetría y visualizaciones de los datos recopilados para identificar tendencias y configurar alertas para recibir notificaciones proactivas de problemas críticos. Puede habilitar Container Insights para ampliar esta supervisión.

También puede adoptar herramientas de código abierto, como Prometheus y Grafana, que la comunidad usa ampliamente para la supervisión de Kubernetes. O bien, puede adoptar otras herramientas de terceros para la supervisión y la observabilidad.

Costos

La gobernanza de los costos es el proceso continuo de implementación de directivas para controlar los costos. En el contexto de Kubernetes, las organizaciones disponen de varias opciones para controlar y optimizar los costos. Entre ellas, se incluyen las herramientas nativas de Kubernetes para administrar y controlar el uso y el consumo de recursos, así como supervisar y optimizar de modo proactivo la infraestructura subyacente. Al calcular los costos por inquilino, debe tener en cuenta los costos asociados a cualquier recurso que use una aplicación de inquilino. El enfoque que se siga para cobrar las tarifas a los inquilinos depende del modelo de inquilinato adoptado por la solución. Se explican más detalles con los siguientes modelos de inquilinato:

  • Totalmente multiinquilino: cuando una sola aplicación multiinquilino atiende todas las solicitudes de inquilino, es su responsabilidad realizar un seguimiento del consumo de recursos y el número de solicitudes generado por cada inquilino. Después, cobrará a sus clientes en consecuencia.
  • Clúster dedicado: cuando un clúster está dedicado a un único inquilino, es fácil cobrar los costos de los recursos de Azure al cliente. El costo total de propiedad depende de muchos factores, entre los que se incluyen el número y el tamaño de las máquinas virtuales, los costos de redes debidos al tráfico de red, las direcciones IP públicas, los equilibradores de carga, los servicios de almacenamiento, como los discos administrados o las instancia de Azure Files usados por la solución de inquilino, etc. Puede etiquetar un clúster de AKS y sus recursos en el grupo de recursos del nodo para facilitar las operaciones de cobro de costos. Para más información, consulte Adición de etiquetas al clúster.
  • Grupo de nodos dedicado: puede aplicar una etiqueta de Azure a un grupo de nodos nuevo o existente que esté dedicado a un único inquilino. Las etiquetas aplicadas a un grupo de nodos se aplican a cada nodo del grupo y se conservan de una actualización a otra. También se aplican etiquetas a los nuevos nodos que se agregan a un grupo durante las operaciones de escalado horizontal. Agregar una etiqueta puede ayudar con tareas como el seguimiento de directivas o el cobro de los costos. Para más información, consulte Uso de etiquetas de Azure en Azure Kubernetes Service (AKS).
  • Otros recursos: puede usar etiquetas para asociar los costos de los recursos dedicados a un inquilino determinado. Específicamente, puede etiquetar direcciones IP públicas, archivos y discos mediante un manifiesto de Kubernetes. Las etiquetas establecidas de esta manera mantendrán los valores de Kubernetes, incluso si las actualiza más adelante mediante otro método. Cuando las direcciones IP públicas, los archivos o los discos se quitan a través de Kubernetes, también se eliminan las etiquetas establecidas por Kubernetes. Las etiquetas de estos recursos de las que Kubernetes no realiza el seguimiento no se ven afectadas. Para más información, consulte Adición de etiquetas mediante Kubernetes.

Puede usar herramientas de código abierto, como KubeCost, para supervisar y controlar el costo de un clúster de AKS. La asignación de costos se puede limitar a una implementación, un servicio, una etiqueta, un pod y un espacio de nombres, lo que le proporcionará flexibilidad en la forma de cargar o mostrar a los usuarios del clúster. Para más información, consulte Gobernanza de costos con Kubecost.

Para obtener más información sobre la medición, asignación y optimización de los costos de una aplicación multiinquilino, consulte Enfoques de arquitectura para la administración y asignación de costos en una solución multiinquilino. Para obtener instrucciones generales sobre la optimización de costos, consulte el artículo del Marco de buena arquitectura de Azure Información general sobre el pilar de optimización de costos.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Pasos siguientes

Revise Recursos para arquitectos y desarrolladores de soluciones multiinquilino.