Diseño de sistemas para múltiples inquilinos en Kubernetes

La arquitectura basada en múltiples clientes es un principio fundamental para la mayoría de los productos de Software como Servicio (SaaS), permitiendo una escalabilidad rentable al atender a múltiples clientes desde una única instancia de aplicación. Kubernetes se ha convertido en el estándar de facto para orquestar aplicaciones basadas en contenedores, pero diseñar un sistema multi-cliente seguro, escalable e independiente requiere decisiones de diseño deliberadas.

Este artículo proporciona un plan técnico para directores de tecnología y ingenieros senior sobre cómo abordar este desafío, centrándose en los modelos de tenencia, las estrategias de aislamiento y las consideraciones operativas.

1. Seleccionar el modelo de tenencia adecuado

La primera y más importante decisión arquitectónica es elegir el modelo de tenencia adecuado. Esta elección impacta directamente en los costes, la seguridad, la complejidad y la escalabilidad. Los tres modelos principales son Silo, Pool y una combinación de ambos.

Servicios de Ingeniería de Productos

Colabora con nuestros gestores de proyecto, ingenieros de software y testers de control de calidad para desarrollar tu nuevo producto de software personalizado o para apoyar tu flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

• Modelo Silo (Completamente Aislado): En este modelo, cada inquilino recibe un conjunto de infraestructura completamente dedicado. En Kubernetes, esto podría significar un clúster dedicado por inquilino o, más comúnmente, un conjunto dedicado de nodos dentro de un clúster compartido (utilizando etiquetas y tolerancias).
  • Ventajas: Máxima seguridad y aislamiento de recursos ("el problema del vecino ruidoso" se elimina), copias de seguridad y restauraciones simplificadas por inquilino, cumplimiento más fácil de los requisitos de residencia de datos.
  • Desventajas: Mayor costo debido al bajo uso de recursos, importante sobrecarga operativa para la configuración y gestión de cada silo.
  • Ideal para: Clientes empresariales con estrictos requisitos de seguridad, cumplimiento (p. ej., HIPAA, PCI-DSS) o SLO de rendimiento.
• Modelo de Piscina (Completamente Compartido): Todos los inquilinos comparten la misma infraestructura, incluyendo computación, red y a menudo almacenamiento de datos. Un identificador de inquilino (tenant_id) se utiliza en todo el conjunto de aplicaciones para segmentar lógicamente los datos y las operaciones.
  • Ventajas: Mayor utilización y eficiencia de costos de recursos, gestión simplificada de un único conjunto de infraestructura.
  • Desventajas: Máxima complejidad arquitectónica para garantizar un estricto aislamiento de datos y seguridad a nivel de aplicación, riesgo de que "vecinos ruidosos" afecten al rendimiento, medición compleja por inquilino.
  • Ideal para: Aplicaciones B2C o productos B2B con un gran número de pequeños inquilinos donde el costo es un factor clave.
• Modelo Híbrido (Semi-Aislado): Este modelo ofrece un equilibrio práctico. Los inquilinos comparten algunos recursos (p. ej., controladores de entrada, pila de monitorización) mientras que tienen recursos dedicados para otros (p. ej., pods de aplicación, bases de datos). La implementación más efectiva de esto en Kubernetes es el Modelo de Namespace por Inquilino.Ventajas:
  • Ventajas: Buen equilibrio entre costo y aislamiento, fuerte separación lógica proporcionada por los primitives de Kubernetes.
  • Desventajas: Requiere una gestión cuidadosa de los componentes compartidos y políticas robustas de RBAC.
  • Ideal para: La mayoría de las aplicaciones SaaS B2B modernas que requieren un equilibrio entre la eficiencia de costos y un fuerte aislamiento lógico.

Para el resto de este artículo, nos centraremos en el modelo Híbrido (Espacio de nombres por inquilino) porque representa la solución más flexible y ampliamente utilizada para construir SaaS multi-inquilinos en Kubernetes.

2. Implementación de Kubernetes: La estrategia "Un espacio de nombres por cliente"

Utilizar un espacio de nombres dedicado de Kubernetes para cada cliente es fundamental en el modelo híbrido. Un espacio de nombres proporciona una delimitación lógica para los recursos, el control de acceso y las políticas de red.

Recursos y aislamiento de seguridad

Dentro del espacio de nombres de cada cliente, es necesario establecer límites en el consumo de recursos y evitar la comunicación no autorizada entre diferentes clientes.

Cuotas y Rangos de Recursos:

Un objeto de "ResourceQuota" establece la cantidad total de recursos (CPU, memoria, almacenamiento, número de objetos) que un espacio de nombres de un inquilino puede consumir. Un "LimitRange" define las solicitudes y límites predeterminados de recursos para los contenedores dentro de ese espacio de nombres, impidiendo que un solo pod monopolice los recursos del nodo.

Aquí tiene un ejemplo de Recurso asignado para un inquilino estándar:

# quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: standard-tenant-quota
  namespace: tenant-a-namespace # Applied to a specific tenant's namespace
spec:
  hard:
    requests.cpu: "2"       # Total requested CPU cores cannot exceed 2
    requests.memory: "4Gi"  # Total requested memory cannot exceed 4Gi
    limits.cpu: "4"         # Total CPU limits cannot exceed 4 cores
    limits.memory: "8Gi"    # Total memory limits cannot exceed 8Gi
    pods: "10"              # Max number of pods
    services: "5"           # Max number of services

Políticas de red:

Por defecto, todos los nodos en un clúster de Kubernetes pueden comunicarse entre sí, independientemente del espacio de nombres. Esto es inaceptable en un entorno con múltiples inquilinos. Los objetos NetworkPolicy son esenciales para garantizar una estricta separación de la red.

La siguiente política deniega todo el tráfico de entrada a un espacio de nombres de un inquilino, excepto del tráfico proveniente de los pods dentro del mismo espacio de nombres y del controlador de entrada del clúster.

# deny-all-allow-self-and-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all-ingress
  namespace: tenant-a-namespace
spec:
  podSelector: {} # Selects all pods in the namespace
  policyTypes:
    - Ingress
  ingress:
    - from:
      - podSelector: {} # Allow traffic from any pod in the same namespace
      - namespaceSelector: # Allow traffic from the ingress controller's namespace
          matchLabels:
            name: ingress-nginx

Esta postura de "denegar por defecto" es una medida de seguridad crítica para evitar que los usuarios accedan a los servicios de otros.

Servicios de Ingeniería de Productos

Colabore con nuestros gestores de proyecto, ingenieros de software y testers de calidad para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

3. Enrutamiento y acceso adaptados al inquilino

Si las aplicaciones de solicitud de inquilinos están aisladas en espacios de nombres, los componentes de infraestructura compartida, como los controladores de entrada, deben dirigir de forma inteligente el tráfico externo al inquilino correcto. El enfoque más común es utilizar la enrutamiento basado en el host, donde cada inquilino obtiene un subdominio único (por ejemplo, tenant-a.your-saas.com.

Una definición de recurso de "Ingress" para este patrón sería así:

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tenant-a-ingress
  namespace: tenant-a-namespace # Deployed in the tenant's namespace
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # For automated TLS
spec:
  rules:
    - host: "tenant-a.your-saas.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: tenant-a-service # Service within tenant-a-namespace
                port:
                  number: 80
  tls:
    - hosts:
        - "tenant-a.your-saas.com"
      secretName: tenant-a-tls-secret # Managed by cert-manager

Esta configuración garantiza que el tráfico para tenant-a.your-saas.com se dirija exclusivamente al tenant-a-service dentro del tenant-a-namespace, manteniendo una clara separación del flujo de tráfico.

4. Estrategias de aislamiento de datos

Incluso con la separación de recursos, la separación de datos es primordial. La elección aquí refleja los principales modelos de tenencia y implica importantes compromisos entre la separación, el coste y la complejidad.

• Base de datos por inquilino: Cada inquilino obtiene una instancia de base de datos dedicada. Esto ofrece la máxima separación de datos y simplifica las operaciones de copia/restauración. Sin embargo, es la opción más cara debido a los costes asociados con el funcionamiento de numerosas instancias de base de datos. Esto se puede gestionar eficazmente utilizando un operador de Kubernetes para su base de datos elegida (por ejemplo, un operador de Postgres que pueda crear nuevas instancias bajo demanda).
• Esquema por inquilino: Una única instancia de base de datos sirve a múltiples inquilinos, pero los datos de cada inquilino residen en un esquema dedicado. Esto proporciona una fuerte separación lógica con menor sobrecarga que el modelo de base de datos por inquilino. La consulta y la gestión son más complejas, ya que la capa de acceso a datos de su aplicación debe configurarse dinámicamente para conectarse al esquema correcto según el contexto del inquilino.
• Esquema compartido, diferenciado por columna: Todos los inquilinos comparten la misma base de datos y tablas. Una tenant_id en cada tabla se utiliza para separar los datos.
  • Ventajas: Mayor densidad y menor coste.
  • Desventajas: Mayor riesgo de fuga de datos debido a errores de programación (por ejemplo, la ausencia de una cláusula WHERE tenant_id = ?). Es obligatorio aplicar políticas de seguridad a nivel de fila en la base de datos para mitigar este riesgo. Este enfoque también complica la indexación, las copias de seguridad y el análisis por inquilino.

Para la mayoría de las aplicaciones SaaS, el modelo "Schema por Tenant" ofrece el mejor equilibrio entre aislamiento y coste. Tu aplicación resolvería el contexto del tenant a partir de la solicitud entrante (por ejemplo, desde un JWT o nombre de dominio) e establecería el esquema de base de datos correspondiente durante la duración de esa transacción.Estructura por inquilinoEste modelo ofrece el mejor equilibrio entre aislamiento y coste. Su aplicación resolvería el contexto del inquilino procedente de la solicitud entrante (por ejemplo, de un JWT o nombre de host) e establecería el esquema de base de datos adecuado durante la duración de esa transacción.

5. Monitoreo y medición adaptados al inquilino

En un entorno con múltiples inquilinos, debe poder asignar el uso de los recursos y supervisar el rendimiento por inquilino. Esto es esencial para identificar problemas, depurar errores e implementar la facturación basada en el consumo.

AprovechandoPrometheus con una estrategia de etiquetado consistente es fundamental. Al asegurar que cada objeto de Kubernetes asociado a un inquilino (namespaces, pods, servicios) esté etiquetado con un identificador único tenant_id, puedes crear paneles y alertas de monitoreo potentes y orientados al inquilino.

Ejemplo de un manifiesto para un "pod" con una etiqueta de inquilino:

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: tenant-a-backend-pod
  namespace: tenant-a-namespace
  labels:
    app: backend
    tenant_id: "tenant-a" # Crucial for monitoring
spec:
  containers:
    - name: backend-container
      image: my-app:1.2.3

Con esta etiqueta, puede escribir consultas de PromQL para agregar métricas por inquilino:

# Calculate total CPU usage per tenant across all their pods
sum(rate(container_cpu_usage_seconds_total{namespace=~".*-namespace"}[5m])) by (label_tenant_id)

Este enfoque le permite rastrear con precisión qué inquilinos están consumiendo más recursos, lo que posibilita una medición justa y una gestión proactiva del rendimiento.

Conclusión

Arquitectar una aplicación SaaS multiinquilino en Kubernetes es un proyecto complejo que requiere cuidadosas decisiones entre costo, aislamiento y sobrecarga operativa. El modelo híbrido "Namespace por Inquilino" proporciona una base robusta y escalable. Al aprovechar las características nativas de Kubernetes como Modelo híbrido "espacio de nombres por inquilino"ofrece una base sólida y escalable. Al aprovechar las características nativas de Kubernetes, comoNamespaces, ResourceQuotas y NetworkPolicies, puede lograr un fuerte aislamiento lógico. Esto debe complementarse con una estrategia bien diseñada de aislamiento de datos y un enfoque disciplinado para el enrutamiento y la supervisión conscientes del inquilino.

En última instancia, la arquitectura adecuada depende de sus necesidades empresariales específicas, los requisitos del cliente y las obligaciones de cumplimiento. Sin embargo, los principios delineados aquí proporcionan un marco probado para construir una plataforma segura, eficiente y con operaciones sólidas para múltiples inquilinos en Kubernetes.

Preguntas frecuentes