«Один кластер на несколько команд»: AWS показала multi-tenant схему SageMaker HyperPod с изоляцией, квотами и chargeback

Задача: дорогой GPU-кластер на несколько команд

AWS описывает типичную ситуацию: команда data science обучает большие языковые модели, подразделение компьютерного зрения запускает inference-нагрузки, а исследовательская группа экспериментирует с новыми архитектурами — и всем им нужен доступ к одному и тому же дорогому GPU-кластеру, но с сохранением границ изоляции, справедливостью в распределении ресурсов и операционной самостоятельностью.

Без продуманной архитектуры, рассчитанной на несколько команд, организация получает четыре проблемы одновременно: неконтролируемое потребление ресурсов, слабую изоляцию между командами, невозможность отнести стоимость общего GPU-времени к тем, кто её создаёт, и административные накладные расходы, которые тормозят работу. Именно эти четыре пункта референсная архитектура и должна закрыть.

Основа схемы — Amazon SageMaker HyperPod, сервис, который берёт на себя управление крупными compute-кластерами для генеративного ИИ. Кластеры оркестрируются Amazon Elastic Kubernetes Service (Amazon EKS) или Slurm, а сервис автоматически следит за здоровьем узлов, восстановлением после сбоев и жизненным циклом кластера.

Как устроена схема

В примере AWS две команды — Team A и Team B — делят один кластер HyperPod на EKS, и каждая работает в собственном namespace. Архитектура разложена на слои слева направо: от личности пользователя через авторизацию к изолированным рабочим пространствам на кластере.

Роли элементов распределены так: AWS IAM Identity Center отвечает за централизованную аутентификацию, отдельные SageMaker AI-домены дают каждой команде свою рабочую среду с настроенным опытом, Kubernetes namespaces служат изоляцией нагрузок, HyperPod Task Governance обеспечивает справедливое распределение ресурсов, а аллокация затрат на уровне namespace даёт видимость расходов по командам и основу для chargeback.

Внутри кластера AWS показывает два сквозных слоя платформы — HyperPod Observability для мониторинга и дашбордов и HyperPod Task Governance для квот и приоритетов в планировании. Под ними кластер разделён на Namespace A и Namespace B, и в каждом команда может запускать свои HyperPod Spaces — интерактивные среды разработки, HyperPod PyTorch jobs — задачи распределённого обучения и HyperPod Inference endpoints — сервинг моделей.

Аутентификация и доступ

Пользователь попадает в систему двумя путями, и оба аутентифицируются через портал AWS IAM Identity Center, который федеративен с внешним провайдером идентичности, — в примере это Microsoft Entra ID. Первый путь — командная строка: пользователь выполняет aws sso login, получает временные учётные данные из permission set своей команды и отправляет задачи прямо в кластер EKS через kubectl. Второй — сам портал: в нём выбирается приложение SageMaker Studio, и вход ведёт в домен команды.

Каждой команде соответствует свой permission set, а Identity Center автоматически создаёт для него IAM-роль — она и выступает IAM-принципалом при входе через aws sso login. Отдельно описаны per-team IAM-роли: они дают доступ к API SageMaker AI, к S3 с ограничением по префиксам бакета команды, к CloudWatch за логами и метриками, а также к EKS — с разрешениями eks:AccessKubernetesApi и eks:MutateViaKubernetesApi, которые нужны графическому интерфейсу Studio, чтобы делать вызовы Kubernetes API от имени пользователя.

У роли есть и требования к доверию: в trust policy должен быть указан sagemaker.amazonaws.com, чтобы SageMaker AI мог принимать роль за пользователя при работе через Studio. Если ту же роль планируется переиспользовать как EKS Pod Identity для нагрузок внутри кластера, в trust policy добавляется и pods.eks.amazonaws.com. Доступ командной строки при этом идёт через отдельный permission set со своими политиками, поэтому CLI-права можно ограничивать независимо.

Изоляция: namespaces, сеть и EKS access entries

На уровне кластера multi-tenancy держится на Kubernetes namespaces и записях доступа EKS. Каждой команде создаётся свой namespace — в примере hyperpod-ns-team-a и hyperpod-ns-team-b, — который служит логической границей и отделяет Spaces, задачи обучения и inference-эндпоинты одной команды от другой. Namespace можно создать вручную через kubectl create namespace или доверить это HyperPod Task Governance, который управляет namespace как частью конфигурации квот и планирования.

AWS честно оговаривает пределы этой изоляции: namespace — это граница изоляции, но не жёсткая граница безопасности. Архитектура рассчитана на несколько команд внутри одной организации, которые делят кластер в общем административном домене и имеют базовое взаимное доверие; она не предназначена для изоляции взаимно недоверенных тенантов. Namespaces, RBAC и квоты предотвращают случайные конфликты, но не защищают от намеренно враждебного тенанта: поды в namespace делят одни узлы и ядро, а cluster-scoped ресурсы — узлы, PersistentVolumes, CRD и часть компонентов операторов — находятся вне namespace. Для недоверенных тенантов или жёсткой регуляторной изоляции AWS советует более сильные границы: отдельные кластеры или аккаунты, выделенные node pools и runtime sandboxing.

Сеть namespace не ограничивает. По умолчанию сеть Kubernetes плоская: любой под видит любой другой под во всех namespace, поэтому без дополнительных контролей под из одного namespace сможет открыть соединение с подом из другого. Рекомендованный шаблон — режим default-deny для каждого namespace через NetworkPolicy: сначала запретить весь входящий трафик, а затем явно разрешить нужное — обмен внутри namespace и необходимый исходящий трафик вроде DNS, хранилищ и API AWS. Применение NetworkPolicy зависит от CNI, который её поддерживает; на EKS поддержку можно включить в Amazon VPC CNI.

Связку IAM и прав Kubernetes обеспечивают EKS access entries. На каждую команду создаются две записи: одна для роли исполнения домена SageMaker AI, то есть для действий из интерфейса Studio, и вторая для роли, которую Identity Center создаёт под permission set команды, — она используется при работе через kubectl. Обе записи ограничены namespace команды, поэтому и из Studio, и из командной строки пользователь работает только со своими ресурсами, а попытка обратиться к чужому namespace возвращает ошибку Kubernetes Forbidden.

Справедливость: HyperPod Task Governance

Когда на кластере включён Task Governance, добавляется слой управления ресурсами. Он задаёт квоты на GPU и CPU для каждой команды — чтобы одна команда не монополизировала общее оборудование во время обучения. Он же расставляет приоритеты: критичным production-нагрузкам inference можно разрешить вытеснять экспериментальные задачи обучения, когда ресурсы ограничены.

Третий элемент — справедливое планирование: когда несколько команд конкурируют за ресурсы, распределение идёт по настроенным политикам, а не по принципу «кто первый пришёл». AWS советует настраивать квоты и приоритеты по namespace каждой команды, балансируя между гарантированным минимумом и возможностью кратковременно превышать его для пиковых нагрузок.

Хранилище: POSIX-права и S3

Для распределённого обучения, где несколько узлов читают один набор данных или пишут чекпоинты, нужна общая высокопроизводительная POSIX-совместимая файловая система. AWS перечисляет варианты: Amazon FSx for Lustre с высокой пропускной способностью и низкой задержкой, Amazon FSx for OpenZFS с сильной POSIX-семантикой, снапшотами и сжатием, а также Amazon Elastic File System (Amazon EFS) с точками доступа, которые упрощают изоляцию каталогов по командам через принудительные UID и GID.

Раскладка обычно такая: у команды есть общий каталог, например /fsx/TeamA или /fsx/TeamB, для наборов данных, моделей и артефактов, а у пользователя — личный домашний каталог вроде /home/User1. Права в такой файловой системе опираются на UID, GID и дополнительные группы, и эту POSIX-идентичность нужно переносить в security context пода, когда пользователь запускает Space или отправляет задачу обучения, — иначе доступ к файлам не будет учитывать владельца и права. AWS рекомендует делать это через mutating admission webhook: он смотрит идентичность отправителя во время приёма запроса, находит соответствующую запись в хранилище соответствий и прописывает в под runAsUser, runAsGroup, fsGroup и дополнительные группы.

Для объектного хранилища доступ к бакетам S3 определяется IAM-ролью исполнения команды. Можно завести по бакету на команду или использовать общий бакет с префиксами, полагаясь на политики IAM; поды в кластере аутентифицируются в S3 через IAM Roles for Service Accounts (IRSA) или Pod Identity, а для простоты ту же роль исполнения домена можно связать с сервисным аккаунтом в namespace команды — тогда доступ к S3 будет одинаковым и из Studio, и из нагрузок кластера.

Кто сколько потратил: аллокация затрат и chargeback

В среде, где команды делят дорогую GPU-инфраструктуру, нужно понимать, кто что потребляет, — иначе не выстроить ни подотчётность, ни бюджетирование, ни chargeback. Эту задачу закрывает Kubecost: он раскладывает расходы внутри кластера по нативным понятиям Kubernetes — namespace, label, deployment и service — и сопоставляет их с организационными сущностями вроде команды, проекта или среды.

Поскольку в этой архитектуре каждая команда уже изолирована в своём namespace, аллокация на уровне namespace напрямую совпадает с границами команд, и администратор платформы получает разбивку потребления GPU, CPU, памяти, хранилища и сети по командам без дополнительной разметки нагрузок. На дашборде Allocations расходы группируются по namespace, что даёт разбивку по команде, а представления можно ограничить её namespace, чтобы каждая команда видела только свои данные и тренды.

Там же настраиваются пороги бюджетов и оповещения — команды и администраторы платформы получают сигнал, когда расходы приближаются к заданному лимиту, что работает на те же цели справедливости, что и Task Governance. Отчёты по namespace можно использовать и для внутреннего chargeback, то есть выставления командам счёта за их потребление, и для showback — отчётности о потреблении без выставления счёта; в обоих случаях финансы и платформа получают данные, чтобы честно относить стоимость общего GPU-времени.

Что важно понимать

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

Второе: у схемы есть явная граница применимости. AWS отдельно предупреждает, что целевой сценарий — команды внутри одной организации с базовым взаимным доверием, а не изоляция между взаимно недоверенными арендаторами; для последнего нужны отдельные кластеры или аккаунты, выделенные node pools и runtime sandboxing. Это снимает распространённое заблуждение, что namespace сам по себе является уровнем безопасности.

Третье: набор базовых паттернов AWS считает долгоживущим. Федерация идентичности, изоляция через namespace, RBAC, управление по квотам и аллокация затрат описаны как фундаментальные элементы, которые останутся применимыми. Тот же подход, по словам компании, можно распространить и на HyperPod Slurm-кластеры — чтобы дать командам единый multi-tenant опыт поверх разных оркестраторов.