En esta página se explica la multitenencia de clústeres en Google Kubernetes Engine (GKE). Esto incluye los clústeres compartidos por diferentes usuarios de una misma organización y los clústeres compartidos por instancias por cliente de una aplicación de software como servicio (SaaS). Los clústeres con varios propietarios son una alternativa a la gestión de muchos clústeres con un solo propietario.
En esta página también se resumen las funciones de Kubernetes y GKE que se pueden usar para gestionar clústeres multiarrendatario.
¿Qué es la arquitectura multicliente?
Un clúster multiinquilino se comparte entre varios usuarios o cargas de trabajo, a los que se denomina "inquilinos". Los operadores de clústeres multiarrendatario deben aislar a los arrendatarios entre sí para minimizar los daños que un arrendatario malicioso o cuya cuenta se haya visto comprometida pueda causar en el clúster y en otros arrendatarios. Además, los recursos del clúster deben asignarse de forma equitativa entre los inquilinos.
Cuando planifiques una arquitectura multiarrendatario, debes tener en cuenta las capas de aislamiento de recursos en Kubernetes: clúster, espacio de nombres, nodo, pod y contenedor. También debes tener en cuenta las implicaciones de seguridad de compartir diferentes tipos de recursos entre los inquilinos. Por ejemplo, programar pods de diferentes 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 tengas que evitar que se coloquen juntas determinadas cargas de trabajo. Por ejemplo, puede que no permitas que se ejecute código no fiable de fuera de tu organización en el mismo nodo que los contenedores que procesan información sensible.
Aunque Kubernetes no puede garantizar un aislamiento perfectamente seguro entre los arrendatarios, sí ofrece funciones que pueden ser suficientes para casos prácticos específicos. Puedes separar cada arrendatario y sus recursos de Kubernetes en sus propios espacios de nombres. Después, puedes usar políticas para aplicar el aislamiento de tenants. Las políticas suelen estar acotadas por el espacio de nombres y se pueden usar para restringir el acceso a las APIs, limitar el uso de recursos y restringir lo que pueden hacer los contenedores.
Los clientes de un clúster multicliente comparten lo siguiente:
- Extensiones, controladores, complementos y definiciones de recursos personalizadas (CRDs).
- El plano de control del clúster. Esto implica que las operaciones, la seguridad y la auditoría del clúster están centralizadas.
Operar un clúster multiarrendatario tiene varias ventajas con respecto a operar varios clústeres de un solo arrendatario:
- Reducción de la sobrecarga de gestión
- Reducción de la fragmentación de recursos
- No es necesario esperar a que se cree el clúster para los nuevos inquilinos
Casos prácticos de multitenancy
En esta sección se describe cómo configurar un clúster para varios casos prácticos de multitenencia.
Propiedad múltiple empresarial
En un entorno empresarial, los tenants de un clúster son equipos distintos de la organización. Normalmente, cada arrendatario tiene un espacio de nombres correspondiente. Los modelos alternativos de multitenencia con un cliente por clúster o un cliente por proyectoGoogle Cloud son más difíciles de gestionar. El tráfico de red dentro de un espacio de nombres no está restringido. El tráfico de red entre espacios de nombres debe permitirse explícitamente. Estas políticas se pueden aplicar mediante la política de red de Kubernetes.
Los usuarios del clúster se dividen en tres roles diferentes, según sus privilegios:
- Administrador de clústeres
- Este rol es para los administradores de todo el clúster, que gestionan todos los inquilinos. Los administradores de clústeres pueden crear, leer, actualizar y eliminar cualquier objeto de política. Pueden crear espacios de nombres y asignarlos a administradores de espacios de nombres.
- Administrador del espacio de nombres
- Este rol es para administradores de inquilinos específicos. Un administrador de espacio de nombres puede gestionar los usuarios de su espacio de nombres.
- Desarrollador
- Los miembros de este rol pueden crear, leer, actualizar y eliminar objetos que no estén sujetos a políticas y que tengan un espacio de nombres, como pods, trabajos y entradas. Los desarrolladores solo tienen estos privilegios en los espacios de nombres a los que tienen acceso.
Para obtener información sobre cómo configurar varios clústeres multiinquilino para una empresa, consulta el artículo Prácticas recomendadas para la multiinquilino en empresas.
Arquitectura multicliente de proveedores de SaaS
Los clientes de un clúster de un proveedor de SaaS son las instancias de la aplicación de cada cliente y el plano de control del SaaS. Para aprovechar las ventajas de las políticas con ámbito de espacio de nombres, las instancias de la aplicación deben organizarse en sus propios espacios de nombres, al igual que los componentes del plano de control del SaaS. Los usuarios finales no pueden interactuar directamente con el plano de control de Kubernetes, sino que utilizan la interfaz del SaaS, que a su vez interactúa con el plano de control de Kubernetes.
Por ejemplo, una plataforma de blogs podría ejecutarse en un clúster multicliente. En este caso, los inquilinos son la instancia del blog de cada cliente y el plano de control de la plataforma. El plano de control de la plataforma y cada blog alojado se ejecutarían en espacios de nombres independientes. Los clientes creaban y eliminaban blogs, y actualizaban las versiones del software de blogging a través de la interfaz de la plataforma sin saber cómo funcionaba el clúster.
Aplicación obligatoria de la política de arquitectura multicliente
GKE y Kubernetes ofrecen varias funciones que se pueden usar para gestionar clústeres multiinquilino. En las siguientes secciones se ofrece una descripción general de estas funciones.
Control de acceso
GKE tiene dos sistemas de control de acceso: gestión de identidades y accesos (IAM) y control de acceso basado en roles (RBAC). IAM es el sistema de control de acceso de Google Cloud's para gestionar la autenticación y la autorización de los recursos de Google Cloud. Utiliza IAM para conceder acceso a los usuarios a los recursos de GKE y Kubernetes. El control de acceso basado en roles está integrado en Kubernetes y otorga permisos granulares para recursos y operaciones específicos en tus clústeres.
Consulta la descripción general del control de acceso para obtener más información sobre estas opciones y cuándo usar cada una.
Consulta la guía práctica sobre RBAC y la guía práctica sobre IAM para saber cómo usar estos sistemas de control de acceso.
Puedes usar los permisos de IAM y RBAC junto con los espacios de nombres para restringir las interacciones de los usuarios con los recursos del clúster en la Google Cloud consola. Para obtener más información, consulta Habilitar el acceso y ver los recursos del clúster por espacio de nombres.Políticas de red
Las políticas de red de los clústeres te permiten controlar la comunicación entre los pods de tu clúster. Las políticas especifican con qué espacios de nombres, etiquetas e intervalos de direcciones IP puede comunicarse un pod.
Consulta las instrucciones de la política de red para habilitar la aplicación de la política de red en GKE.
Sigue el tutorial sobre la política de red para aprender a escribir políticas de red.
Cuotas de recursos
Las cuotas de recursos gestionan la cantidad de recursos que usan los objetos de un espacio de nombres. Puedes definir cuotas en términos de uso de CPU y memoria, o en términos de recuento de objetos. Las cuotas de recursos te permiten asegurarte de que ningún cliente utilice más recursos de clústeres de los que tiene asignados.
Consulta la documentación sobre cuotas de recursos para obtener más información.
Control de admisión de pods basado en políticas
Para evitar que se ejecuten en tu clúster pods que infrinjan tus límites de seguridad, usa un controlador de admisión. Los controladores de admisión pueden comprobar las especificaciones de los pods con las políticas que definas y pueden evitar que los pods que infrinjan esas políticas se ejecuten en tu clúster.
GKE admite los siguientes tipos de control de acceso:
- Policy Controller: declara políticas predefinidas o personalizadas y aplícalas en clústeres a gran escala con flotas. Policy Controller es una implementación del agente de políticas de código abierto Gatekeeper y es una función de GKE Enterprise.
- Controlador de admisión PodSecurity: implementa políticas predefinidas que se corresponden con los estándares de seguridad de pods en clústeres concretos o en espacios de nombres específicos.
Antiafinidad de pods
Puedes usar antafinidades de pods para evitar que los pods de diferentes inquilinos se programen en el mismo nodo.
Las restricciones de antiafinidad se basan en las etiquetas de los pods.
Por ejemplo, la especificación de Pod que se muestra a continuación describe un Pod con la etiqueta "team":
"billing" y una regla de antiafinidad que impide que el Pod se programe junto con Pods que no tengan la etiqueta.
apiVersion: v1
kind: Pod
metadata:
name: bar
labels:
team: "billing"
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: "kubernetes.io/hostname"
labelSelector:
matchExpressions:
- key: "team"
operator: NotIn
values: ["billing"]
El inconveniente de esta técnica es que los usuarios malintencionados podrían eludir la regla
aplicando la etiqueta team: billing a un pod arbitrario. La antiafinidad de pods por sí sola no puede aplicar políticas de forma segura en clústeres con tenants que no sean de confianza.
Consulta la documentación sobre antafinidades de pods para obtener más información.
Nodos dedicados con intolerancias
Las intolerancias de nodos son otra forma de controlar la programación de cargas de trabajo. Puedes usar taints de nodos para reservar nodos especializados para que los usen determinados clientes. Por ejemplo, puedes dedicar nodos equipados con GPUs a los inquilinos específicos cuyas cargas de trabajo requieran GPUs. En los clústeres de Autopilot, las tolerancias de nodos solo se admiten para la separación de cargas de trabajo. El aprovisionamiento automático de nodos añade automáticamente etiquetas de nodos según sea necesario.
Para dedicar un grupo de nodos a un inquilino concreto, aplica un taint con effect: "NoSchedule" al grupo de nodos. De esta forma, solo los pods con una tolerancia correspondiente se pueden programar en los nodos del grupo de nodos.
El inconveniente de esta técnica es que los usuarios malintencionados podrían añadir una tolerancia a sus pods para acceder al grupo de nodos dedicado. Las contaminaciones y tolerancias de nodos por sí solas no pueden aplicar políticas de forma segura en clústeres con tenants que no sean de confianza.
Para obtener más información, consulta la sección Tolerancias e intolerancias de la documentación de Kubernetes.