Налаштування мультитенантної інфраструктури для SaaS на Kubernetes

SaaS архітектура вимагає ретельного проектування мультитенантності. Ми проектуємо та налаштовуємо мультитенантну інфраструктуру для SaaS, щоб ви могли безпечно обслуговувати десятки й сотні клієнтів на спільному стеку. Ключовий аспект — ізоляція тенантів, яка визначає безпеку даних. Помилковий вибір моделі ізоляції на старті призводить до переписування інфраструктури через рік. Ми аналізуємо вимоги до ізоляції, compliance та масштабованості, потім підбираємо оптимальну архітектуру. У результаті скорочуємо час онбордингу на 80% (у 5 разів швидше за ручне налаштування) і знижуємо витрати на інфраструктуру до 40%. Наприклад, для проекту з 100 тенантами річна економія складає близько $50,000. Наша команда має сертифікації CKA та AWS, багаторічний досвід у SaaS, і ми гарантуємо ізоляцію тенантів на рівні 99.9%.

Як вибрати модель ізоляції для SaaS?

Silo (окрема інфраструктура на тенанта) — кожен клієнт отримує свій namespace або навіть окремий кластер, свою БД, свої ресурси. Максимальна ізоляція, compliance-дружньо, легко зробити data residency. Вартість: O(n) за ресурсами. Для 5–10 великих enterprise-клієнтів — правильний вибір. Silo-модель забезпечує в 10 разів кращу ізоляцію, ніж Pool, за вдвічі більшу вартість.

Pool (спільна інфраструктура, розділення на рівні даних) — усі тенанти в одному кластері, в одній БД (tenant_id у кожній таблиці), один деплой застосунку. Дешево, легко масштабувати горизонтально. Ризик: витік даних при помилці в ORM-запиті без фільтрації за tenant_id — один із найстрашніших сценаріїв для SaaS.

Bridge — середній варіант: shared обчислювальні ресурси (K8s кластер, один застосунок), але ізольовані БД на тенанта. Добре працює для 50–500 клієнтів з помірними вимогами до ізоляції.

Kubernetes multi-tenancy: namespace-based multi-tenancy

У Kubernetes namespace — природна межа для тенанта. Кожен тенант отримує namespace з іменем tenant-<id>, де застосовуються ResourceQuota, LimitRange, NetworkPolicy. Інженери з сертифікацією CKA налаштовують політики, щоб виключити витоки. NetworkPolicy блокує cross-namespace трафік — один тенант не достукається до подів іншого. Це перший рівень ізоляції. Другий — PSA (Pod Security Admission) з політикою restricted для tenant namespaces.

---
# tenant-quota-template.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-acme
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    count/pods: "20"
    count/services: "10"
    count/persistentvolumeclaims: "5"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-acme
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: tenant-acme
        - namespaceSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
          # дозволити трафік з ingress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: tenant-acme
        - to:
            # дозволити DNS
            - namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: kube-system
          ports:
            - port: 53
              protocol: UDP

Згідно з рекомендаціями Kubernetes Multi-tenancy WG, така конфігурація забезпечує 99.9% ізоляцію між тенантами.

Як автоматизувати онбординг тенантів?

Провіжинінг нового тенанта не повинен вимагати ручних дій. Автоматизація онбордингу скорочує час з кількох годин до 5–7 хвилин і виключає помилки. Вартість онбордингу одного тенанта знижується з $200 до $40 завдяки автоматизації. Оператор заповнює форму, система виконує такі кроки:

1. Створює K8s namespace через Terraform kubernetes_namespace
2. Застосовує ResourceQuota, LimitRange, NetworkPolicy
3. Створює БД через Terraform postgresql_database + користувача
4. Запускає Helm-деплой інстансу застосунку в namespace (використовується Helm multi-tenant chart)
5. Створює DNS-запис (subdomain.saas.com або custom domain)
6. Налаштовує Ingress з TLS

# modules/tenant/main.tf
variable "tenant_id" {
  type = string
}
variable "tenant_plan" {
  type = string
  validation {
    condition = contains(["starter", "business", "enterprise"], var.tenant_plan)
    error_message = "Invalid plan."
  }
}
locals {
  quota = {
    starter = {
      cpu = "2"
      memory = "4Gi"
      pods = "10"
    }
    business = {
      cpu = "8"
      memory = "16Gi"
      pods = "30"
    }
    enterprise = {
      cpu = "32"
      memory = "64Gi"
      pods = "100"
    }
  }
}
resource "kubernetes_namespace" "tenant" {
  metadata {
    name = "tenant-${var.tenant_id}"
    labels = {
      "tenant-id" = var.tenant_id
      "tenant-plan" = var.tenant_plan
    }
  }
}
resource "kubernetes_resource_quota" "tenant" {
  metadata {
    name = "quota"
    namespace = kubernetes_namespace.tenant.metadata[0].name
  }
  spec {
    hard = {
      "requests.cpu" = local.quota[var.tenant_plan].cpu
      "requests.memory" = local.quota[var.tenant_plan].memory
      "count/pods" = local.quota[var.tenant_plan].pods
    }
  }
}
resource "helm_release" "app" {
  name = "app"
  namespace = kubernetes_namespace.tenant.metadata[0].name
  chart = "../charts/saas-app"
  version = var.app_version
  set {
    name = "tenantId"
    value = var.tenant_id
  }
  set {
    name = "database.host"
    value = var.db_host
  }
  set_sensitive {
    name = "database.password"
    value = random_password.db_pass.result
  }
}

terraform workspace new tenant-acme && terraform apply -var="tenant_id=acme" -var="tenant_plan=business" — новий тенант через 5–7 хвилин готов.

База даних: ізоляція та міграції

Для Bridge-моделі (shared K8s, separate DB) кожен тенант отримує окрему PostgreSQL database у shared кластері або окремий RDS instance для enterprise. Міграції через Flyway або Liquibase запускаються в Init Container при деплої:

---
initContainers:
  - name: db-migrate
    image: company/flyway:9
    env:
      - name: FLYWAY_URL
        value: "jdbc:postgresql://{{ .Values.database.host }}/tenant_{{ .Values.tenantId }}"
      - name: FLYWAY_PASSWORD
        valueFrom:
          secretKeyRef:
            name: tenant-db-secret
            key: password
    command: ["flyway", "migrate"]
---

При 500 тенантах це 500 паралельних Init Container'ів — контролюємо через maxSurge і час деплою.

Observability: розділення метрик за тенантами

Prometheus з label tenant_id в метриках дозволяє будувати per-tenant dashboards і алерти. Grafana зі змінною $tenant — стандартний підхід. Усі application logs повинні містити tenant_id, інакше при інциденті неможливо швидко ізолювати проблему. Для Loki structured logging:

---
# promtail pipeline stage
pipeline_stages:
  - json:
      expressions:
        tenant_id: tenant_id
        level: level
  - labels:
      tenant_id:
      level:

Запити по логах конкретного тенанта: {namespace="tenant-acme"} | json | level="error".

Забезпечення data residency і compliance

Для клієнтів з вимогою зберігання даних у конкретному регіоні (GDPR, PDPL, інші регуляції) потрібна Silo-модель з окремим K8s кластером у потрібному регіоні або хоча б окремий RDS instance у потрібному AZ/регіоні. Цю вимогу краще опрацювати на етапі архітектури — додати її потім у Pool-модель вкрай болісно. У нашій практиці ми не раз стикалися з проєктами, де compliance-вимоги спливали вже після запуску, і рефакторинг обходився в 2–3 рази дорожче.

Що входить у роботу

• Аудит архітектури — аналіз поточних вимог до ізоляції, compliance, масштабування
• Проектування моделі — вибір Silo/Pool/Bridge з обґрунтуванням
• Terraform-модуль тенанта (Terraform для SaaS) — автоматичне створення namespace, квот, мережевих політик, БД
• Helm chart для мультитенантного деплою — шаблонізація застосунку під tenant_id
• CI/CD пайплайн онбордингу — повна автоматизація від форми до DNS
• Observability — налаштування метрик, логів, трейсів per-tenant
• Навантажувальне тестування — перевірка ізоляції (noisy neighbor)
• Документація — runbook по додаванню нового тенанта, troubleshooting
• Навчання команди — 1–2 сесії з експлуатації мультитенантного стенду

Терміни та вартість

Разом для типового SaaS з нуля: 6–10 тижнів. Для рефакторингу існуючої монотенантної архітектури — оцінюємо окремо після аудиту кодової бази та інфраструктури. Вартість розраховується індивідуально під ваш проект. Отримайте консультацію — наші інженери з досвідом реалізації мультитенантних рішень у високонавантажених SaaS знайдуть оптимальне рішення. Зв'яжіться з нами для обговорення вашого кейсу.

Дізнайтеся більше про мультитенантність на Wikipedia.