Arquitectura multi-inquilino SaaS con Kubernetes

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

Este artículo proporciona un plan técnico para directores técnicos 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 arrendamiento adecuado

La primera y más importante decisión arquitectónica es elegir el modelo de tenencia adecuado. Esta elección tiene un impacto directo en el coste, 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

Trabaje con nuestros gestores de proyectos, ingenieros de software y probadores 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

• Modelo de 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 ("problema del vecino ruidoso" eliminado), copia de seguridad y restauración simplificadas por inquilino, cumplimiento más fácil de los requisitos de residencia de datos.
  • Desventajas: Mayor costo debido a la baja utilización de los recursos, una importante sobrecarga operativa para la configuración y gestión de cada silo.
  • Ideal para: Clientes empresariales con estrictos requisitos de seguridad, cumplimiento (por ejemplo, HIPAA, PCI-DSS) o 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 de los recursos y eficiencia de costos, gestión simplificada de un único conjunto de infraestructura.
  • Desventajas: Mayor 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, facturació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 primordial.
• Modelo Híbrido (Semi-Aislado): Este modelo ofrece un equilibrio práctico. Los inquilinos comparten algunos recursos (por ejemplo, controladores de entrada, pila de monitoreo) mientras que tienen recursos dedicados para otros (por ejemplo, pods de aplicación, bases de datos). La implementación más efectiva de esto en Kubernetes es el modelo Namespace por Inquilino.Ventajas:
  • Buen equilibrio entre costo y aislamiento, fuerte separación lógica proporcionada por los primitivos de Kubernetes.Buen equilibrio entre coste y aislamiento, con una fuerte separación lógica proporcionada por los conceptos básicos de Kubernetes.
  • Desventajas: Requiere una gestión cuidadosa de los componentes compartidos y políticas de RBAC robustas.
  • Ideal para: La mayoría de las aplicaciones SaaS B2B modernas que requieren un equilibrio entre eficiencia de costos e un fuerte aislamiento lógico.

En el resto de este artículo, nos centraremos en el modelo "Híbrido (Espacio de nombres por inquilino)", ya que representa el patrón más flexible y ampliamente adoptado para construir SaaS multi-inquilino en Kubernetes.Híbrido (Espacio de nombres por inquilino)modelo, ya que representa el patrón más flexible y ampliamente adoptado para construir soluciones SaaS multi-inquilino en Kubernetes.

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

Utilizar un espacio de nombres de Kubernetes dedicado para cada cliente es fundamental para 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.

Aislamiento de recursos y seguridad

Dentro del espacio de nombres de cada inquilino, debe establecer límites de consumo de recursos y evitar la comunicación no autorizada entre inquilinos.

Cuotas y Rangos de Recursos:

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

Aquí se muestra un ejemplo de Recurso básico 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 pods en un clúster de Kubernetes pueden comunicarse entre sí, independientemente del namespace. Esto es inaceptable en un entorno multi-inquilino. Los objetos NetworkPolicy son cruciales para garantizar una estricta aislamiento 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 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 "rechazo por defecto" es una medida de seguridad crucial para evitar que los usuarios accedan a los servicios de los demás.

Servicios de Ingeniería de Productos

Colabore con nuestros gestores de proyectos, ingenieros de software y probadores 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 a servicios teniendo en cuenta al inquilino

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

Una definición de recurso de Ingress para este patrón sería la siguiente:

# 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 fundamental. La elección aquí refleja los principales modelos de tenencia y implica importantes compromisos entre la separación, el costo y la complejidad.

• Base de datos por inquilino: Cada inquilino obtiene una instancia de base de datos dedicada. Esto ofrece la mayor protección de datos y simplifica las operaciones de copia de seguridad/restauración. Sin embargo, es la opción más costosa debido a la sobrecarga de ejecutar 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 puede crear nuevas instancias bajo demanda).
• Esquema por inquilino: Una sola 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 lógica de aislamiento 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 en función del 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 costo.
  • 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 (RLS) 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 Inquilino" ofrece el mejor equilibrio entre aislamiento y coste. Tu aplicación resolvería el contexto del inquilino a partir de la solicitud entrante (por ejemplo, de un JWT o nombre de dominio) y 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 a partir de la solicitud entrante (por ejemplo, de un JWT o nombre de dominio) y establecería el esquema de base de datos apropiado durante la duración de esa transacción.

5. Monitoreo y medición adaptados al inquilino

En un entorno multi-inquilino, debe poder asignar el uso de los recursos y supervisar el rendimiento de forma individual para cada inquilino. Esto es esencial para identificar problemas, solucionar errores y aplicar facturación basada en el uso.

Aprovechando Prometheus 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 de monitorización y alertas potentes, adaptados a cada inquilino.

Ejemplo de un manifiesto de 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 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 realizar un seguimiento preciso de qué inquilinos están consumiendo más recursos, lo que facilita la medición justa y la gestión proactiva del rendimiento.

Conclusión

Arquitectura de una aplicación SaaS multi-inquilino en Kubernetes es un proyecto complejo que requiere consideraciones cuidadosas entre el coste, la separación y la 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 de "un 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 una fuerte separación lógica. 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 de los inquilinos.

En última instancia, la arquitectura adecuada depende de las necesidades específicas de su negocio, los requisitos de los clientes y las obligaciones de cumplimiento. Sin embargo, los principios descritos aquí proporcionan un marco probado para construir una plataforma segura, eficiente y operativa para múltiples usuarios en Kubernetes.

Preguntas frecuentes