Multi-tenancy и vCluster
Тема дорожной карты · Kubernetes
Мультитенантность в Kubernetes — архитектура совместного использования одного кластера несколькими командами, проектами или клиентами при обеспечении изоляции ресурсов, доступа и радиуса поражения между тенантами. Изоляция на основе пространств имён — наиболее распространённый подход: каждый тенант получает выделенный Namespace Kubernetes с ограниченными объектами RBAC Role и RoleBinding, ResourceQuota для ограничения CPU, памяти и количества объектов, а также LimitRange для установки значений requests и limits по умолчанию для Pod'ов. Сетевая изоляция между пространствами имён тенантов обеспечивается через NetworkPolicy Kubernetes или политики уровня service mesh, предотвращающие несанкционированный межпространственный трафик внутри кластера. Более жёсткие границы изоляции достигаются с помощью виртуальных кластеров (vcluster), выделенных пулов узлов в сочетании с taints и tolerations или Hierarchical Namespace Controller из проекта kubernetes-sigs/hierarchical-namespaces. Движки политик OPA Gatekeeper и Kyverno обеспечивают защитные барьеры на уровне тенанта — предотвращают выход Pod'ов за пределы пространства имён, требуют соблюдения соглашений об именовании меток и блокируют привилегированные контейнеры, — что делает мультитенантность в Kubernetes операционно безопасной в масштабе.
Как это работает
Multi-tenancy и vCluster покрывает day-2 работу эксплуатации Kubernetes-кластера: обновления, node maintenance, capacity planning, backup и DR, оптимизация стоимости, multi-tenancy изоляция. Обновления следуют графику deprecation Kubernetes (один minor каждые 4 месяца); node maintenance использует cordon + drain; backups через Velero или CSI snapshots. DR требует регулярных тренировок — не только документации.
Когда применять
Установите Multi-tenancy и vCluster практики до того, как кластер станет критичным для выручки. Запланируйте первую DR-тренировку в течение 30 дней после go-live; задокументируйте процедуру обновления до того, как первая версия станет EOL; настройте cost-дашборды (Kubecost, OpenCost) до того, как счёт станет сюрпризом. Operations-долг копится тихо — гасите его по каденции, не в режиме паники.
Типичные ошибки
Ловушки cluster operations: пропуск minor-обновлений до принуждения (3+ версий позади = кошмар обновления); cluster-wide cluster-admin tokens, которые никто не ротирует; нет задокументированного runbook на случай "control plane умер" (реальная возможность на self-managed кластерах); cost-сюрпризы (idle GPU-ноды, over-provisioned requests, orphan PVCs). Тренируйте incident response на non-production кластере ежемесячно.