Kubernetes Multitenancy: как перестать плодить кластеры для каждой команды

Kubernetes легко создать. Именно поэтому в компаниях быстро появляются десятки кластеров: отдельный для команды, отдельный для окружения, отдельный для особого требования, ещё один «временно». Через год platform team поддерживает зоопарк, тратит время на обновления, мониторинг, доступы, сертификаты и разные версии аддонов.

Multitenancy предлагает другой подход: несколько команд и окружений используют общий кластер или набор общих кластеров, но остаются изолированными через policies, namespaces, quotas и platform abstractions. Это не бесплатная магия, а архитектурный компромисс.

Почему кластеров становится слишком много

Отдельный кластер часто кажется самым простым решением. Команде нужен другой ingress? Поднимем кластер. Нужен отдельный namespace с повышенными правами? Поднимем кластер. Нужна тестовая среда? Ещё кластер.

Проблема проявляется позже:

• растёт стоимость инфраструктуры;
• усложняются upgrades;
• дублируется observability;
• сложнее security baseline;
• команды по-разному настраивают сеть;
• platform team теряет скорость;
• появляется drift между окружениями.

Kubernetes позволяет быстро масштабировать платформу, но без правил он масштабирует хаос.

Что такое multitenancy

Multitenancy — это модель, где несколько tenants используют общую платформу, но имеют логические границы. Tenant может быть командой, продуктом, окружением или внутренним клиентом.

В Kubernetes базовые строительные блоки:

• namespaces;
• RBAC;
• ResourceQuota;
• LimitRange;
• NetworkPolicy;
• Pod Security Standards;
• admission controllers;
• separate node pools;
• service accounts;
• policy engines вроде Kyverno или OPA Gatekeeper.

Эти механизмы позволяют дать командам самостоятельность, не отдавая им весь кластер.

Изоляция: где границы

Главный вопрос multitenancy — насколько сильная нужна изоляция. Есть разные уровни:

• soft isolation: namespaces и quotas;
• network isolation: запрет лишних соединений;
• security isolation: policies, restricted pods, запрет privileged;
• compute isolation: отдельные node pools;
• control plane isolation: отдельные кластеры.

Не все workloads можно безопасно держать вместе. Если есть жёсткие compliance-требования, разные уровни доверия или недоверенные пользователи, отдельный кластер может быть правильным решением.

Platform engineering слой

Multitenancy работает лучше, когда команды не взаимодействуют напрямую со всеми сложностями Kubernetes. Platform team может дать им понятные интерфейсы:

• шаблоны приложений;
• self-service namespace creation;
• стандартные Helm charts;
• GitOps workflow;
• predefined resource classes;
• observability по умолчанию;
• security policies без ручной настройки;
• документацию и examples.

Цель — не спрятать Kubernetes полностью, а убрать повторяющуюся эксплуатационную работу.

Quotas и fairness

В общем кластере одна команда не должна случайно съесть все ресурсы. Поэтому нужны quotas:

• CPU и memory requests/limits;
• количество pods;
• storage requests;
• LoadBalancer services;
• ingress objects;
• jobs и cronjobs.

Но quotas должны быть реалистичными. Если они слишком жёсткие, команды будут постоянно просить исключения. Если слишком мягкие — multitenancy не защитит платформу.

Network Policies

По умолчанию многие Kubernetes-кластеры слишком открыты внутри. В multitenant-среде это опасно: сервис одной команды не должен бесконтрольно ходить к сервисам другой.

Базовая стратегия:

• default deny между namespaces;
• явные разрешения для нужных связей;
• отдельные правила для ingress/egress;
• контроль доступа к shared-сервисам;
• логирование сетевых отказов.

Без сетевой изоляции namespaces дают скорее удобную организацию, чем реальную безопасность.

Когда отдельный кластер всё ещё нужен

Multitenancy не означает «один кластер для всего». Отдельный кластер оправдан, если:

• разные compliance-зоны;
• недоверенные workloads;
• разные требования к control plane;
• критичный blast radius;
• GPU/специализированное железо;
• тяжёлые noisy workloads;
• разные команды эксплуатации.

Хорошая платформа сочетает подходы: общие кластеры для типовых задач и отдельные — для обоснованных исключений.

Итог

Kubernetes Multitenancy помогает перестать плодить кластеры без причины, снизить operational overhead и дать командам self-service. Но для этого нужны policies, quotas, network isolation, RBAC и понятный platform layer.

Главный принцип: отдельный кластер должен быть архитектурным решением, а не реакцией на каждое новое требование. Тогда Kubernetes становится платформой, а не коллекцией случайных островов.