Arquitectura

Debido a esta infraestructura compartida, el CNI es el mismo que el configurado en el clúster anfitrión. Lo mismo ocurre con el almacenamiento disponible, donde las Clases de Almacenamiento y los Volúmenes son los del clúster anfitrión.

Para proporcionar el aislamiento necesario, K3k aprovecha las Políticas de Red.

En el modo compartido, K3k aprovecha los 'ResourceQuotas' y 'LimitRanges' de Kubernetes para gestionar la compartición de recursos y hacer cumplir los límites. Dado que todas las cargas de trabajo del clúster virtual se ejecutan dentro del mismo espacio de nombres en el clúster anfitrión, se aplican ResourceQuotas a este espacio de nombres para limitar los recursos totales consumidos por un clúster virtual. LimitRanges se utilizan para establecer solicitudes y límites de recursos predeterminados para los pods, asegurando que las cargas de trabajo tengan asignaciones razonables de recursos incluso si no las especifican explícitamente.

A cada pod en un clúster virtual se le asigna un nombre único que incorpora el nombre del pod, el espacio de nombres y el nombre del clúster. Esto previene colisiones de nombres en el espacio de nombres del clúster anfitrión compartido.

Es importante entender que los ResourceQuotas se aplican a nivel de espacio de nombres. Esto significa que todos los pods dentro de un clúster virtual comparten la misma cuota. Mientras esto proporciona límites generales para el clúster virtual, también significa que la asignación de recursos es dinámica. Si una carga de trabajo no está utilizando toda su asignación de recursos, otras cargas de trabajo dentro del mismo clúster virtual pueden utilizar esos recursos, incluso si pertenecen a diferentes despliegues o servicios.

Este intercambio dinámico puede ser tanto un beneficio como un desafío. Permite una utilización eficiente de los recursos, pero también puede llevar a un rendimiento impredecible si las cargas de trabajo tienen demandas de recursos variables. Además, este enfoque dificulta garantizar un aislamiento estricto de recursos entre cargas de trabajo dentro del mismo clúster virtual.

El aislamiento entre clústeres virtuales en modo compartido depende en gran medida de las Políticas de Red de Kubernetes. Las Políticas de Red definen reglas que controlan el tráfico de red permitido hacia y desde los pods. K3k configura las Políticas de Red para asegurar que los pods en un clúster virtual no puedan comunicarse con los pods en otros clústeres virtuales o con los pods en el clúster anfitrión, proporcionando una base sólida para el aislamiento de red.

Si bien las Políticas de Red ofrecen capacidades de aislamiento robustas, es importante entender sus características:

K3k también utiliza la Admisión de Seguridad de Pods de Kubernetes (PSA) para hacer cumplir políticas de seguridad dentro de los clústeres virtuales basadas en los Estándares de Seguridad de Pods (PSS). Los PSS definen diferentes niveles de seguridad para los pods, restringiendo qué acciones pueden realizar los pods. Al configurar PSA para hacer cumplir un nivel específico de PSS (por ejemplo, baseline o restricted) para un clúster virtual, K3k asegura que los pods se adhieran a las mejores prácticas de seguridad establecidas y evita que utilicen características privilegiadas o realicen operaciones potencialmente peligrosas.

Los aspectos clave de la integración de PSA incluyen:

La arquitectura de modo compartido está diseñada con la seguridad en mente. K3k emplea múltiples capas de controles de seguridad, incluyendo Políticas de Red y PSA, para proteger clústeres virtuales y el clúster anfitrión. Mientras que el modelo de espacio de nombres compartido requiere una configuración y gestión cuidadosas, estos controles proporcionan una base de seguridad robusta para ejecutar cargas de trabajo en un entorno multi-inquilino. K3k evalúa y mejora continuamente sus mecanismos de seguridad para abordar amenazas en evolución y garantizar el más alto nivel de protección para sus usuarios.

Los clústeres virtuales en modo virtual tienen cada uno su propia configuración de red independiente gestionada por sus respectivos servidores K3s. Cada clúster virtual ejecuta su propio plugin CNI, configurado dentro de su servidor K3s, proporcionando un completo aislamiento de red de otros clústeres virtuales y del clúster anfitrión. Mientras que las redes de clústeres virtuales operan en última instancia sobre la infraestructura de red del clúster anfitrión, la configuración de red y la gestión del tráfico son completamente separadas.

La compartición de recursos en modo virtual se gestiona aplicando límites de recursos a los pods que componen el clúster virtual (tanto el pod del servidor K3s como los pods de agente K3s). A cada pod se le asigna una cantidad específica de CPU, memoria y otros recursos. Las cargas de trabajo que se ejecutan dentro del clúster virtual utilizan estos recursos asignados. Esto significa que el clúster virtual en su conjunto tiene un grupo de recursos definido determinado por los límites en sus pods constituyentes.

Este enfoque proporciona una forma clara y directa de controlar los recursos disponibles para cada clúster virtual. Sin embargo, requiere una planificación cuidadosa de los recursos para garantizar que cada clúster virtual tenga suficiente capacidad para sus cargas de trabajo.

El modo virtual ofrece un fuerte aislamiento debido a los clústeres K3s dedicados desplegados para cada clúster virtual. Debido a que cada clúster virtual ejecuta su propio plano de control y nodos de trabajo separados, las cargas de trabajo están efectivamente aisladas entre sí y del clúster anfitrión. Esta arquitectura minimiza el riesgo de que un clúster virtual impacte a otros o al clúster anfitrión.

La seguridad en modo virtual se beneficia del aislamiento inherente proporcionado por los clústeres K3s separados. Sin embargo, las mejores prácticas de seguridad estándar de Kubernetes siguen aplicándose, y K3k enfatiza un enfoque de seguridad en capas. Mientras que los pods del servidor K3s a menudo se ejecutan con privilegios elevados (debido a la naturaleza de su función, que requiere acceso a recursos del sistema), K3k recomienda minimizar estos privilegios siempre que sea posible y adherirse al principio de menor privilegio. Esto se puede lograr configurando cuidadosamente las capacidades necesarias en lugar de depender del completo modo privileged. Se puede encontrar más información sobre las mejores prácticas de seguridad de K3s en la documentación oficial de K3s: https://docs.k3s.io/security (Este enlace proporciona orientación general sobre seguridad, incluyendo discusiones sobre capacidades y otros temas relevantes).

Actualmente, la seguridad en modo virtual tiene un riesgo de escalada de privilegios ya que los pods del servidor se ejecutan con privilegios elevados debido a la naturaleza de su función, que requiere acceso a recursos del sistema.