Основные понятия: многотенантность в Azure Kubernetes Service (AKS)

Отвечая на вопрос «Как настроить Kubernetes для работы в режиме мультитенантности?», архитекторы должны сначала понять концептуальные границы и доступные модели изоляции. Многотенантность в AKS — это практика выполнения нескольких изолированных рабочих нагрузок, принадлежащих разным командам, приложениям или клиентам в общем кластере Kubernetes. В этой статье подробно описаны основные понятия и архитектурные модели для многотенантности на Azure Kubernetes Service (AKS).

Tip

Каковы три модели многотенантности в AKS? Многопользовательская архитектура AKS использует спектр вариантов изоляции с тремя распространёнными моделями: изоляция пространств имён, изоляция пулов узлов и отдельный кластер для каждого арендатора. Изоляция на уровне пространств имен лучше всего подходит для доверенных внутренних команд и обеспечивает максимальную экономическую эффективность, изоляция на уровне пулов узлов обеспечивает более строгое разделение рабочих нагрузок при умеренных накладных расходах, а отдельный кластер для каждого клиента обеспечивает самую надежную изоляцию для сценариев с недоверенной средой или строгими нормативными требованиями.

Пошаговые инструкции по реализации и манифесты YAML см. в сопутствующем руководстве: Рекомендации по мультитенантности в AKS.

Почему многотенантность в AKS?

Мультитенантность позволяет нескольким командам, приложениям или клиентам совместно использовать один кластер Kubernetes. Основное обоснование многотенантности в AKS — это экономичность и операционный масштаб.

Использование выделенного кластера для каждого приложения или команды приводит к значительной фрагментации ресурсов, простоям вычислительных ресурсов и кратному увеличению накладных расходов на плоскость управления. Объединение рабочих нагрузок в кластеры с несколькими клиентами позволяет организациям максимизировать использование ресурсов и сократить расходы на облако. С операционной точки зрения мультитенантная архитектура сокращает количество кластеров, находящихся в эксплуатации, а значит, платформенным командам приходится устанавливать исправления, обновлять, отслеживать и защищать меньше кластеров, что упрощает управление их жизненным циклом.

Какова разница между мягкой и жесткой многотенантностью?

Kubernetes по сути не является многотенантной системой. Чтобы обеспечить многотенантность, необходимо предусмотреть либо «мягкую», либо «жесткую» модель изоляции в зависимости от уровня доверия между арендаторами.

Разница между мягкой и жёсткой мультитенантностью в Kubernetes заключается прежде всего в модели доверия и вытекающих из неё требованиях к изоляции. Мягкая мультитенантность предполагает доверенных внутренних тенантов и сосредоточена на предотвращении случайного взаимного влияния с помощью логических механизмов контроля, таких как пространства имён, RBAC и квоты. Строгая многотенантность предполагает низкий или нулевой уровень доверия между арендаторами и требует более строгих мер изоляции, чтобы снизить риск несанкционированного доступа, латерального перемещения и раскрытия данных.

Модель	Уровень доверия	Цель	Сценарий использования	Пример сценариев
Мягкая мультитенантность	Высокий уровень доверия между внутренними клиентами	Предотвратить случайное вмешательство, нехватку ресурсов и конфликты конфигураций	Внутренние среды платформы, в которых команды совместно используют инфраструктуру	Несколько продуктовых команд в одной организации совместно используют кластер AKS для разработки, тестирования и внутренних сервисов
Жесткая многотенантность	Низкое или нулевое доверие между клиентами	Предотвращение вредоносных атак, бокового перемещения и кражи данных	Размещение внешних клиентов и регулируемые рабочие нагрузки	Поставщик SaaS, размещающий рабочие нагрузки, специфичные для каждого клиента, для которого изоляция арендаторов является обязательным требованием безопасности и соответствия нормативным требованиям

Спектр изоляции

Многотенантность в AKS — это не выбор между двумя вариантами; она представляет собой спектр. По мере продвижения по спектру уровень изоляции возрастает, но также растут операционная сложность и затраты. Этот спектр служит организационной основой для проектирования многопользовательского кластера:

• Изоляция пространства имен (Логическая): клиенты используют одни и те же пулы узлов и плоскость управления, но разделяются логически пространствами имен Kubernetes. Это основа нестрогой мультитенантности.
• Изоляция пула узлов (физические вычислительные ресурсы): арендаторы совместно используют плоскость управления, но им выделяются отдельные рабочие узлы. Это улучшает разделение рабочих нагрузок и снижает эффект «шумного соседа», но не обеспечивает полной изоляции арендатора, поскольку компоненты управляющей плоскости и уровня кластера по-прежнему остаются общими.
• Отдельный кластер для каждого клиента (полная физическая изоляция): Клиенты полностью изолированы и имеют собственную плоскость управления AKS и собственную плоскость данных. Это предельная форма жёсткой мультитенантности, фактически отказывающаяся от совместного использования на уровне Kubernetes в пользу изоляции на уровне Azure.

Базовые компоненты AKS для мультитенантной архитектуры

AKS предоставляет набор встроенных и интегрированных с Azure примитивов для обеспечения всего спектра изоляции.

• Microsoft Entra ID. Обеспечивает централизованное управление удостоверениями и доступом для проверки подлинности пользователей и автоматизированных систем в API Kubernetes.
• Azure RBAC: сопоставляет удостоверения Microsoft Entra ID с разрешениями Kubernetes, гарантируя, что клиенты могут получать доступ только к авторизованным ресурсам.
• Управляемые пространства имён: обеспечивают логические границы внутри кластера для группировки ресурсов арендатора, применения квот и разграничения доступа.
• Политика Azure / Gatekeeper: применяет централизованные правила соответствия и управления в кластере, чтобы предотвратить развертывание небезопасных или несанкционированных конфигураций клиентов.
• Azure CNI: обеспечивает встроенную интеграцию виртуальной сети для сети AKS и поддерживает сегментацию трафика клиента с помощью элементов управления политикой сети. Поведение IP-адреса пода зависит от выбранного режима CNI (например, Overlay или Pod Subnet).
• Службы сетевого взаимодействия контейнеров Azure (ACNS) Cilium L7: обеспечивают высокопроизводительные сетевые политики на основе eBPF и фильтрацию трафика уровня 7 для строгой изоляции сетевого трафика арендатора.
• Удостоверение рабочей нагрузки: позволяет отдельным подам безопасно аутентифицироваться во внешних службах Azure с помощью федеративной идентичности, устраняя общие секреты между арендаторами.

Сопоставление уровней изоляции между плоскостями

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

самолёт	Description	Примененные примитивы AKS
Контрольная плоскость	Защита доступа к серверу API Kubernetes и логическим границам.	Microsoft Entra ID, Azure RBAC, управляемые пространства имен
Плоскость данных	Защита сетевого трафика, выполнения вычислений и границ на уровне узла.	Azure CNI, ACNS Cilium L7, пулы узлов
Уровень ресурсов	Управление потреблением вычислительных ресурсов, внешним доступом и соответствием конфигурации.	Политика Azure, идентификатор рабочей нагрузки

Какую модель изоляции следует выбрать?

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

Модель изоляции	Уровень безопасности	Рентабельность	Сложность эксплуатации	Лучше всего подходит для
Пространство имён для каждого арендатора	Низкий до среднего (логический)	Высокий (максимальный общий доступ)	Низкий (управление одним кластером)	Внутренние команды, среды разработки и тестирования, нестрогая многотенантность.
Пул узлов для каждого арендатора	Высокий (с изолированными вычислительными ресурсами)	Средний (общий уровень управления)	Средний (управление оттенками и терпимостями)	Внутренние и внешние рабочие нагрузки, которым требуется более строгая изоляция вычислительных ресурсов при совместном использовании плоскости управления; не лучший вариант для многоарендности zero-trust с потенциально враждебными арендаторами.
Кластер на клиент	Наивысший (физический)	Низкая (высокие накладные расходы)	Высокий (требуется управление флотом)	Враждебная многотенантная среда, внешние корпоративные заказчики, модель нулевого доверия.

Когда следует использовать каждую модель

• Используйте отдельное пространство имён для каждого арендатора, если арендаторы являются внутренними или доверенными, приоритетом является экономическая эффективность, а средств логической изоляции достаточно.
• Используйте отдельный пул узлов для каждого арендатора, если требуется более строгое разделение вычислительных ресурсов и снижение влияния «шумных соседей», при этом используя общую плоскость управления AKS.
• Используйте кластер для каждого клиента, если клиенты ненадежны, нормативные границы являются строгими, или модель риска требует минимальной общей инфраструктуры.

Дальнейшие действия

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

• Рекомендации по многотенантности в AKS

Итог

• Многотенантность в Azure Kubernetes Service (AKS) — это практика выполнения нескольких изолированных рабочих нагрузок клиента в общей инфраструктуре Kubernetes для снижения затрат и упрощения операций.
• Модель «одно пространство имён на арендатора» — наиболее экономически эффективный вариант для доверенных внутренних нагрузок, поскольку она обеспечивает максимальное совместное использование инфраструктуры, сохраняя при этом логические границы.
• Подход node-pool-per-tenant улучшает изоляцию вычислительных ресурсов и контроль влияния «шумных соседей», но по-прежнему использует общую плоскость управления AKS и другие общие компоненты уровня кластера.
• Кластер для каждого клиента обеспечивает самую надежную изоляцию клиентов для сценариев нулевого доверия и строго регулируемых сценариев, но для этого требуется более высокая стоимость и больше операционных затрат.