La arquitectura multiusuario en Google Kubernetes Engine (GKE) se refiere a uno o más clústeres que se comparten entre usuarios. En Kubernetes, un usuario se puede definir como cualquiera de los siguientes:
- Un equipo responsable de desarrollar y operar una o más cargas de trabajo
- Un conjunto de cargas de trabajo relacionadas, ya sean operadas por uno o más equipos
- Una sola carga de trabajo, como una implementación
El clúster multiusuario se suele implementar para reducir costos o aplicar políticas de administración de manera coherente en todos los usuarios. Sin embargo, la configuración incorrecta de un clúster de GKE o sus recursos de GKE asociados puede generar un fracaso en los ahorros de costos, una aplicación de políticas incorrecta o interacciones destructivas entre cargas de trabajo diferentes.
En esta guía, se proporcionan prácticas recomendadas con el fin de configurar de manera segura y eficiente varios clústeres multiusuario para una organización empresarial.
Suposiciones y requisitos
Las prácticas recomendadas de esta guía se basan en un caso práctico multiusuario para un entorno empresarial, que sigue las suposiciones y los requisitos que se indican a continuación:
- La organización es una sola empresa que tiene muchos usuarios (dos o más equipos de aplicaciones o servicios) que usan Kubernetes y desean compartir recursos de procesamiento y administración.
- Cada usuario es un solo equipo que desarrolla una sola carga de trabajo.
- Además de los equipos de aplicaciones y servicios, hay otros equipos que también usan y administran clústeres, incluidos los miembros del equipo de la plataforma, los administradores de clústeres, los auditores, etcétera.
- El equipo de la plataforma es propietario de los clústeres y define la cantidad de recursos que cada equipo de usuarios puede usar; cada usuario puede solicitar más.
- Cada equipo de usuarios debe poder implementar su aplicación a través de la API de Kubernetes sin tener que comunicarse con el equipo de la plataforma.
- Cada usuario no debería poder afectar a otros usuarios en el clúster compartido, excepto a través de decisiones de diseño explícitas, como llamadas a la API, fuentes de datos compartidas, etcétera.
Esta configuración servirá como modelo, a partir del cual podemos demostrar las prácticas recomendadas para la arquitectura multiusuario. Si bien es posible que esta configuración no describa perfectamente todas las organizaciones empresariales, se puede extender con facilidad para cubrir situaciones similares.
Configura carpetas, proyectos y clústeres
Recomendaciones:
Establece una jerarquía de carpetas y proyectos.Asignar funciones con IAM
Centraliza el control de la red con VPC compartidas.
Crea un proyecto de administración de clústeres por clúster.
Crea clústeres privados.
Asegúrate de que el plano de control del clúster sea regional.
Asegúrate de que los nodos de tu clúster abarquen al menos tres zonas.
Escala automáticamente los nodos y los recursos del clúster.
Programa períodos de mantenimiento para las horas de menor demanda.
Configura un balanceador de cargas de aplicaciones externo con Ingress.
Para las organizaciones empresariales que implementan clústeres multiusuario en GKE, se necesita una configuración adicional en otros sistemas de Google Cloud a fin de administrar la complejidad, que no existe en implementaciones más simples de Kubernetes de una sola aplicación y un solo equipo. Esto incluye la configuración del proyecto para aislar problemas administrativos, así como asignar la estructura de la organización a las identidades y cuentas de la nube, y administrar recursos adicionales de Google Cloud, como bases de datos, registro y supervisión, almacenamiento y redes.
Establece una jerarquía de carpetas y proyectos
Para captar la forma en que tu organización administra los recursos de Google Cloud y aplicar una separación de problemas, usa carpetas y proyectos. Las carpetas permiten que diferentes equipos establezcan políticas en cascada en varios proyectos, mientras que estos se pueden usar para separar entornos (por ejemplo, producción frente a etapa de pruebas) y equipos entre sí. Por ejemplo, la mayoría de las organizaciones tienen un equipo con el fin de administrar la infraestructura de red y un equipo diferente para administrar los clústeres. Cada tecnología se considera una parte separada de la pila que requiere su propio nivel de experiencia, solución de problemas y acceso.
Una carpeta superior puede contener hasta 300 carpetas y puedes anidar carpetas de hasta 10 niveles. Si tienes más de 300 usuarios, puedes organizarlos en jerarquías anidadas para que se mantengan dentro del límite. Para obtener más información sobre las carpetas, consulta Crea y administra carpetas.
Asigna funciones con IAM
Puedes controlar el acceso a los recursos de Google Cloud a través de las políticas de IAM. Comienza por identificar los grupos necesarios para tu organización y el alcance de sus operaciones. Luego, asigna la función de IAM adecuada al grupo.
Centraliza el control de la red
Para mantener el control centralizado de los recursos de red, como las subredes, las rutas y los firewalls, usa las redes de VPC compartidas. Los recursos en una VPC compartida pueden comunicarse entre sí de forma segura y eficiente a través de los límites del proyecto mediante IP internas. Cada red de VPC compartida está definida y es propiedad de un proyecto host centralizado, y pueden usarla uno o más proyectos de servicio.
Con la VPC compartida y con IAM, puedes separar la administración de la red de la administración del proyecto. Esta separación permite implementar el principio de mínimo privilegio. Por ejemplo, un equipo de red centralizado puede administrar la red sin necesitar permisos para los proyectos involucrados. De manera similar, los administradores de proyectos pueden controlar los recursos de estos sin necesitar permisos para manipular la red compartida.
Cuando configuras una VPC compartida, debes configurar las subredes y sus rangos de IP secundarios en la VPC. Para determinar el tamaño de la subred, debes conocer la cantidad esperada de usuarios, la cantidad de pods y servicios que se espera que se ejecuten, y el tamaño máximo y promedio del pod. El cálculo de la capacidad total del clúster permitirá comprender el tamaño de instancia deseado, y esto proporciona el recuento total de nodos. Con la cantidad total de nodos, se puede calcular el espacio de IP total consumido y esto puede proporcionar el tamaño de subred deseado.
Estos son algunos factores que también debes tener en cuenta cuando configures tu red:
- La cantidad máxima de proyectos de servicio que se pueden conectar a un proyecto host es 1,000, y la cantidad máxima de proyectos host de VPC compartida en una sola organización es 100.
- Los rangos de IP de nodo, pod y servicios deben ser únicos. No puedes crear una subred cuyos rangos de direcciones IP principales y secundarios se superpongan.
- La cantidad máxima de pods y servicios para un clúster de GKE determinado está limitada por el tamaño de los rangos secundarios del clúster.
- La cantidad máxima de nodos en el clúster está limitada por el tamaño del rango de direcciones IP principal de la subred del clúster y del rango de direcciones del pod del clúster.
- Para obtener flexibilidad y más control sobre la administración de direcciones IP, puedes configurar la cantidad máxima de pods que se pueden ejecutar en un nodo. Mediante la reducción de la cantidad de pods por nodo, también se reduce el rango de CIDR asignado por nodo, lo que requiere menos direcciones IP.
Para ayudar a calcular las subredes de tus clústeres, puedes usar la herramienta de código abierto, la calculadora de IPAM de GKE. La administración de direcciones IP (IPAM) permite el uso eficiente del espacio o las subredes de IP y evita tener superposiciones en los rangos, lo que impide las opciones de conectividad en el futuro. Para obtener información sobre los rangos de red en un clúster de VPC, consulta Crea un clúster nativo de la VPC.
Los usuarios que requieren mayor aislamiento para los recursos que se ejecutan fuera de los clústeres compartidos (como las VM dedicadas de Compute Engine) pueden usar su propia VPC, que intercambia tráfico con la VPC compartida ejecutada por el equipo de redes. Esto proporciona seguridad adicional a costa de una mayor complejidad y de muchas otras limitaciones. Para obtener más información sobre el intercambio de tráfico, consulta Usa intercambio de tráfico entre redes de VPC. En el siguiente ejemplo, todos los usuarios eligieron compartir una VPC de usuario única (por entorno).
Crea clústeres confiables y con alta disponibilidad
Implementa las siguientes recomendaciones para diseñar la arquitectura de tu clúster a fin de obtener alta disponibilidad y confiabilidad:
- Crea un proyecto de administración de clústeres por clúster para reducir el riesgo de que las configuraciones a nivel de proyecto (por ejemplo, las vinculaciones de IAM) afecten negativamente a muchos clústeres y con el fin de ayudar a proporcionar separación para la cuota y la facturación. Los proyectos de administración de clústeres son independientes de los proyectos de los usuarios, en los que los usuarios individuales usan para administrar, por ejemplo, sus recursos de Google Cloud.
- Haz que el clúster de producción sea privado para inhabilitar el acceso a los nodos y administrar el acceso al plano de control. También recomendamos usar clústeres privados para entornos de desarrollo y etapa de pruebas.
- Asegúrate de que el plano de control del clúster sea regional a fin de proporcionar alta disponibilidad para la arquitectura multiusuario; cualquier interrupción en el plano de control afectará a los usuarios. Ten en cuenta que hay implicaciones de costo en la ejecución de clústeres regionales. Los clústeres de Autopilot están preconfigurados como clústeres regionales.
- Asegúrate de que los nodos de tu clúster abarquen al menos tres zonas para lograr confiabilidad zonal. Para obtener información sobre el costo de salida entre zonas de la misma región, consulta la documentación sobre precios de red.
Haz un ajuste de escala automático de nodos y recursos del clúster
Para satisfacer las demandas de tus usuarios, haz un ajuste de escala automático de nodos en tu clúster mediante la habilitación del ajuste de escala automático.El ajuste de escala automático ayuda a que los sistemas se muestren receptivos y en buen estado cuando varios usuarios implementan cargas de trabajo pesadas en sus espacios de nombres o para responder a interrupciones zonales.
Con los clústeres de Autopilot, los grupos de nodos se escalan de forma automática para cumplir con los requisitos de tus cargas de trabajo.
Cuando habilitas el ajuste de escala automático, especificas la cantidad mínima y máxima de nodos en un clúster según los tamaños de la carga de trabajo esperados. Si especificas la cantidad máxima de nodos, puedes asegurarte de que haya suficiente espacio para todos los pods en el clúster, independientemente del espacio de nombres en el que se ejecuten. El ajuste de escala automático del clúster ajusta la escala de los grupos de nodos en función del límite mínimo/máximo, lo que ayuda a reducir los costos operativos cuando la carga del sistema disminuye, y evita que los pods entren en estado pendiente cuando no hay suficientes recursos de clúster disponibles. Para determinar la cantidad máxima de nodos, identifica la cantidad máxima de CPU y memoria que requiere cada usuario, y agrega esas cantidades juntas para obtener la capacidad total que el clúster debería poder controlar si todos los usuarios estuvieran en el límite. Con la cantidad máxima de nodos, puedes elegir los tamaños y recuentos de instancias, teniendo en cuenta el espacio de subred de IP disponible para el clúster.
Usa el ajuste de escala automático de pods para hacer un ajuste de escala automático de los pods según las demandas de recursos. El escalador automático horizontal de pods (HPA) escala la cantidad de réplicas de pod según el uso de CPU/memoria o las métricas personalizadas. El ajuste de escala automático vertical de pods (VPA) se puede usar para hacer un ajuste de escala automático de las demandas de recursos de pods. No se debe usar con el HPA, a menos que las métricas personalizadas estén disponibles, ya que los dos escaladores automáticos pueden competir entre sí. Por este motivo, comienza con el HPA y, más adelante, el VPA, cuando sea necesario.
Determina el tamaño de tu clúster
A la hora de determinar el tamaño de tu clúster, estos son algunos factores importantes que debes considerar:
- El tamaño de tu clúster depende del tipo de cargas de trabajo que planeas ejecutar. Si tus cargas de trabajo tienen mayor densidad, la rentabilidad es mayor, pero también hay una mayor probabilidad de contención de recursos.
- El tamaño mínimo de un clúster se define por la cantidad de zonas que abarca: un nodo para un clúster zonal y tres nodos para un clúster regional.
- Por proyecto, hay un máximo de 50 clústeres por zona, más 50 clústeres regionales por región.
- Por clúster, hay un máximo de 15,000 nodos por clúster (5,000 para versiones de GKE hasta la 1.17), 1,000 nodos por grupo de nodos, 1,000 nodos por clúster (si usas el controlador de entrada de GKE), 256 Pods por nodo (110 para versiones de GKE anteriores a 1.23.5-gke.1300), 150,000 Pods por clúster y 300,000 contenedores por clúster. Consulta la página de Cuotas y límites para obtener más información.
Programa períodos de mantenimiento
Para reducir los tiempos de inactividad durante las actualizaciones y el mantenimiento del clúster/nodo, programa períodos de mantenimiento que se lleven a cabo durante las horas de menor demanda. Durante las actualizaciones, puede haber interrupciones temporales cuando se mueven las cargas de trabajo para volver a crear los nodos. Para garantizar un impacto mínimo de tales interrupciones, programa actualizaciones durante las horas de menor demanda y diseña las implementaciones de tu aplicación para manejar interrupciones parciales sin problemas, si es posible.
Configura un balanceador de cargas de aplicaciones externo con Ingress
Para ayudar con la administración de los servicios publicados de tus usuarios y la administración del tráfico entrante a esos servicios, crea un balanceador de cargas HTTP(s) para permitir un solo ingreso por clúster, en el que se registren los servicios de cada usuario con el recurso de Ingress del clúster. Para crear y configurar un balanceador de cargas HTTP(S), crea un recurso de Kubernetes Ingress, que defina cómo el tráfico llega a tus servicios y cómo se enruta a la aplicación de tu usuario. Cuando registras los servicios con el recurso de Ingress, la convención de nombres de los servicios se vuelve coherente y muestra una sola entrada, como tenanta.example.com y tenantb.example.com.
Protege el clúster multiusuario
Recomendaciones:
Controla la comunicación del pod con las políticas de red.Ejecuta cargas de trabajo con GKE Sandbox.
Configura controles de admisión basados en políticas.
Usa la federación de identidades para cargas de trabajo para GKE para otorgar acceso a los servicios de Google Cloud.
Restringe el acceso de red al plano de control.
Controla la comunicación del pod con políticas de red
Para controlar la comunicación de red entre pods en cada uno de los espacios de nombres de tu clúster, crea políticas de red basadas en los requisitos de tus usuarios. Como recomendación inicial, debes bloquear el tráfico entre los espacios de nombres que alojan las aplicaciones de diferentes usuarios. El administrador de tu clúster puede aplicar una política de red deny-all para denegar todo el tráfico de entrada a fin de evitar que los pods de un espacio de nombres envíen accidentalmente tráfico a servicios o bases de datos en otros espacios de nombres.
A modo de ejemplo, esta es una política de red que restringe la entrada de todos los otros espacios de nombres al espacio de nombres tenant-a:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: tenant-a
spec:
podSelector:
matchLabels:
ingress:
- from:
- podSelector: {}
Ejecuta cargas de trabajo con GKE Sandbox
Los clústeres que ejecutan cargas de trabajo no confiables están más expuestos a vulnerabilidades de seguridad que otros clústeres. Con GKE Sandbox, puedes endurecer los límites de aislamiento entre cargas de trabajo para tu entorno multiusuario. Para la administración de seguridad, recomendamos comenzar con GKE Sandbox y, luego, usar controles de admisión basados en políticas para llenar los vacíos.
GKE Sandbox se basa en gVisor, un proyecto de zona de pruebas de contenedores de código abierto, y proporciona aislamiento adicional para cargas de trabajo multiusuario mediante la adición de una capa adicional entre tus contenedores y el SO host. Los entornos de ejecución de contenedores a menudo se ejecutan como usuarios privilegiados en el nodo y tienen acceso a la mayoría de las llamadas del sistema al kernel del host. En un clúster multiusuario, un usuario malicioso puede obtener acceso al kernel del host y a los datos de otro usuario. GKE Sandbox mitiga estas amenazas mediante la disminución de la necesidad de que los contenedores interactúen con el host mediante la reducción de la superficie de ataque del host y la restricción del movimiento de los actores maliciosos.
GKE Sandbox proporciona dos límites de aislamiento entre el contenedor y el SO host:
- Un kernel de espacio de usuario, escrito en Go, que controla las llamadas del sistema y limita la interacción con el kernel del host. Cada pod tiene su propio kernel de espacio de usuario aislado.
- El kernel de espacio de usuario también se ejecuta dentro de los espacios de nombres y las llamadas del sistema de filtrado de seccomp.
Configura controles de admisión basados 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.
Usa la federación de identidades para cargas de trabajo para GKE para otorgar acceso a los servicios de Google Cloud
Para otorgar acceso seguro a las cargas de trabajo a los servicios de Google Cloud, habilita la federación de identidades para cargas de trabajo para GKE en el clúster. La federación de identidades para cargas de trabajo para GKE ayuda a los administradores a administrar las cuentas de servicio de Kubernetes que las cargas de trabajo de Kubernetes usan a fin de acceder a los servicios de Google Cloud. Cuando creas un clúster con la federación de identidades para cargas de trabajo para GKE habilitada, se establece un espacio de nombres de identidad para el proyecto en el que se aloja el clúster. El espacio de nombres de identidad permite que el clúster autentique automáticamente las cuentas de servicio para aplicaciones de GKE mediante la asignación del nombre de la cuenta de servicio de Kubernetes a un controlador de cuenta de servicio virtual de Google, que se utiliza para la vinculación de IAM de las cuentas de servicio de Kubernetes de los usuarios.
Restringe el acceso de red al plano de control
Para proteger tu plano de control, restringe el acceso a las redes autorizadas. En GKE, cuando habilitas redes autorizadas de la instancia principal, puedes autorizar hasta 50 rangos de CIDR y permitir que las direcciones IP solo en esos rangos accedan a tu plano de control. GKE ya usa la seguridad de la capa de transporte (TLS) y la autenticación para proporcionar acceso seguro al extremo del panel de control desde la Internet pública. Mediante las redes autorizadas, puedes restringir el acceso solo a conjuntos específicos de direcciones IP.
Aprovisionamiento de usuarios
Recomendaciones:
Crea proyectos de usuarios.Usa RBAC para definir mejor el acceso de los usuarios.
Crea espacios de nombres para el aislamiento entre los usuarios.
Crea proyectos de usuarios
Con el fin de alojar los recursos que no son de clúster de un usuario, crea un proyecto de servicio para cada usuario. Estos proyectos de servicio contienen recursos lógicos específicos para las aplicaciones del usuario (por ejemplo, registros, supervisión, depósitos de almacenamiento, cuentas de servicio, etc.). Todos los proyectos de servicio de usuarios están conectados a la VPC compartida en el proyecto host del usuario.
Usa RBAC para definir mejor el acceso de los usuarios
Define un acceso más preciso a los recursos del clúster para tus usuarios con RBAC de Kubernetes. Además del acceso de solo lectura otorgado inicialmente con IAM a los grupos de usuarios, define las funciones y vinculaciones de RBAC de Kubernetes de todo el espacio de nombres para cada grupo de usuarios.
Anteriormente, identificamos dos grupos de usuarios: administradores de usuarios y desarrolladores de usuarios. Para esos grupos, definimos las siguientes funciones y accesos de RBAC:
| Grupo | Función de RBAC de Kubernetes |
Descripción |
|---|---|---|
| Administrador de usuarios | administrador de espacios de nombres | Otorga acceso para mostrar y ver las implementaciones en su espacio de nombres. Otorga acceso para agregar y quitar usuarios del grupo de usuarios. |
| Desarrollador de usuarios | editor de espacios de nombres, visualizador de espacios de nombres |
Otorga acceso para crear, editar o borrar pods, implementaciones, servicios y mapas de configuración en su espacio de nombres. |
Además de crear funciones y vinculaciones de RBAC que asignan varios permisos a los grupos de Google Workspace o Cloud Identity dentro de su espacio de nombres, los administradores de usuarios a menudo requieren la capacidad de administrar usuarios en cada uno de esos grupos. En función de los requisitos de tu organización, esto se puede manejar mediante la delegación de los permisos de Google Workspace o Cloud Identity al administrador de usuarios para que administre su propia membresía de grupo, o mediante la participación del administrador de usuarios con un equipo en tu organización que tenga permisos de Google Workspace o Cloud Identity para manejar esos cambios.
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.Usa los Grupos de Google para vincular permisos
Para administrar de manera eficiente los permisos del usuario en un clúster, puedes vincular los permisos de RBAC a tus Grupos de Google. Tus administradores de Google Workspace mantienen la membresía de esos grupos, por lo que los administradores de clústeres no necesitan información detallada sobre tus usuarios.
Como ejemplo, tenemos un Grupo de Google llamado tenant-admins@mydomain.com, y un usuario llamado admin1@mydomain.com es miembro de ese grupo. La siguiente vinculación proporciona al usuario acceso de administrador al espacio de nombres tenant-a:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: tenant-a
name: tenant-admin-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: "tenant-admins@mydomain.com"
Crea espacios de nombres
Para proporcionar un aislamiento lógico entre los usuarios que se encuentran en el mismo clúster, implementa espacios de nombres. Como parte del proceso de RBAC de Kubernetes, el administrador de clústeres crea espacios de nombres para cada grupo de usuarios. El administrador de usuarios administra a los usuarios (desarrolladores de usuarios) dentro de su respectivo espacio de nombres. Los desarrolladores de usuarios pueden usar recursos específicos de clústeres y usuarios para implementar sus aplicaciones.
Evita alcanzar los límites de espacio de nombres
La cantidad máxima teórica de espacios de nombres en un clúster es 10,000, pero en la práctica hay muchos factores que podrían evitar que alcances este límite. Por ejemplo, puedes alcanzar la cantidad máxima de pods (150,000) y nodos (5,000) en todo el clúster antes de alcanzar la cantidad máxima de espacios de nombres; otros factores (como la cantidad de secretos) pueden reducir aún más los límites efectivos. Como resultado, una buena regla general es intentar solo acercarse al límite teórico de una restricción a la vez y mantenerse aproximadamente a un orden de magnitud de los otros límites, a menos que en la experimentación se muestre que tus casos prácticos funcionan bien. Si necesitas más recursos de los que admite un solo clúster, debes crear más clústeres. Para obtener información sobre la escalabilidad de Kubernetes, consulta el artículo sobre los límites de escalabilidad de Kubernetes.
Estandariza los nombres de los espacios de nombres
Para facilitar las implementaciones en varios entornos alojados en clústeres diferentes, estandariza la convención de nombres del espacio de nombres que usas. Por ejemplo, evita vincular el nombre del entorno (desarrollo, etapa de pruebas y producción) con el nombre del espacio de nombres y, en su lugar, usa el mismo nombre en todos los entornos. Si usas el mismo nombre, evitas tener que cambiar los archivos de configuración en todos los entornos.
Crea cuentas de servicio para cargas de trabajo de usuarios
Crea una cuenta de servicio de Google específica para cada carga de trabajo distinta en un espacio de nombres de usuario. Esto proporciona una forma de seguridad que garantiza que los usuarios puedan administrar las cuentas de servicio para las cargas de trabajo que poseen o implementen en sus espacios de nombres respectivos. La cuenta de servicio de Kubernetes para cada espacio de nombres se asigna a una cuenta de servicio de Google mediante la federación de identidades para cargas de trabajo para GKE.
Aplica cuotas de recursos
Para garantizar que todas las instancias que comparten un clúster tengan acceso justo a los recursos del clúster, aplica cuotas de recursos. Crea una cuota de recursos para cada espacio de nombres según la cantidad de pods implementados por cada usuario y la cantidad de memoria y CPU requeridas por cada pod.
En el siguiente ejemplo, se define una cuota de recursos en la que los pods del espacio de nombres tenant-a pueden solicitar hasta 16 CPU y 64 GB de memoria, y la CPU máxima es de 32 y la memoria máxima es de 72 GB.
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-a
spec:
hard: "1"
requests.cpu: "16"
requests.memory: 64Gi
limits.cpu: "32"
limits.memory: 72Gi
Supervisión, registro y uso
Proporciona registros específicos de usuarios
Para proporcionar a los usuarios datos de registro específicos de las cargas de trabajo de sus proyectos, usa el enrutador de registros de Cloud Logging. Para crear registros específicos del usuario, el administrador del clúster crea un receptor para exportar entradas de registro a un bucket de registro creado en el proyecto de Google Cloud del usuario.
Para obtener más detalles sobre cómo configurar estos tipos de registros, consulta Registro de instancias múltiples en GKE.
Resumen de la lista de tareas
En la siguiente tabla, se resumen las tareas recomendadas para crear clústeres multiusuario en una organización empresarial:
¿Qué sigue?
- Para obtener más información sobre la seguridad, consulta Endurece la seguridad del clúster.
- Para obtener más información sobre las redes de VPC, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.
- Para obtener más prácticas recomendadas empresariales, consulta el marco de trabajo de la arquitectura de Google Cloud.