Prácticas recomendadas para arquitecturas multiusuario empresariales

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

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. Usa Grupos de Google con el fin de asignar y administrar IAM de manera eficiente para los usuarios.

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.
Un clúster regional privado con un plano de control regional que se ejecuta en tres zonas
Figura 3: Un clúster regional privado con un plano de control regional que se ejecuta en tres zonas.

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.

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 5,000 nodos por clúster, 1,000 nodos por grupo de nodos, 1,000 nodos por clúster (si usas el controlador de entrada de GKE), 110 pods por nodo y 300,000 contenedores.

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 el balanceo de cargas HTTP(S) 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

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 políticas de seguridad de pods 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.

Crea políticas de seguridad de pods

Para evitar que los pods se ejecuten en un clúster, crea una política de seguridad de pods (PSP), que especifique las condiciones que los pods deben cumplir en un clúster. Para implementar el control de la política de seguridad de pods, habilita el controlador de admisión y autoriza a la cuenta de servicio del pod de destino a usar la política. Puedes autorizar el uso de políticas para un pod en Control de acceso basado en funciones (RBAC) de Kubernetes si vinculas el serviceAccount del pod a una función que tenga acceso para usar las políticas.

Cuando se define una PSP, recomendamos definir la política más restrictiva vinculada a system:authenticated y las políticas más permisivas vinculadas según sea necesario para las excepciones.

A modo de ejemplo, aquí hay una PSP restrictiva que requiere que los usuarios se ejecuten como usuarios sin privilegios, bloquea posibles elevaciones a la raíz y requiere el uso de varios mecanismos de seguridad:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # The following is redundant with non-root + disallow privilege
  # escalation, but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
  # Allow core volume types.
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    # Assume that persistentVolumes set up by the cluster admin
    # are safe to use.
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # Assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535

Establece los siguientes parámetros para evitar la elevación de privilegios en los contenedores:

  • Para asegurarte de que ningún proceso secundario de un contenedor pueda obtener más privilegios que su superior, establece el parámetro allowPrivilegeEscalation en false.
  • Para inhabilitar los privilegios de elevación fuera del contenedor, inhabilita el acceso a los componentes de los espacios de nombres del host (hostNetwork, hostIPC y hostPID). Esto también bloquea el análisis de la actividad de red de otros pods en el mismo nodo.

Usa Workload Identity 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 Workload Identity en el clúster. Workload Identity ayuda a los administradores a administrar las cuentas de servicio de Kubernetes que las cargas de trabajo de Kubernetes usan para acceder a los servicios de Google Cloud. Cuando creas un clúster con Workload Identity habilitado, 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

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 administrador 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.

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 Workload Identity.

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

Sigue las métricas de uso

Para obtener desgloses de costos en espacios de nombres y etiquetas individuales en un clúster, puedes habilitar la medición de uso de GKE. La medición de uso de GKE realiza un seguimiento de la información sobre las solicitudes de recursos y el uso de recursos de las cargas de trabajo de un clúster, que puedes desglosar por espacio de nombres y etiquetas. Con la medición de uso de GKE, puedes calcular el desglose de costos para los departamentos o equipos que comparten un clúster, comprender los patrones de uso de aplicaciones individuales (o incluso los componentes de una sola aplicación), ayudar a los administradores de clústeres a clasificar los picos de uso y proporcionar una mejor capacidad de planificación y presupuesto.

Cuando habilitas la medición de uso de GKE en el clúster multiusuario, los registros de uso de recursos se escriben en una tabla de BigQuery. Puedes exportar métricas específicas de usuarios a los conjuntos de datos de BigQuery en el proyecto del usuario correspondiente, que los auditores pueden analizar para determinar los desgloses de costos. Los auditores pueden visualizar los datos de medición de uso de GKE mediante la creación de paneles con plantillas listas para usar de Google Data Studio.

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 Monitoring. 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.

Proporciona supervisión específica de usuarios

Para proporcionar supervisión específica de usuarios, el administrador de clústeres puede usar un espacio de nombres dedicado que contiene un adaptador Prometheus a Stackdriver (prometheus-to-sd) con una configuración por espacio de nombres. Esta configuración garantiza que los usuarios solo puedan supervisar sus propias métricas en sus proyectos. Sin embargo, la desventaja de este diseño es el costo adicional de administrar tus propias implementaciones de Prometheus.

Estas son otras opciones que puedes considerar para proporcionar supervisión específica de usuarios:

  • Los equipos aceptan usuarios compartidos dentro del entorno de Cloud Monitoring y permiten que los usuarios tengan visibilidad de todas las métricas del proyecto.
  • Implementa una sola instancia de Grafana por usuario, que se comunica con el entorno compartido de Cloud Monitoring. Configura la instancia de Grafana para ver solo las métricas de un espacio de nombres en particular. La desventaja de esta opción es el costo y la sobrecarga de administrar estas implementaciones adicionales de Grafana.

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:

Área Tareas
Configuración organizativa
Administración de identidades y accesos
Redes
Alta disponibilidad y confiabilidad
Seguridad
Registros y supervisión

¿Qué sigue?