En esta página, se explica el clúster de instancias múltiples en Google Kubernetes Engine (GKE). Esto incluye clústeres compartidos por usuarios diferentes en una sola organización y clústeres compartidos por instancias por cliente de una aplicación de software como servicio (SaaS). El clúster de instancias múltiples es una alternativa para la administración de varios clústeres de usuarios individuales.
En esta página, también se resumen las características de Kubernetes y GKE que se pueden usar para administrar los clústeres de instancias múltiples.
¿Qué significa “instancias múltiples”?
Un clúster de instancias múltiples se comparte por muchos usuarios o cargas de trabajo a las que nos referimos como “instancias”. Los operadores de clústeres de instancias múltiples deben aislar a las instancias para minimizar el daño que una instancia malintencionada o vulnerada pueda causar al clúster y a otras instancias. Además, los recursos de clúster se deben asignar entre las instancias.
Cuando planeas una arquitectura de usuarios múltiples debes considerar las capas de aislamiento de recursos en Kubernetes: clúster, espacio de nombres, nodo, pod y contenedor. También debes considerar las implicaciones de seguridad cuando se comparten tipos diferentes de recursos entre instancias. Por ejemplo, si programas pods de usuarios diferentes en el mismo nodo, se puede reducir la cantidad de máquinas necesarias en el clúster. Por otro lado, puede ser necesario evitar que se coloquen algunas cargas de trabajo. Por ejemplo, no debes permitir que se ejecuten códigos no confiables externos a tu organización en el mismo nodo que los contenedores que procesan información sensible.
A pesar de que Kubernetes no puede garantizar un aislamiento del todo seguro entre las instancias, ofrece características que pueden ser suficientes para casos prácticos específicos. Puedes separar cada instancia y sus recursos de Kubernetes en sus propios espacios de nombres. Puedes usar políticas para aplicar un aislamiento de instancias. En general, el espacio de nombres alcanza las políticas y estas se pueden usar para restringir el acceso a la API, el uso de los recursos y los permisos de los contenedores.
Las instancias de un clúster de instancias múltiples comparten lo siguiente:
- Extensiones, controladores, complementos y definiciones de recursos personalizadas (CRD)
- 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 de instancias múltiples tiene varias ventajas sobre operar múltiples clústeres de instancias individuales:
- Se reduce la sobrecarga de administración.
- Se reduce la fragmentación de recursos.
- No hay necesidad de crear clústeres para instancias nuevas.
Casos prácticos de instancias múltiples
En esta sección, se describe cómo puedes configurar un clúster para varios casos prácticos de instancias múltiples.
Instancias múltiples para empresas
En un entorno empresarial, las instancias de un clúster son equipos distintos dentro de la organización. En general, cada instancia tiene un espacio de nombres correspondiente. Los modelos alternativos de instancias múltiples con una instancia por clúster o una instancia por proyecto de Google Cloud son más difíciles de administrar. El tráfico de red dentro de un espacio de nombres no tiene restricción. El tráfico de red entre espacios de nombres se debe permitir de manera explícita. Estas políticas se pueden aplicar mediante la política de red de Kubernetes.
Los usuarios del clúster se dividen en tres funciones diferentes, según su privilegio:
- Administrador del clúster
- Esta función es para los administradores de la totalidad del clúster, que administran todas las instancias. Los administradores de clúster pueden crear, leer, actualizar y borrar cualquier objeto de política. Pueden crear espacios de nombres y asignarlos a administradores de espacio de nombres.
- Administrador de espacio de nombres
- Esta función es para administradores de instancias individuales específicas. Un administrador de espacio de nombres puede administrar a los usuarios en su espacio de nombres.
- Desarrollador
- Los miembros de esta función pueden crear, leer, actualizar y borrar objetos que no se rigen por políticas de espacio de nombres como Pods, Ingresses y Jobs. Los desarrolladores solo tienen estos privilegios en los espacios de nombres a los que tienen acceso.
Si deseas obtener información sobre la configuración de varios clústeres multiusuario de una organización empresarial, consulta Prácticas recomendadas para arquitecturas empresariales multiusuario.
Proveedor de SaaS multiusuario
Las instancias de un clúster de proveedor SaaS son las instancias por cliente de la aplicación y el plano de control de SaaS. Para aprovechar las políticas de alcance de espacio de nombres, las instancias de la aplicación se deben organizar en sus propios espacios de nombres, como los componentes del plano de control de SaaS. Los usuarios finales no pueden interactuar con el plano de control directamente, deben usar la interfaz de SaaS, que, a su vez, interactúa con el plano de control de Kubernetes.
Por ejemplo, una plataforma de blog se puede ejecutar en un clúster de instancias múltiples. En este caso, las instancias son cada una de las instancias de blog del cliente y el plano de control de la plataforma. El plano de control de la plataforma y cada blog alojado se ejecutan todos en espacios de nombres separados. Los clientes crean y borran blogs, actualizan las versiones del software del blog a través de la interfaz de la plataforma sin poder ver cómo opera el clúster.
Aplicación de la política de instancias múltiples
GKE y Kubernetes proporcionan varias características que se pueden usar para administrar clústeres de instancias múltiples. En las secciones siguientes puedes encontrar una descripción general de esas características.
Control de acceso
GKE tiene dos sistemas de control de acceso: Identity and Access Management (IAM) y el control de acceso según los roles (RBAC). IAM es el sistema de control de acceso de Google Cloud para administrar la autenticación y la autorización de los recursos de Google Cloud. Usa IAM para otorgar a los usuarios acceso a los recursos de GKE y Kubernetes. RBAC está integrado en Kubernetes y otorga permisos detallados para recursos y operaciones específicas dentro de 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 de RBAC y la guía práctica de IAM para aprender 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 del usuario con los recursos del clúster en la consola de Google Cloud. Para obtener más información, consulta Habilita el acceso y visualiza los recursos del clúster por espacio de nombres.Políticas de red
Las políticas de red de clústeres te brindan control sobre la comunicación entre los Pods del clúster. Las políticas especifican los espacios de nombres, las etiquetas y los rangos de direcciones IP con los que un Pod se puede comunicar.
Consulta la guía práctica de políticas de red para obtener instrucciones sobre cómo habilitar la aplicación de la política de red en GKE.
Sigue el instructivo de políticas de red para aprender cómo escribir políticas de red.
Cuotas de recursos
Las cuotas de recursos administran la cantidad de recursos usados por los objetos en un espacio de nombres. Puedes establecer cuotas de acuerdo con el uso de memoria y de CPU o de acuerdo con los conteos de objeto. Las cuotas de recursos te aseguran que ninguna instancia use más de lo que se le asigna de los recursos de clúster.
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 los Pods que infringen los límites de seguridad se ejecuten en tu clúster, usa un controlador de admisión. Los controladores de admisión pueden verificar las especificaciones del Pod con las políticas que defines y pueden evitar que los pods que infringen esas políticas se ejecuten en tu clúster.
GKE admite los siguientes tipos de control de admisión:
- 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 abiertas de Gatekeeper de código abierto y es una función de GKE Enterprise.
- Controlador de admisión PodSecurity: Aplica políticas predefinidas que correspondan a los Estándares de seguridad de Pods en clústeres individuales o en espacios de nombres específicos.
Antiafinidad de pods
Puedes usar la antiafinidad del Pod para evitar que Pods de instancias diferentes se programen en el mismo nodo.
Las restricciones de antiafinidad se basan en etiquetas de pods.
Por ejemplo, la siguiente especificación de pod describe un pod con la etiqueta "team":
"billing" y una regla antiafinidad que impide que se programe junto con pods sin 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 problema de esta técnica es que los usuarios malintencionados pueden eludir la regla si aplican la etiqueta team: billing en un pod arbitrario. La antiafinidad del Pod por sí sola no puede aplicar la política en clústeres con instancias no confiables.
Consulta la documentación de antiafinidad del Pod para obtener más información.
Nodos dedicados con taints y tolerancias
Los taints de nodo son otra manera de controlar la programación de la carga de trabajo. Puedes usar los taints de nodo para reservar nodos especializados a fin de que los usen ciertas instancias. Por ejemplo, puedes dedicar nodos equipados con GPU a instancias específicas cuyas cargas de trabajo requieran GPU. En los clústeres de Autopilot, las tolerancias de nodo solo son compatibles con la separación de cargas de trabajo. Los taints se agregan automáticamente mediante el aprovisionamiento automático de nodos según sea necesario.
Para dedicar un grupo de nodos a una instancia determinada, aplica un taint con effect: "NoSchedule" al grupo de nodos. Entonces, solo se pueden programar pods con una tolerancia correspondiente en nodos del grupo de nodos.
El problema con esta técnica es que los usuarios malintencionados pueden agregar una tolerancia a sus Pods para obtener acceso al grupo de nodos dedicados. Las tolerancias y taints de nodo por sí solas no pueden aplicar de manera segura una política en clústeres con instancias no confiables.
Para obtener más información, consulta Taints y tolerancias en la documentación de Kubernetes.