Azure Kubernetes Service (AKS) simplifica la implementación de un clúster de Kubernetes administrado en Azure descargando la sobrecarga operativa en la plataforma en la nube de Azure. Dado que AKS es un servicio de Kubernetes hospedado, Azure controla tareas críticas, como la supervisión y el mantenimiento del estado y el plano de control.
Los clústeres de AKS se pueden compartir entre varios inquilinos en distintos escenarios y maneras. En algunos casos, diversas aplicaciones se pueden ejecutar en el mismo clúster. En otros casos, varias instancias de la misma aplicación se pueden ejecutar en el mismo clúster compartido, una para cada inquilino. El término multiinquilino describe con frecuencia todos estos tipos de uso compartido. 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 arrendamiento.
En este artículo se describen algunas de las características de AKS que puede usar al compilar sistemas multiinquilino. Para obtener instrucciones generales y procedimientos recomendados para la multiinquilino de Kubernetes, consulte multiinquilino en la documentación de Kubernetes.
Tipos multiinquilino
El primer paso para determinar cómo compartir un clúster de AKS en varios inquilinos es evaluar los patrones y las herramientas que están disponibles para su uso. En general, el multiinquilino en clústeres de Kubernetes se divide en dos categorías principales, pero muchas variaciones siguen siendo posibles. La documentación de Kubernetes describe dos casos de uso comunes para la multiinquilino: varios equipos y varios clientes.
Varios equipos
Una forma común de multiinquilino 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 u 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 de plataforma como servicio (PaaS) en Azure.
En este escenario, los miembros de los equipos suelen tener acceso directo a los recursos de Kubernetes a través de herramientas, como kubectl. O bien, los miembros tienen acceso indirecto a través de controladores de GitOps, como Flux y Argo CD, o a través de 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 multiinquilino suele implicar a un proveedor de software como servicio (SaaS). O bien, un proveedor de servicios ejecuta varias instancias de una carga de trabajo, que se consideran inquilinos independientes, para sus clientes. En este escenario, los clientes no tienen acceso directo al clúster de AKS, pero solo tienen acceso a su aplicación. Además, ni siquiera saben que su aplicación se ejecuta en Kubernetes. La optimización de costos suele ser una preocupación crítica. Los proveedores de servicios usan directivas de Kubernetes, como cuotas de recursos y 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 a los que normalmente se hace referencia como inquilinos de . Esta definición incluye clústeres de Kubernetes que comparten diferentes equipos o divisiones dentro de una organización. También contiene clústeres que comparten instancias por cliente de una aplicación SaaS.
El multiinquilino 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, un equipo podría usar más de su cuota justa de recursos. Los administradores pueden usar cuotas de recursos para solucionar este problema.
En función del nivel de seguridad que proporciona el aislamiento, puede distinguir entre multiinquilino suave y duro.
- El multiinquilino suave es adecuado dentro de una sola empresa en la que los inquilinos son diferentes equipos o departamentos que confían entre sí. En este escenario, el aislamiento tiene como objetivo garantizar la integridad de la carga de trabajo, organizar los recursos del clúster en diferentes grupos de usuarios internos y defenderse contra posibles ataques de seguridad.
- La multiinquilino duro describe escenarios en los que los inquilinos heterogéneos no confían entre sí, a menudo desde perspectivas de seguridad y uso compartido de recursos.
Al planear la compilación de un clúster de AKS multiinquilino, debe tener en cuenta las capas de aislamiento de recursos y multiinquilino que proporciona Kubernetes, entre las que se incluyen:
- Clúster
- Namespace
- Grupo de nodos o nodo
- Vaina
- Contenedor
Además, debe tener en cuenta las implicaciones de seguridad de compartir distintos recursos entre varios inquilinos. Por ejemplo, puede reducir el número de máquinas necesarias en el clúster mediante la programación de pods de distintos inquilinos en el mismo nodo. Por otro lado, es posible que tenga que evitar que se intercalen cargas de trabajo específicas. 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 podrían 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. Después, puede usar de control de acceso basado en rol (RBAC) de Kubernetes y directivas de red para aplicar el aislamiento de inquilinos. Por ejemplo, en el diagrama siguiente se 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.
Hay varias maneras de diseñar y compilar soluciones multiinquilino con AKS. Cada uno de estos métodos incluye su propio conjunto de inconvenientes, en términos de implementación de 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 inquilino en los planos de datos y control, en función de sus requisitos.
Aislamiento del plano de control
Si tiene aislamiento en el nivel del plano de control, garantiza que los distintos inquilinos no puedan acceder a los recursos de los demás o que afecten 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 obtener 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. Puede usar espacios de nombres 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 el trabajo entre 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 riesgo de superposición de nombres.
- roles de RBAC y enlaces de rol son recursos con ámbito de espacio de nombres que los equipos pueden usar para limitar los usuarios y procesos de inquilinos para acceder a recursos y servicios solo en 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.
- cuotas de recursos para la CPU y la 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 cada aplicación de inquilino que se ejecute en un espacio de nombres independiente tenga los recursos que necesita para ejecutarse y evitar problemas ruidosos de vecinos, lo que puede afectar a otras aplicaciones de inquilino que comparten el mismo clúster.
- directivas de red son objetos con espacio de nombres que los equipos pueden adoptar para aplicar el tráfico de red permitido 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 cuentas de servicio de diferentes 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 del 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 en el 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:
- espacios de nombres
- controles de acceso de
- cuotas de
Aislamiento del plano de datos
El aislamiento del plano de datos garantiza que los pods y las cargas de trabajo de distintos inquilinos estén suficientemente aislados entre sí. Para obtener 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, a menudo quiere controlar qué componentes pueden comunicarse entre sí. De forma 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.
AKS proporciona dos maneras de implementar directivas de red:
- Azure tiene su implementación para las directivas de red, denominadas directivas de red de Azure.
- directivas de red de Calico es una solución de seguridad de red y red 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 IP permitidos y no permitidos. A continuación, estos pares se programan como reglas de filtro de iptables. Solo puede usar directivas de red de Azure con clústeres de AKS configurados con el complemento de red de Azure CNI
Para más información, consulte de aislamiento de red de
Aislamiento de almacenamiento
Azure proporciona un amplio conjunto de repositorios de datos paaS administrados, como azure SQL Database y azure Cosmos DBy 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 dedicado y un recurso de almacenamiento. Para obtener más información sobre diferentes estrategias y enfoques para administrar datos en un escenario multiinquilino, consulte Enfoques arquitectónicos para el almacenamiento y los datos en soluciones multiinquilino.
Las cargas de trabajo que se ejecutan en AKS también pueden usar volúmenes persistentes para almacenar datos. En Azure, puede crear volúmenes persistentes como recursos de Kubernetes compatibles con Azure Storage. Puede crear manualmente volúmenes de datos y asignarlos a pods directamente, o puede crearlos automáticamente mediante notificaciones de volumen persistente. AKS proporciona clases de almacenamiento integradas para crear volúmenes persistentes que Azure Disks, Azure Filesy compatibilidad con azure NetApp Files. Para obtener más información, consulte Opciones de almacenamiento para aplicaciones en AKS. Por motivos de seguridad y resistencia, debe evitar el uso del almacenamiento local en los nodos del agente a través de emptyDir y hostPath .
Cuando AKS clases de almacenamiento integradas no son una buena opción para uno o varios inquilinos, puede crear clases de almacenamiento personalizadas para satisfacer los requisitos de los distintos inquilinos. Estos requisitos incluyen el tamaño del volumen, la SKU de almacenamiento, un acuerdo 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 usarlo para aplicar etiquetas a cualquier volumen persistente que se cree en su espacio de nombres para cobrar sus costos. Para más información, consulte Uso de etiquetas de Azure en AKS.
Para obtener más información, consulte aislamiento de Storage en la documentación de Kubernetes.
Aislamiento de nodos
Puede configurar cargas de trabajo de inquilino para que se ejecuten en nodos de agente independientes para evitar problemas ruidosos de vecinos 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 los inquilinos que tienen requisitos estrictos para el aislamiento, la seguridad, el cumplimiento normativo y el rendimiento.
Puede usar taints, tolerations, etiquetas de nodo, selectores de nodosy afinidad de nodo para restringir los pods de los inquilinos para que se ejecuten solo en un conjunto determinado de nodos o grupos de nodos.
En general, AKS proporciona aislamiento de carga de trabajo en varios niveles, entre los que se incluyen:
- En el nivel de kernel, mediante la ejecución de cargas de trabajo de inquilino en máquinas virtuales ligeras (VM) en nodos de agente compartidos y mediante espacio aislado de pods en función de contenedores de Kata.
- En el nivel físico, al hospedar aplicaciones de inquilino en clústeres dedicados o grupos de nodos.
- En el 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 del 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 en el nivel de hardware. También puede crear grupos de nodos compartidos o por inquilino que admitan estándar federal de procesos de información (FIPS), máquinas virtuales confidencialeso cifrado basado en host.
Use el aislamiento de nodo para asociar y cobrar fácilmente el costo de un conjunto de nodos o un grupo de nodos a un único inquilino. Está estrictamente relacionado con el modelo de arrendamiento adoptado por la solución.
Para más información, consulte aislamiento de nodo en la documentación de Kubernetes.
Modelos de arrendamiento
AKS proporciona más tipos de aislamiento de nodo y modelos de arrendamiento.
Implementaciones automatizadas de un solo inquilino
En un modelo de implementación de un solo inquilino automatizado, se implementa un conjunto dedicado de recursos para cada inquilino, como se muestra en este ejemplo:
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 compilan mediante este modelo hacen un uso amplio de infraestructura como código (IaC). Por ejemplo, Bicep, Azure Resource Manager, Terraformo 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 usar el patrón de sellos de implementación de .
Ventajas de :
- 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 total entre los inquilinos de un nivel de seguridad, redes y consumo de recursos. Un atacante que administra para obtener el control de un contenedor solo tiene acceso a los contenedores y volúmenes montados que pertenecen a un único inquilino. Un modelo de arrendamiento de aislamiento completo es fundamental para algunos clientes con una elevada sobrecarga de cumplimiento normativo.
- Es poco probable que los inquilinos afecten al rendimiento del sistema del otro, por lo que evita problemas ruidosos vecinos. Esta consideración incluye el tráfico contra 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. Use la característica de tiempo de actividad de
tiempo de actividad para 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 podría ser una mejor solución para aquellos clientes con requisitos sólidos en términos de aislamiento de carga de trabajo. - Puede implementar actualizaciones y cambios progresivamente en todos 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 porque un único inquilino usa todos los recursos.
riesgos de :
- La rentabilidad es baja porque cada inquilino usa un conjunto dedicado de recursos.
- Es probable que el mantenimiento continuo sea lento porque necesita repetir las actividades de mantenimiento en varios clústeres de AKS, uno para cada inquilino. Considere la posibilidad de automatizar los procesos operativos y aplicar los cambios progresivamente a través de los entornos. Otras operaciones entre implementaciones, como informes y análisis en todo el patrimonio, también pueden resultar útiles. Asegúrese de planear cómo consultar y manipular 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 todos los recursos de Azure se comparten, incluido el clúster de AKS. En este contexto, solo tiene una infraestructura para implementar, supervisar y mantener. Todos los inquilinos usan el recurso, como se muestra en el diagrama siguiente:
ventajas:
- Este modelo es atractivo debido al menor costo de funcionamiento de una solución con componentes compartidos. Al usar este modelo de arrendamiento, 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. Estos cambios ayudan a mantener el tráfico que generan 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 pueden 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 nodos del agente. Base la configuración en el uso de recursos del sistema, como CPU y memoria. Como alternativa, puede escalar horizontalmente y escalar horizontalmente el número de pods y nodos de clúster en función de las métricas personalizadas. Por ejemplo, puede usar el número de solicitudes pendientes o las métricas de un sistema de mensajería externo que usa escalador automático basado en eventos basado en Kubernetes (KEDA).
- Asegúrese de separar los datos de cada inquilino e implementar medidas de seguridad para evitar la pérdida de datos entre distintos inquilinos.
- Asegúrese de realizar un seguimiento y asociar los costos de Azure a inquilinos individuales, en función de su uso real. Las soluciones que no son de Microsoft, como kubecost, pueden ayudarle a calcular y desglosar los costos en distintos equipos e inquilinos.
- El mantenimiento puede ser más sencillo con una sola implementación porque solo tiene que actualizar un conjunto de recursos de Azure y mantener una sola aplicación. Sin embargo, también puede ser más arriesgado porque 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 alcance los límites de escalado de recursos de Azure cuando tenga un conjunto compartido de recursos. Para evitar alcanzar un límite de cuota de recursos, puede 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 comparte algunos componentes de solución en todos los inquilinos e implementa recursos dedicados para inquilinos individuales. Por ejemplo, puede compilar 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:
Ventajas de :
- Las implementaciones con particiones horizontales pueden ayudarle a mitigar problemas ruidosos de vecinos. Tenga en cuenta este enfoque si identifica que la mayor parte de la carga de tráfico en 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 solo inquilino envía un gran número de solicitudes a la solución, el rendimiento de una base de datos podría verse afectado negativamente, pero las bases de datos y los componentes compartidos de otros inquilinos, como el nivel de aplicación, no se verán afectados.
riesgos de :
- Con una implementación con particiones horizontales, debe tener en cuenta la implementación y administración automatizadas de los componentes, especialmente los componentes que usa un solo inquilino.
- Este modelo podría no proporcionar el nivel de aislamiento necesario para los clientes que no pueden compartir recursos con otros inquilinos por motivos de cumplimiento o directiva interna.
Implementaciones con particiones verticales
Puede aprovechar las ventajas de los modelos de inquilino único y totalmente multiinquilino mediante un modelo híbrido que particiona verticalmente los inquilinos en varios clústeres de AKS o grupos de nodos. Este enfoque proporciona las siguientes ventajas sobre los dos modelos de arrendamiento anteriores:
- Puede usar una combinación de implementaciones multiinquilino 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. 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 distintas configuraciones. Esta técnica es más eficaz cuando tiene inquilinos distribuidos entre diferentes zonas geográficas.
Puede implementar diferentes variaciones de este modelo de arrendamiento. Por ejemplo, puede optar por ofrecer la solución multiinquilino con distintos niveles de funcionalidad a un costo diferente. El modelo de precios puede proporcionar varias SKU que proporcionan un nivel incremental de rendimiento y aislamiento en términos de uso compartido de recursos, rendimiento, red y segregación de datos. Tenga en cuenta los siguientes niveles:
- Nivel básico: las solicitudes de inquilino se sirven mediante una sola aplicación de Kubernetes multiinquilino que se comparte con otros inquilinos. Los datos se almacenan en una o varias bases de datos que comparten todos los inquilinos de nivel Básico.
- Nivel estándar: una aplicación dedicada de Kubernetes atiende las solicitudes de inquilino 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. 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 de nivel estándar.
- Nivel Premium: la aplicación de inquilino se ejecuta en un grupo de nodos dedicado o en un clúster de AKS para garantizar un Acuerdo de Nivel de Servicio superior, un mejor rendimiento y un mayor grado de aislamiento. Este nivel puede proporcionar un modelo de costo flexible basado en el número y la SKU de los nodos del agente que hospedan la aplicación de inquilino. Puede usar espacio aislado de pods como solución alternativa a clústeres dedicados o grupos de nodos para aislar distintas cargas de trabajo de inquilino.
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.
En el diagrama siguiente se 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.
Este modelo también puede ofrecer acuerdos de nivel de servicio diferentes para distintos niveles. Por ejemplo, el nivel básico puede ofrecer un tiempo de actividad de 99,9%, el nivel estándar puede ofrecer 99,95% tiempo de actividad y el nivel Premium puede ofrecer 99,99% tiempo de actividad. Puede implementar el Acuerdo de Nivel de Servicio superior mediante servicios y características que habilitan destinos de mayor disponibilidad.
Ventajas de :
- Dado que sigue compartiendo la infraestructura, todavía puede obtener algunas de las ventajas de costo de tener implementaciones multiinquilino compartidas. Puede implementar clústeres y grupos de nodos que se comparten entre varias aplicaciones de inquilino de nivel básico y de nivel estándar, que usan un tamaño de máquina virtual menos costoso para los nodos del 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 superior y un número máximo de réplicas y nodos de pod a un precio superior.
- Puede ejecutar servicios del sistema, como CoreDNS, konnectivityo controlador de entrada de Azure Application Gateway, en un grupo de nodos en modo de sistema dedicado. Puede usar taints, tolerations, etiquetas de nodo, selectores de nodosy afinidad de nodo para ejecutar una aplicación de inquilino en uno o varios grupos de nodos en modo de usuario.
- Puede usar taints, tolerations, etiquetas de nodo, selectores de nodo y afinidad de nodo para ejecutar recursos compartidos. Por ejemplo, puede tener un controlador de entrada o un sistema de mensajería en un grupo de nodos dedicado que tenga un tamaño de máquina virtual específico, una configuración del escalador automático y una compatibilidad con zonas de disponibilidad.
riesgos de :
- 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 inquilino único.
- Necesita una estrategia coherente y un único panel de cristal, o 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 que generan las aplicaciones de inquilino, puede habilitar el escalador automático de clústeres de para escalar los nodos del agente de AKS. El escalado automático ayuda a los sistemas a mantener la capacidad de respuesta en las siguientes circunstancias:
- La carga del tráfico aumenta durante horas de trabajo específicas o períodos del año.
- Las cargas pesadas compartidas o de inquilino se implementan en un clúster.
- Los nodos del agente no están disponibles debido a interrupciones de una zona de disponibilidad.
Al habilitar el escalado automático para un grupo de nodos, especifique 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 la escasez de recursos, como la CPU y la memoria.
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 pods automáticamente en función de las demandas de recursos. HorizontalPodAutoscaler escala automáticamente el número de réplicas de pod en función del uso de cpu o memoria o métricas personalizadas. Mediante KEDA, puede impulsar el escalado de cualquier contenedor de Kubernetes en función del número de eventos de sistemas externos, como Azure Event Hubs o Azure Service Bus, que usan las aplicaciones de inquilino.
escalador automático de pods verticales (VPA) permite una administración eficaz de recursos para pods. Al ajustar la CPU y la memoria asignadas a los pods, el VPA le ayuda a reducir el número de nodos necesarios para ejecutar aplicaciones de inquilino. Tener menos nodos reduce el costo total de propiedad y le ayuda a evitar problemas ruidosos vecinos.
Asigne grupos de reservas de capacidad a los grupos de nodos para proporcionar una mejor asignación y aislamiento de recursos para distintos inquilinos.
Mantenimiento
Para reducir el riesgo de tiempo de inactividad que podría afectar a las aplicaciones de inquilino durante las actualizaciones del clúster o del grupo de nodos, programe AKS mantenimiento planeado durante las horas de poca actividad. Programe 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 para minimizar 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 intervalo de tiempo en un día específico. Todas las operaciones de mantenimiento se producen durante las ventanas programadas.
Seguridad
En las secciones siguientes se describen los procedimientos recomendados de seguridad para soluciones multiinquilino con AKS.
Acceso al clúster
Al compartir un clúster de AKS entre varios equipos de una organización, debe implementar el principio de de privilegios mínimos para aislar distintos inquilinos entre sí. En concreto, debe asegurarse de que los usuarios solo tienen acceso a sus espacios de nombres y recursos de Kubernetes al usar herramientas como kubectl, Helm, Fluxo Argo CD.
Para obtener más información sobre la autenticación y la autorización con AKS, consulte los siguientes artículos:
- opciones de acceso e identidad de para AKS
- integración de Microsoft Entra administrada por AKS
- control de acceso basado en rol de Kubernetes con el identificador de Microsoft Entra en AKS
Identidad de carga de trabajo
Si hospeda varias aplicaciones de inquilino en un único clúster de AKS y cada aplicación está en un espacio de nombres independiente, cada carga de trabajo debe usar una cuenta de servicio de Kubernetes diferente y credenciales para acceder a los servicios de Azure de bajada. Las cuentas de servicio son uno de los tipos de usuario principales de Kubernetes. La API de Kubernetes contiene y administra cuentas de servicio. Las credenciales de la cuenta de servicio se almacenan como secretos de Kubernetes, por lo que los pods autorizados pueden usarlos 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 que se implementan en clústeres de AKS pueden usar credenciales de aplicación de Microsoft Entra para acceder a los recursos protegidos por el identificador de Microsoft Entra, como Azure Key Vault y Microsoft Graph. id. 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 aislado de pods
AKS incluye un mecanismo denominado espacio aislado de pod 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 aislado de 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 los requisitos normativos, del sector o de cumplimiento de gobernanza, como el Estándar de seguridad de datos del sector de tarjetas 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).
Al implementar aplicaciones en clústeres o grupos de nodos independientes, puede aislar fuertemente las cargas de trabajo de inquilino de diferentes equipos o clientes. El uso de varios clústeres y grupos de nodos puede ser adecuado para los requisitos de aislamiento de muchas organizaciones y soluciones SaaS, pero hay escenarios en los que un único clúster con grupos de nodos de máquina virtual compartidos es más eficaz. Por ejemplo, puede usar un único clúster al ejecutar pods que no son de confianza y de confianza en el mismo nodo o colocar DaemonSets y contenedores con privilegios en el mismo nodo para una comunicación local más rápida y agrupación funcional. pod sandboxing puede ayudarle a aislar fuertemente 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 que se vuelva a compilar el código o que se produzcan otros problemas de compatibilidad, pero el espacio aislado de pods en AKS puede ejecutar cualquier contenedor sin modificar dentro de un límite mejorado de máquina virtual de seguridad.
El espacio aislado de pods en AKS se basa en
Para obtener más información, consulte:
- espacio aislado de pods con AKS
- compatibilidad con contenedores aislados de máquinas virtuales kata en AKS para el espacio aislado de pods
Host dedicado de Azure
azure Dedicated Host es un servicio que proporciona servidores físicos dedicados a una sola suscripción de Azure y proporcionan aislamiento de hardware en el nivel de servidor físico. Puede aprovisionar estos hosts dedicados dentro de una región, zona de disponibilidad y dominio de error, y puede colocar máquinas virtuales directamente en los hosts aprovisionados.
Hay varias ventajas para usar Azure Dedicated Host con AKS, entre las que se incluyen:
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 infraestructura de almacenamiento subyacente y de red 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.
El host dedicado de Azure puede ayudar a los proveedores de SaaS a garantizar que las aplicaciones de inquilino cumplen los requisitos normativos, del sector y de cumplimiento de gobernanza para proteger la información confidencial. Para más información, consulte Incorporación de un host dedicado de Azure a un clúster de AKS.
Karpenter
Karpenter es un proyecto de administración del ciclo de vida de nodo de código abierto creado para Kubernetes. Agregar Karpenter a un clúster de Kubernetes puede mejorar la eficacia y el costo de ejecutar cargas de trabajo en ese clúster. Karpenter busca pods que el programador de Kubernetes marca como no programado. También aprovisiona y administra dinámicamente los nodos que pueden cumplir los requisitos del pod.
Karpenter proporciona un control específico sobre el aprovisionamiento de nodos y la colocación de cargas de trabajo en un clúster administrado. Este control mejora la multiinquilino mediante la optimización de la asignación de recursos, lo que garantiza el aislamiento entre las aplicaciones de cada inquilino y reduce los costos operativos. Al compilar una solución multiinquilino en AKS, Karpenter proporciona funcionalidades útiles para ayudarle a administrar diversos requisitos de aplicación para admitir distintos inquilinos. Por ejemplo, es posible que necesite algunas aplicaciones de inquilinos para ejecutarse en grupos de nodos optimizados para GPU y otros para ejecutarse en grupos de nodos optimizados para memoria. Si la aplicación requiere una latencia baja para el almacenamiento, puede usar Karpenter para indicar que un pod requiere un nodo que se ejecuta en una zona de disponibilidad específica para que pueda colocar el nivel de almacenamiento y aplicación.
AKS habilita el aprovisionamiento automático de nodos en clústeres de AKS a través de Karpenter. La mayoría de los usuarios deben usar el modo de aprovisionamiento automático de nodos para habilitar Karpenter como un complemento administrado. Para obtener más información, consulte aprovisionamiento automático de nodos. Si necesita una personalización más avanzada, puede elegir autohospedar Karpenter. Para obtener más información, consulte ladel proveedor de AKS Karpenter de
Máquinas virtuales confidenciales
Puede usar máquinas virtuales confidenciales para agregar uno o varios grupos de nodos al clúster de AKS para abordar los requisitos estrictos de aislamiento, privacidad y seguridad de los inquilinos. máquinas virtuales confidenciales usar un entorno de ejecución de confianza basado en hardware . virtualización de AMD Secure Encrypted Encrypted: paginación anidada segura (SEV-SNP) las máquinas virtuales confidenciales deniegan el hipervisor y otro código de administración de host acceso a la memoria y el estado de la máquina virtual, lo que agrega una capa de defensa y protección en profundidad contra el acceso al operador. Para obtener más información, consulte Uso de máquinas virtuales confidenciales en un clúster de AKS.
Estándares federales del proceso de información (FIPS)
fiPS 140-3 es un estándar gubernamental de ESTADOS Unidos que define los requisitos mínimos de seguridad para los módulos criptográficos en los productos y sistemas de tecnología de la información. Al habilitar 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. cumplimiento de fiPS garantiza el uso de módulos criptográficos validados para cifrado, hash y otras operaciones relacionadas con la seguridad. Con los grupos de nodos de AKS habilitados para FIPS, puede cumplir los requisitos de cumplimiento normativo y del sector mediante el uso 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 obtener más información, consulte Habilitar FIPS para grupos de nodos de AKS.
Traiga sus propias claves (BYOK) con discos de Azure
Azure Storage cifra todos los datos de una cuenta de almacenamiento en reposo, incluidos el sistema operativo y los discos de datos de un clúster de AKS. De forma predeterminada, los datos se cifran con claves administradas por Microsoft. Para obtener más control sobre las claves de cifrado, puede proporcionar claves administradas por el cliente para usarlas para el cifrado en reposo del sistema operativo y los discos de datos de los clústeres de AKS. Para obtener más información, consulte:
Cifrado basado en host
de cifrado basado en host en AKS refuerza aún más el aislamiento, la privacidad y la seguridad de la carga de trabajo del inquilino. 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 del sistema operativo efímeros se cifran en reposo con claves administradas por la plataforma al habilitar el cifrado de un extremo a otro.
En AKS, el sistema operativo y los discos de datos usan el cifrado del lado servidor con claves administradas por la plataforma de forma predeterminada. 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 para cifrar la clave de protección de datos mediante el cifrado de sobres, también conocido como encapsulado. 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. Los datos de cada inquilino en las memorias caché del disco de datos y del sistema operativo se cifran en reposo con claves administradas por el cliente o administradas por la plataforma, en función del tipo de cifrado de disco seleccionado. Para obtener más información, consulte:
- cifrado basado en host en AKS
- BYOK con discos de Azure en AKS
- cifrado del lado servidor de Azure Disk Storage
Gestión de redes
En las secciones siguientes se describen los procedimientos recomendados de red para soluciones multiinquilino con AKS.
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 en varios equipos de una organización, proteja el acceso al plano de control mediante una de las siguientes soluciones.
Clústeres de AKS privados
Mediante el uso de un clúster de AKS privado, puede asegurarse de que el tráfico de red entre el servidor de API y los grupos de nodos permanece dentro de la red virtual. En un clúster de AKS privado, el plano de control o el servidor de API tiene una dirección IP interna que solo es accesible a través de un punto de conexión privado de Azure , que se encuentra 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 a través del punto de conexión privado. Para obtener más información, consulte Creación de un clúster de AKS privado.
Intervalos de direcciones IP autorizadas
La segunda opción para mejorar la seguridad del clúster y minimizar los ataques es usar intervalos de 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 IP y intervalos de Inter-Domain enrutamiento sin clases (CIDR). Cuando se usan direcciones IP autorizadas, todavía se exponen públicamente, pero el acceso está limitado a un conjunto de intervalos. Para obtener más información, consulte Acceso seguro al servidor de API mediante intervalos de direcciones IP autorizados en AKS.
Integración de Private Link
Puede usar integración del servicio Private Link 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 más información sobre cómo configurar Private Link para una solución multiinquilino hospedada en Azure, consulte Multiinquilino y Private Link.
Servidores proxy inversos
Un
- controlador de entrada NGINX es un servidor proxy inverso popular que admite características avanzadas, como el equilibrio de carga, la terminación SSL y el enrutamiento de nivel 7.
- proveedor de entrada de Kubernetes de Traefik es un controlador de entrada de Kubernetes que se puede usar para administrar el acceso a los servicios de clúster mediante la compatibilidad con la especificación de entrada.
- controlador de entrada de Kubernetes haProxy 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.
- controlador de entrada de Azure Application Gateway (AGIC) es una aplicación kubernetes, lo que permite a los clientes de AKS usar una instancia de Application Gateway nativa de Azure Application Gateway L7 para exponer 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 ayudar a proteger y controlar las solicitudes entrantes a 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 los tiempos de espera para las aplicaciones de inquilino, defina una directiva de escalado automático para que el número de pods del controlador de entrada pueda expandirse al instante y contraerse para que coincidan 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 escalabilidad y segregación.
Al usar el controlador de entrada de Azure Application Gateway (AGIC), considere la posibilidad de implementar los siguientes procedimientos recomendados:
- Configure la puerta de enlace de aplicaciones de que usa el controlador de entrada para escalado automático. Con el escalado automático habilitado, las SKU de Application Gateway y firewall de aplicaciones web (WAF) v2 se escalan horizontalmente o en función de los requisitos de tráfico de la aplicación. Este modo proporciona una mayor elasticidad a la aplicación y elimina la necesidad de adivinar el tamaño de la puerta de enlace de aplicaciones o el recuento de instancias. Este modo también le ayuda a ahorrar costos al no requerir que la puerta de enlace se ejecute en la capacidad aprovisionada máxima para la carga máxima de tráfico esperada. Debe especificar un recuento mínimo de instancias (y opcionalmente máximo).
- Considere la posibilidad de implementar varias instancias del AGIC, cada una asociada a una puerta de enlace de aplicaciones de independiente, cuando el número de aplicaciones de inquilino supera el cantidad máxima de sitios. Suponiendo que cada aplicación de inquilino se ejecuta en un espacio de nombres dedicado, use compatibilidad con varios espacios de nombres para distribuir las aplicaciones de inquilino en más instancias de AGIC.
Integración con Azure Front Door
Azure Front Door es un equilibrador de carga global de nivel 7 y una red moderna de entrega de contenido en la nube (CDN) 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 respuestas, WAF en el perímetro, el enrutamiento basado en direcciones URL, la reescritura y las redirecciones que puede usar al exponer aplicaciones multiinquilino hospedadas en AKS a la red pública de Internet.
Por ejemplo, puede 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.
Puede configurar Azure Front Door para modificar el encabezado de host de origen de solicitud de para que coincida con el nombre de dominio de la aplicación back-end. El encabezado Host original enviado por el cliente se propaga a través del encabezado X-Forwarded-Host y el código de la aplicación multiinquilino puede usar esta información para asignar la solicitud entrante al inquilino correcto.
Azure Web Application Firewall, en Azure Front Door, proporciona protección centralizada para las aplicaciones web. Azure Web Application Firewall puede ayudarle a 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, a través de un origen interno del equilibrador de carga, mediante Private Link. Para más información, consulte Conexión de Azure Front Door Premium a un origen de equilibrador de carga interno con Private Link.
Conexiones salientes
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 de traducción de direcciones de red de origen (SNAT). puertos SNAT generar 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 de AKS compartido, puede 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: de forma predeterminada, AKS aprovisiona un equilibrador de carga de SKU estándar 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 si se requieren saltos adicionales para la salida. De forma predeterminada, el equilibrador de carga público se crea con una dirección IP pública predeterminada que las reglas de salida de usar. Las reglas de salida permiten definir explícitamente SNAT para un equilibrador de carga estándar público. Esta configuración permite usar las direcciones IP públicas del equilibrador de carga para proporcionar conectividad saliente a Internet para las instancias de back-end. Cuando sea necesario, para evitar agotamiento de puertos SNAT, puede configurar las reglas de salida del equilibrador de carga público para usar más direcciones IP públicas. Para obtener más información, consulte Uso de la dirección IP de front-end de un equilibrador de carga para la salida a través de 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 aplicaciones de inquilino. Nat Gateway permite hasta 64 512 flujos de tráfico UDP y TCP salientes por dirección IP pública, con un máximo de 16 direcciones IP. Para evitar el riesgo de agotamiento de puertos SNAT cuando se usa una puerta de enlace NAT 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 paramultiinquilino.
- ruta definida por el usuario (UDR): puede personalizar la ruta de salida de un clúster de AKS para admitir escenarios de red personalizados, como aquellos que no permiten direcciones IP públicas y requieren que el clúster se site detrás de una aplicación virtual de red (NVA). Al configurar un clúster para enrutamiento definido por el usuario, AKS no configura automáticamente las rutas de acceso de salida. Debe completar la configuración de salida. Por ejemplo, enruta el tráfico de salida a través de una Azure Firewall. Debe implementar el clúster de AKS en una red virtual existente con una subred que configuró anteriormente. Cuando no se usa una arquitectura de equilibrador de carga estándar, debe establecer una salida explícita. 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 equilibrador de carga estándar o al dispositivo.
Monitorizació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 calcular los desgloses de costos en espacios de nombres individuales. Use Azure Monitor para supervisar el estado y el rendimiento de AKS. Incluye la recopilación de registros y métricas de , análisis de telemetría y visualizaciones de datos recopilados para identificar tendencias y configurar alertas que le notifican de forma proactiva los problemas críticos. Puede habilitar de container Insights para expandir esta supervisión.
También puede adoptar herramientas de código abierto, como prometheus y Grafana, que se usan ampliamente para la supervisión de Kubernetes. O bien, puede adoptar otras herramientas que no son de Microsoft para supervisar y observar.
Costos
La gobernanza de costos es el proceso continuo de implementación de directivas para controlar los costos. En el contexto de Kubernetes, hay varios métodos que las organizaciones pueden usar para controlar y optimizar los costos. Estos métodos incluyen el uso de herramientas nativas de Kubernetes para administrar y controlar el uso y el consumo de recursos, y supervisar y optimizar proactivamente 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 sigue para cobrar las cuotas a los inquilinos depende del modelo de arrendamiento que adopte la solución. En la lista siguiente se describen los modelos de arrendamiento con más detalle:
- Multiinquilino completo: 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 que genera cada inquilino. A continuación, usted cobra 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, como el número y el tamaño de las máquinas virtuales, los costos de red del tráfico de red, las direcciones IP públicas, los equilibradores de carga y los servicios de almacenamiento, como discos administrados o archivos de Azure que usa la solución de inquilino. Puede etiquetar un clúster de AKS y sus recursos en el grupo de recursos del nodo para facilitar las operaciones de carga de costos. Para obtener más información, consulte Agregar etiquetas al clúster.
- Grupo de nodos dedicados: puede aplicar una etiqueta de Azure a un grupo de nodos nuevo o existente dedicado a un único inquilino. Las etiquetas se aplican a cada nodo del grupo de nodos y se conservan a través de las actualizaciones. Las etiquetas también se aplican a los nuevos nodos que se agregan a un grupo de nodos durante las operaciones de escalabilidad horizontal. Agregar una etiqueta puede ayudar con tareas como el seguimiento de directivas o la carga de costos. Para obtener más información, consulte Adición de etiquetas a grupos de nodos.
- Otros recursos: puede usar etiquetas para asociar los costos de los recursos dedicados a un inquilino determinado. En concreto, puede etiquetar direcciones IP públicas, archivos y discos mediante un manifiesto de Kubernetes. Las etiquetas establecidas de esta manera mantienen los valores de Kubernetes, incluso si los actualiza más adelante mediante otro método. Cuando se quitan las direcciones IP públicas, los archivos o los discos a través de Kubernetes, se quitan las etiquetas que se establecen en Kubernetes. Las etiquetas de los recursos a los que Kubernetes no realiza el seguimiento siguen sin verse afectados. Para obtener más información, consulte Agregar etiquetas mediante Kubernetes.
Puede usar herramientas de código abierto, como KubeCost, para supervisar y controlar el costo de un clúster de AKS. Puede definir el ámbito de la asignación de costos a una implementación, un servicio, una etiqueta, un pod y un espacio de nombres, lo que le ofrece flexibilidad en la forma en que se recargó o se muestran los usuarios del clúster. Para obtener 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 arquitectónicos 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 Azure Well-Architected Framework, Información general sobre el pilar optimización de costos.
Gobernanza
Cuando varios inquilinos comparten la misma infraestructura, administrar la privacidad de los datos, el cumplimiento y los requisitos normativos pueden complicarse. Debe implementar medidas de seguridad sólidas y directivas de gobernanza de datos. Los clústeres de AKS compartidos presentan un mayor riesgo de vulneraciones de datos, acceso no autorizado y incumplimiento de las normativas de protección de datos. Cada inquilino puede tener requisitos de gobernanza de datos únicos y directivas de cumplimiento, lo que dificulta la seguridad y la privacidad de los datos.
Microsoft Defender para contenedores es una solución de seguridad de contenedores nativa de la nube que proporciona funcionalidades de detección y protección de amenazas para entornos de Kubernetes. Mediante defender para contenedores, puede mejorar la posición de cumplimiento y gobernanza de datos al hospedar varios inquilinos en un clúster de Kubernetes. Use Defender for Containers para ayudar a proteger los datos confidenciales, detectar y responder a amenazas mediante el análisis del comportamiento de los contenedores y el tráfico de red, y cumplir los requisitos normativos. Proporciona funcionalidades de auditoría, administración de registros y generación de informes para demostrar el cumplimiento de los reguladores y auditores.
Colaboradores
Microsoft mantiene este artículo. Originalmente fue escrito por los siguientes colaboradores.
Autor principal:
- Paolo Salvatori | Ingeniero principal de clientes
Otros colaboradores:
- Bohdan Cherchyk | Ingeniero superior de clientes
- John Downs | Ingeniero principal de software
- Chad Kittel | Ingeniero principal de software
- de Arsen Vladimirskiy | Ingeniero principal de clientes