«У нас тридцать два кластера» - эту фразу руководитель platform engineering произнёс почти шёпотом, будто признавался в чём-то постыдном. Девять продуктовых команд, шесть окружений на каждую - и никто не принимал сознательного решения довести инфраструктуру до такого состояния. Оно просто росло. По одному кластеру за раз.
Как тридцать два кластера убивают инженерную команду
История знакома почти каждой компании, добравшейся до определённого масштаба. Цифра меняется - иногда двенадцать, иногда шестьдесят. Суть одна. Kubernetes позволяет поднять новый кластер за минуты, и всякий раз, когда команде нужно было «что-то чуть иное», самым лёгким ответом оказывалось именно это.
Экономика такого роста жестока. Только на EKS control plane каждый кластер обходится в 73 доллара в месяц - ещё до единой запущенной рабочей нагрузки. Тридцать два кластера превращаются в 2336 долларов ежемесячно на пустом месте. Прибавьте node pool'ы, мониторинг, патчи безопасности, обновления - и операционная нагрузка начинает буквально поглощать команду. По данным ежегодного исследования CNCF 2025 года, 78% организаций ожидают роста числа команд, развёртывающих приложения в кластере. Больше команд - больше окружений. Без стратегии это неизбежно выливается в ещё больше кластеров.
Три модели multitenancy: что выбрать
Ответ на cluster sprawl - multitenancy. Kubernetes не проектировался под него изначально, но именно этот подход стал стандартом для зрелых платформенных команд в 2026 году. Инструментарий дозрел, паттерны устоялись.
Существуют три принципиально разные модели, и выбор между ними - самое важное решение до старта любых работ:
- Программная tenancy на основе namespace - общий кластер, общие узлы, изоляция через RBAC, NetworkPolicies и ResourceQuotas. Быстро, дёшево, подходит для внутренних команд с базовым уровнем доверия. Не защищает от намеренных атак.
- Виртуальные кластеры (vCluster) - каждый тенант видит «свой» кластер с полноценным API server, но физически всё работает на общих узлах хоста. Значительно сильнее изолирует, чем namespace-модель, и дешевле выделенных кластеров. Оптимально для SaaS-продуктов и команд, которым нужны права на уровне кластера.
- Выделенные кластеры - максимальная изоляция и максимальная стоимость. Оправдана там, где модель угроз предполагает враждебных тенантов или где compliance прямо требует аппаратного разделения.
Четыре слоя изоляции: пропустить нельзя ни одного
Независимо от выбранной модели, нормальный multitenancy требует проработки четырёх уровней изоляции. Большинство команд закрывают первые два - RBAC и сетевые политики - и бросают остальное на полдороге. Это не мелкая недоработка. Каждый пропущенный слой - готовый вектор влияния одного тенанта на другого.
Консолидация кластеров сейчас в повестке почти каждой инженерной организации, где всерьёз занялись FinOps. Multitenancy - та самая инженерная работа, которая делает эту консолидацию осмысленной, а не авантюрой. Плюс растущие compliance-требования в финансах, здравоохранении и госсекторе: регуляторы всё настойчивее требуют задокументированной изоляции на каждом уровне. Тридцать два кластера с разной конфигурацией безопасности этот запрос не закрывают. Грамотно выстроенный multitenancy - закрывает.
