AWS Machine Learning Blog

Share GPU clusters across teams with isolation and fairness using Amazon SageMaker HyperPod

6.9内容质量
Share GPU clusters across teams with isolation and fairness using Amazon SageMaker HyperPod

TL;DR · AI 摘要

Share GPU clusters across teams with isolation and fairness using Amazon SageMaker HyperPod Artificial Intelligence Shar...

核心要点

  • 主题聚焦：Share GPU clusters across teams with isolation a
  • 来源：AWS Machine Learning Blog，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

使用 Amazon SageMaker HyperPod 在团队间共享 GPU 集群并实现隔离与公平性 | 人工智能

使用 Amazon SageMaker HyperPod 在团队间共享 GPU 集群并实现隔离与公平性

同一公司内的多个团队对昂贵的 GPU 集群的共享访问需求日益增长，同时需要保持隔离边界、资源公平性和运营独立性。设想一个训练大型语言模型的数据科学团队、运行推理工作负载的计算机视觉团队，以及实验新模型架构的研究团队。他们可能都需要访问同一集群。如果没有精心设计的多租户（多团队）架构，组织将面临资源消耗失控、团队间隔离薄弱、无法将共享 GPU 成本归因于产生成本的团队，以及因管理开销而减缓创新的问题。

Amazon SageMaker HyperPod 是一项专为 AI 服务打造的解决方案，简化了大规模计算集群的管理，适用于生成式 AI 工作负载。它通过 Amazon Elastic Kubernetes Service（Amazon EKS）或 Slurm 提供弹性且优化的集群，使组织能够按规模运行分布式训练、交互式开发和模型推理。同时，它自动处理节点健康监控、故障恢复和集群生命周期管理。

在本文中，我们将介绍如何在 Amazon SageMaker HyperPod 与 EKS 上构建多租户环境的参考架构。该架构使用 AWS IAM Identity Center 进行集中认证、按团队划分的 SageMaker AI 域以实现定制化用户体验、Kubernetes 命名空间进行工作负载隔离、HyperPod 任务治理实现公平资源分配，以及命名空间级别的成本分配以实现按团队支出可视化和费用分摊。阅读完本文后，您将获得一个清晰的蓝图，使多个团队能够高效共享单个 HyperPod EKS 集群。

架构概述

下图展示了多租户 HyperPod EKS 部署的高层架构。在此示例中，两个团队（团队 A 和团队 B）共享一个 HyperPod EKS 集群，每个团队都在其独立的命名空间内运行。

图1：两个团队共享一个 HyperPod EKS 集群的多租户架构概述

该架构从左到右以分层流程构建，通过授权控制将用户身份连接到集群上的隔离工作负载命名空间。

用户与认证

在最左侧，每个团队的用户（团队 A 的用户 1、团队 B 的用户 2）通过两条路径与系统交互。这两条路径均通过 AWS IAM Identity Center 门户进行认证，该门户与底部左侧显示的外部身份提供商（如 Microsoft Entra ID）进行联合认证。

第一条路径是通过 CLI 访问。用户使用 aws sso login 进行认证，该命令会将用户重定向到 Identity Center 门户，然后从其团队的权限集获取临时凭证，通过 kubectl 直接提交任务到 EKS 集群。在图中，粉红色箭头从 CLI 终端顶部直接流入 HyperPod EKS 集群。

第二条路径是通过 Identity Center 门户直接访问，用户选择 SageMaker Studio 应用程序以登录到其团队特定的 SageMaker AI 域。

每个团队都有一个对应的权限集（TeamA权限集、TeamB权限集），其中包含CLI工作流程所需的AWS Identity and Access Management（IAM）策略。Identity Center会自动为每个权限集分配一个IAM角色，如图中所示为TeamA-permissionset-role和TeamB-permissionset-role（标记为“CLI/Console角色”）。该角色在用户通过aws sso login进行身份验证时作为IAM主体。

SageMaker AI域

通过Identity Center门户，用户将被路由到其所属团队的特定SageMaker AI域。每个域（SageMaker AI域Team A和SageMaker AI域Team B）都提供一个专用的Amazon SageMaker Studio图形界面，并配置了团队专属的执行角色（TeamA-role和TeamB-role）。这些域作为主要工作区界面，用户可通过图形界面提交任务（如图中所示的粉红色箭头流向EKS）。

EKS访问控制

在EKS边界，访问条目将IAM角色映射到Kubernetes权限。图中显示了TeamA-role和TeamB-role（Studio执行角色）的访问条目，用于授权来自SageMaker Studio图形界面的请求。还需要为Identity Center分配的CLI/Console角色（TeamA-permissionset-role和TeamB-permissionset-role）配置访问条目，以授权通过kubectl传入的请求。所有访问条目均关联到托管或自定义基于角色的访问控制（RBAC）策略（由钥匙图标表示），并限定在团队指定的命名空间内。因此，无论访问来自Studio还是CLI，用户只能与其所在命名空间内的资源进行交互。

HyperPod EKS集群

集群本身在顶部展示了两个跨平台层：HyperPod可观测性（用于监控和仪表板）和HyperPod任务治理（用于计算配额管理和调度优先级）。在这两层之下，集群被划分为Namespace A（Team A）和Namespace B（Team B）。在每个命名空间内，团队可以运行自己的HyperPod Spaces（交互式开发环境）、HyperPod PyTorch作业（分布式训练工作负载）和HyperPod推理端点（模型服务）。

存储

集群下方的架构包含两个存储层级。第一层是符合POSIX标准的文件系统（Amazon FSx for Lustre或Amazon FSx for OpenZFS），按团队划分共享目录（/fsx/TeamA、/fsx/TeamB）和用户主目录（/home/User1、/home/User2）。第二层是按团队或共享的Amazon Simple Storage Service（Amazon S3）存储桶，用于对象存储，由团队的IAM执行角色管理。

此架构从身份验证到工作负载执行，实现了对每个团队的隔离，同时高效共享昂贵的GPU基础设施。

认证与访问控制

任何多租户系统的基石是强大的认证机制：在用户与任何资源交互之前验证用户身份。在此架构中，AWS IAM Identity Center作为集中式认证层，与外部身份提供商联合，管理用户身份和组成员资格。

为何选择AWS IAM Identity Center

AWS IAM Identity Center（AWS单点登录的继任者）为跨AWS账户和应用程序的员工身份提供了一个统一的管理平台。对于多租户HyperPod部署，它提供了以下关键功能：

  • 集中式身份管理 – 无需为每个 AWS 服务维护单独的用户数据库，Identity Center 为所有用户身份及其组成员关系提供统一的权威来源。
  • 与现有身份提供商联合 – 大多数企业已经在 Microsoft Entra ID（原 Azure AD）、Okta 或 Ping Identity 等系统中管理员工身份。Identity Center 可与这些提供商集成，使组织能够复用现有身份基础设施，无需重复创建用户账户。
  • 与 SageMaker AI 原生集成 – SageMaker AI 域支持 Identity Center 认证，用户可通过企业身份提供商使用单点登录（SSO）功能访问 SageMaker Studio。
  • AWS 账户访问 – Identity Center 还可通过特定的权限集授予用户对底层 AWS 账户的访问权限，这些权限集可与 Studio 图形界面体验配合使用 CLI 工作流。
  • Amazon Managed Grafana 的必需组件 – Amazon Managed Grafana 使用 Identity Center 作为员工用户的认证机制，当团队需要访问监控工作负载的可观测性仪表板时，这是自然的选择。

了解更多：什么是 IAM Identity Center

将 Identity Center 与外部身份提供商配置

在本参考架构中，我们使用 Microsoft Entra ID 作为外部身份提供商，尽管相同模式也适用于大多数标准安全断言标记语言（SAML）2.0 提供商。

配置包括以下内容：

  • 身份提供商中的组结构 – 在 Entra ID 中创建与组织团队对应的组。在我们的示例中，我们定义了三个组：TeamA、TeamB 和 Admin。每个组包含属于该团队的用户（例如，TeamA 组中的 [email protected]）。
  • SCIM 配置 – 在 Entra ID 和 AWS IAM Identity Center 之间启用 SCIM（跨域身份管理系统）同步。SCIM 提供用户和组的自动供应和去供应。当新用户被添加到 Entra ID 中的 TeamA 组时，他们将自动与 Identity Center 同步，并获得适当的访问权限，无需人工干预。
  • 基于 SAML 的认证 – 配置 SAML 2.0 联邦身份，使用户在认证时通过 Entra ID 进行验证。Identity Center 作为服务提供方，信任来自您的 Entra ID 租户的断言。

通过此配置，您可以在现有企业目录中管理团队成员（这决定了所有下游授权决策），并自动传播到 AWS。

下图展示了如何在 Microsoft Entra ID 中表示组织团队，为 TeamA、TeamB 和 Admin 分别创建了专用组。

图2：在 Microsoft Entra ID 中，组织团队以组的形式表示

接下来的图像展示了 AWS IAM Identity Center 中对应的组，这些组通过 SCIM 同步从 Entra ID 自动配置。

图3：AWS IAM Identity Center 中对应的组，通过 SCIM 配置

了解更多：连接外部身份提供商 · SCIM 配置文件和 SAML 2.0 实现

授权

认证建立后，下一步是授权：控制每个团队在 AWS 服务和 Kubernetes 集群中可以执行的操作。此架构中的授权在两个层级上运行：IAM 用于服务级访问，Kubernetes RBAC 用于集群级访问。

每个团队的 IAM 角色

每个团队都需要一个专用的 IAM 角色，该角色封装其 AI 和机器学习（ML）工作流程所需的 AWS 权限。这些角色作为 SageMaker AI 领域的执行角色，定义团队可以访问的 AWS 服务。

典型的团队 IAM 角色应包含以下策略：

  • Amazon SageMaker AI – 通过 SageMaker AI API 管理 HyperPod 集群、MLflow 跟踪服务器和其他 SageMaker AI 资源。
  • Amazon S3 – 读取训练数据集并写入模型工件、检查点和日志。将这些权限范围限定在团队特定的存储桶前缀。
  • Amazon CloudWatch – 查看与团队工作负载相关的日志和指标。
  • Amazon EKS – 特别是 eks:AccessKubernetesApi 和 eks:MutateViaKubernetesApi 权限，SageMaker Studio GUI 需要这些权限代表用户进行 Kubernetes API 调用（例如，列出 Spaces 或提交作业）。

每个 IAM 角色的信任策略必须将 sagemaker.amazonaws.com 作为受信任的主体，以便 SageMaker AI 可以代表用户通过 Studio 操作时承担该角色。如果计划将相同的执行角色作为 EKS Pod 身份关联用于集群内工作负载（如后面 Amazon S3 存储部分所述），信任策略还必须将 pods.eks.amazonaws.com 作为受信任的主体。通过 Identity Center 的 CLI 访问使用单独的权限集及其自身的策略（参见“通过 Identity Center 访问 AWS 账户”部分），因此 CLI 权限可以独立范围限定。

了解更多：如何使用 SageMaker AI 执行角色

通过 Identity Center 访问 AWS 账户

除了 SageMaker Studio，团队通常需要直接访问 AWS 账户以执行 CLI 操作，例如运行 kubectl 命令、脚本化工作流程或以编程方式访问资源。Identity Center 权限集提供了这种能力。

对于管理员组，根据公司政策分配具有管理权限的权限集，授予集群管理和管理操作所需的账户访问权限。

对于团队 A 和团队 B，创建包含内联或托管策略的权限集，直接授予 CLI 工作流程所需的权限。典型的团队权限集包括 eks:AccessKubernetesApi 权限（用于从 AWS 控制台查看 Kubernetes 资源）、团队数据的限定 S3 访问权限，以及用于监控的 CloudWatch 读取权限。这些策略独立于 Studio 执行角色定义，因此管理员可以将 CLI 权限定制为团队从命令行执行的具体操作。

用户通过 AWS 命令行界面（AWS CLI）使用 aws sso login 获取临时凭证，然后使用这些凭证配置 kubectl 以直接与 EKS 集群交互。

下图展示了 AWS IAM Identity Center 中的每个团队权限集，为 CLI 工作流程（如运行 kubectl 和 aws sso login 以访问 EKS 集群）提供限定的 AWS 账户访问权限。

图 4：AWS IAM Identity Center 中用于 CLI 工作流程的每个团队权限集

了解更多信息：通过权限集管理 AWS 账户

配置 AWS CLI

团队成员通过运行 aws configure sso 命令，使用 Identity Center 进行身份验证以配置 AWS CLI。这会在 ~/.aws/config 中创建配置文件，引用 Identity Center 的相应会话和权限集。当团队成员从命令行与集群进行交互时，会使用其特定于团队的配置文件，无论访问来自 Studio 还是本地终端，都能保持授权边界。

生成的配置为 Identity Center 门户定义了一个共享的 sso-session 块，并为每个团队定义了一个命名配置文件，每个配置文件都指向该团队的权限集。团队成员随后运行 aws sso login --profile <team> 以获取临时凭证，这些凭证的权限范围限定在他们的权限集内：

code
[sso-session my-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-west-2
sso_registration_scopes = sso:account:access

[default]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = OpsAdmin
region = us-west-2

[profile team-a]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamA-permission-set
region = us-west-2

[profile team-b]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamB-permission-set
region = us-west-2

了解更多信息：使用 AWS CLI 配置 IAM Identity Center 身份验证

SageMaker AI 域

SageMaker AI 域为每个团队提供工作区边界，提供定制的用户体验、预配置的执行角色，并与 Identity Center 身份验证进行内置集成。

为什么使用 SageMaker AI 域

为每个团队使用一个 SageMaker AI 域是组织多团队环境的成熟模式。这种方法具有以下优势：

  • 成熟的多团队模式 – AWS 已经详细记录了这种通过分离业务线或多个域中的团队来实现的模式，使其成为已被验证并支持的配置。
  • 原生 Identity Center 身份验证 – 每个域都可以配置 Identity Center 身份验证，这意味着用户通过企业身份提供商一次登录后，将直接进入其团队的 Studio 环境。
  • 内置团队配置 – 域已经提供了指定用户和团队配置的机制，无需额外自定义实体。例如，团队执行角色等设置可以在域级别指定，并在用户配置文件级别覆盖，以实现最大灵活性。
  • 导航自定义 – 通过域设置，管理员可以隐藏与团队工作流程无关的导航项，为 HyperPod 用例提供聚焦的界面。

了解更多信息：SageMaker AI 域实体和状态 · 多个域概述

为每个团队设置域

为每个团队创建一个带有 Identity Center 身份验证的 SageMaker AI 域。在我们的示例中，我们创建 TeamA-domain 和 TeamB-domain。每个域的配置如下：

  • 默认执行角色 – 将域的默认执行角色设置为授权步骤中创建的特定于团队的 IAM 角色。通过 Studio 执行的所有操作都将继承相应的权限。
  • Identity Center 组分配 – 将对应的 Identity Center 组（例如 TeamA 组）添加到域中。这会为该组的所有成员激活 SageMaker Studio 应用程序，使他们能够访问 Studio 界面。
  • 应用分配验证 – 配置组访问权限后，请在Identity Center中检查应用分配情况，确认正确的组已映射到相应的域。
  • 导航自定义 – 为每个域配置默认导航设置，仅显示相关功能。例如，您可以隐藏与HyperPod工作流无关的项目，为仅需使用HyperPod资源的团队成员提供专注HyperPod的简洁用户体验，降低认知负担。

下图展示了SageMaker AI控制台，其中每个团队（TeamA-domain和TeamB-domain）分配了一个独立域，各自提供隔离的工作空间边界。

图5：SageMaker控制台中每个团队对应一个SageMaker域

下图展示了TeamA-domain的详细信息，包括分配的Identity Center组。

图6：TeamA-domain配置及其分配的Identity Center组

HyperPod EKS集群配置

HyperPod EKS集群是工作负载执行的场所。通过Kubernetes命名空间实现集群级别的多租户隔离，通过EKS访问条目实现授权。

命名空间隔离

为每个团队创建专用的Kubernetes命名空间，例如hyperpod-ns-team-a和hyperpod-ns-team-b。命名空间在集群内提供逻辑边界，将每个团队的工作负载（空间、训练作业、推理端点）相互隔离。

注意：命名空间是隔离边界而非硬性安全边界。该架构针对同一组织内的多团队场景：团队共享集群并处于共同的管理域和基础互信水平。此方案未设计用于相互不信任租户之间的多客户隔离。命名空间、RBAC和配额可防止意外干扰（如团队覆盖彼此资源或超出计算配额），但无法防御有预谋的恶意租户：命名空间内的Pod共享相同节点和内核，集群范围资源（节点、PersistentVolumes、CRDs、部分操作组件）位于任何命名空间之外。对于不信任租户或严格监管隔离场景，应使用更严格的边界，如独立集群或账户、专用节点池和运行时沙箱化。针对此处的多团队场景，结合命名空间隔离、RBAC、Task Governance配额及后续描述的POSIX身份控制，可实现分离性与操作简洁性的平衡。

命名空间可通过kubectl create namespace手动创建，或通过HyperPod Task Governance自动分配。HyperPod Task Governance将命名空间作为配额和调度配置的一部分进行管理。

下图展示了集群命名空间（通过HyperPod Task Governance管理），每个团队（hyperpod-ns-team-a和hyperpod-ns-team-b）拥有一个专用命名空间，实现工作负载隔离。

图7：每个团队的专用Kubernetes命名空间用于工作负载隔离

了解更多：Kubernetes命名空间

网络隔离

命名空间不会限制网络流量。默认情况下，Kubernetes网络是扁平化的：所有命名空间中的Pod均可互相访问。因此，hyperpod-ns-team-a中的Pod默认可连接到hyperpod-ns-team-b中的Pod，除非添加控制措施。为沿团队边界限制Pod间可达性，请使用Kubernetes NetworkPolicy资源。

推荐的模式是每个命名空间默认拒绝：首先拒绝所有入站（以及可选的出站）流量，然后显式允许每个团队所需的流量，通常是命名空间内通信以及必需的出站流量，如DNS、存储端点和AWS API。以下示例拒绝团队命名空间中的所有入站流量，然后仅允许同一命名空间内Pod的流量：

code
# 1. 在团队的命名空间中默认拒绝所有入站流量。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}  # 适用于命名空间中的所有Pod
  policyTypes:
  - Ingress
---
# 2. 仅允许来自同一命名空间内Pod的入站流量。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # 本命名空间中的任意Pod

NetworkPolicy的执行依赖于支持它的容器网络接口（CNI）。在EKS中，您可以在Amazon虚拟私有云（Amazon VPC）CNI中启用网络策略支持。

与命名空间类似，NetworkPolicy可以减少团队间的意外可达性并缩小作用范围，但它们本身并不能在共享节点上形成对抗性安全边界。如前所述，如需更强的隔离，可考虑为每个团队分配专用节点池或使用独立集群。

了解更多：Kubernetes网络策略 · Amazon VPC CNI网络策略

EKS访问条目

EKS访问条目将IAM主体与Kubernetes RBAC权限关联。为每个团队创建两个访问条目：

  • Studio访问条目 – IAM主体是团队的SageMaker AI域执行角色。此条目用于从SageMaker Studio GUI发起操作时。
  • CLI访问条目 – IAM主体是Identity Center为团队权限集创建的SSO预配角色（遵循AWSReservedSSO_<权限集名称>_<唯一ID>的命名模式）。此条目用于用户通过kubectl与集群交互时。

这两个条目均通过托管或自定义Kubernetes策略限定在团队的命名空间内。例如，Team A的两个条目仅授予hyperpod-ns-team-a命名空间内的权限。如果需要，两个条目可以携带不同的RBAC策略。例如，CLI条目可能限制对某些资源类型的写入权限，而Studio条目允许完全访问。

通过这种限定，无论访问来自Studio还是CLI，用户只能与其所在命名空间中的资源交互。尝试列出或修改其他团队命名空间中的资源会导致Kubernetes拒绝错误。

对于更高级的场景，可以使用访问条目中的Kubernetes组，将用户映射到提供细粒度权限的自定义ClusterRoles或Roles，这些权限超出标准托管策略的范围。

下图展示了Team B角色的EKS访问条目，限定在hyperpod-ns-team-b命名空间内，因此其权限仅适用于Team B的命名空间。

图8：限定在Team B命名空间的EKS访问条目

了解更多：通过EKS访问条目授予IAM用户对Kubernetes的访问权限

HyperPod任务治理

当在集群上启用任务治理时，它会提供额外的资源管理层次：

  • 计算配额 – 为每个团队定义可使用的GPU和CPU资源上限。这可防止单个团队在训练过程中独占共享硬件资源。
  • 优先级 – 为每个团队或工作负载类型分配调度优先级，当资源受限时允许关键的生产推理工作负载抢占实验性训练任务。
  • 公平调度 – 通过任务治理功能，当多个团队竞争资源时，资源分配将遵循配置的策略，而非先到先得的模式。

通过为每个团队的命名空间配置适当的配额和优先级，在保证最低资源保障与突发工作负载的弹性容量之间实现平衡。

下图展示了两个团队的任务治理计算分配情况，每个团队的命名空间都分配了集群计算容量的独立配额。

图9：按团队命名空间划分的任务治理计算分配

了解更多：SageMaker HyperPod 任务治理

存储

存储是跨团队共享的人工智能和机器学习（AI/ML）环境中的关键组件。团队需要高性能文件系统来存储训练数据、检查点和模型构件，同时需在团队间维持适当的访问边界。

符合POSIX标准的文件系统

对于需要共享的高性能POSIX文件系统的工作负载（常见于分布式训练场景，多个节点需要读取相同数据集或写入检查点），请考虑以下选项：

  • Amazon FSx for Lustre – 提供高吞吐量、低延迟的并行文件系统访问，非常适合需要高速读取大规模数据集的训练工作负载。
  • Amazon FSx for OpenZFS – 提供具有强大POSIX语义的通用文件系统，支持快照和压缩。非常适合需要传统文件系统功能与高性能兼具的工作负载。
  • Amazon Elastic File System (Amazon EFS) – 提供全托管的弹性网络文件系统（NFS）存储。EFS还支持访问点，可通过将不同的挂载点映射到不同目录并强制实施UID和GID，简化按团队划分的目录隔离。

存储布局通常遵循以下结构：

  • 按团队共享目录 – 每个团队拥有共享目录（例如 /fsx/TeamA、/fsx/TeamB），用于存储所有团队成员需要访问的数据集、模型和构件。
  • 按用户个人目录 – 每个用户拥有个人主目录（例如 /home/User1、/home/User2），用于个人工作、实验和笔记本。

这些文件系统上的POSIX权限模型依赖UID、GID和补充组来实施访问边界。当用户启动HyperPod空间或提交训练任务时，这些POSIX身份信息应传播到Pod的安全上下文中，以确保文件系统访问遵循配置的所有权和权限设置。我们建议使用Kubernetes的mutating admission webhook从身份存储中检索POSIX身份信息。当工作负载提交时，webhook会在运行时查找身份信息，并相应地修改Pod的安全上下文。

code
# 1. 从准入请求中提取调用者的会话标识
# 在 EKS 中，来自 IAM 假冒角色（包括 IAM Identity Center）
# 的请求会在 userInfo.extra["sessionName"] 中显示 STS 会话名称。其格式
# 取决于会话的创建方式（例如 SSO 短名称、电子邮件
# 或 role-session-name）；请将身份映射与该值对齐。
def extract_username(admission_request):
    extra = admission_request["userInfo"]["extra"]
    ...
    return extra["sessionName"][0]

# 2. 从映射表（例如 DynamoDB）中查找 POSIX 身份
def lookup_posix_identity(username):
    item = posix_table.get_item(Key={"username": username})["Item"]
    ...
    return {
        "uid": int(item["uid"]),
        "gid": int(item["gid"]),
        "supplementalGroups": [int(g) for g in item["supplementalGroups"]],
    }

# 3. 使用解析后的 POSIX 身份修补 Pod 安全上下文
def build_security_context_patch(pod, posix):
    ...
    return [{
        "op": "add",
        "path": "/spec/securityContext",
        "value": {
            "runAsUser": posix["uid"],
            "runAsGroup": posix["gid"],
            "fsGroup": posix["gid"],
            "supplementalGroups": posix["supplementalGroups"],
        },
    }]

了解更多：FSx for Lustre · FSx for OpenZFS · Amazon EFS

Amazon S3 存储

对于对象存储，S3 存储桶的访问由团队的 IAM 执行角色控制。您可以为每个团队创建专用存储桶，或使用共享存储桶并配合团队专属前缀，通过 IAM 策略实现隔离。集群中的 Pod 需要配置适当的服务账户，使用 IAM 服务账户角色（IRSA）或 Pod 身份认证以访问 S3。为简化操作，可以将 SageMaker AI 域配置的执行角色关联到团队命名空间内的 Kubernetes 服务账户，从而实现 Studio 和集群工作负载的一致 S3 访问权限。

了解更多：服务账户的 IAM 角色（IRSA） · EKS Pod 身份

HyperPod 空间

HyperPod 空间提供直接在集群节点上运行的交互式开发环境（IDE）。在共享集群中，空间必须正确限定到每个团队的命名空间，并配置适当的资源模板。

空间模板

为每个团队创建命名空间限定的 Space 模板。这些模板定义了团队成员创建空间时可用的资源配置（实例类型、存储卷、环境变量）。通过将模板限定到命名空间，可以确保每个团队只能在其指定范围内启动空间。

当启用 HyperPod 任务治理时，模板应包含治理系统要求的默认标签（如团队标识符和优先级标签）。集群管理员预先配置这些标签，使团队成员在启动空间时无需手动指定。

以下示例展示了限定到团队 A 的 JupyterLab 空间模板。团队特定的部分包括 metadata.namespace、baseLabels 下的任务治理队列标签，以及挂载团队共享文件系统和用户主目录的默认卷：

code
apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jl-smd-custom
  namespace: hyperpod-ns-team-a  # 将模板作用域限定在 Team A 的命名空间内
spec:
  displayName: "JupyterLab (team-a)"
  description: "SageMaker Distribution"
  appType: jupyterlab
  baseLabels:
  - key: kueue.x-k8s.io/queue-name  # 任务治理（Kueue）Team A 的本地队列
    value: hyperpod-ns-team-a-localqueue
  ...
  # 容器命令、默认 CPU/内存资源、安全上下文、访问类型等
  ...
  defaultVolumes:
  - name: home-dir  # 每个用户的主目录
    mountPath: /home
    persistentVolumeClaimName: fsx-openzfs-claim
  - name: shared-data  # Team A 的共享目录
    mountPath: /fsx
    persistentVolumeClaimName: fsx-lustre-claim
  ...
  # 主（EBS）存储默认值和限制
  ...

持久卷声明

在每个团队的命名空间中创建适当的持久卷声明（Persistent Volume Claims，PVC），并引用共享文件系统。这些 PVC 将团队的共享目录和用户的主目录挂载到 Space 中，从而提供对训练数据、检查点和个人工作区的访问。

仅限所有者和共享 Space

请根据组织在 Space 共享方面的需求进行考虑：

  • 仅限所有者 Space – 每个 Space 仅可由创建它的用户访问。这是默认配置，适用于团队处理敏感或独立项目的情况。
  • 共享 Space – 多个团队成员可以访问同一个 Space，适用于结对编程、协作调试或共享开发环境。启用共享 Space 时，请确保 POSIX 权限和补充组已正确配置，以允许对 Space 内创建的文件进行适当访问。

了解更多：[在 Amazon SageMaker HyperPod EKS 集群上使用交互式开发环境](链接)

Studio 体验

虽然团队可以通过 CLI 使用 kubectl 完全与集群交互，但 SageMaker Studio 为偏好托管、GUI 驱动工作流的用户提供了集群的图形化入口点。在此架构中，每个团队通过自己的 SageMaker AI 域（如前所述）访问 Studio，并使用相同的 Identity Center 凭据登录，在团队命名空间的边界内操作。

下图展示了用户使用企业凭据登录后访问的 IAM Identity Center 访问门户，提供对分配的 SageMaker Studio 应用和 Amazon Managed Grafana 应用的单点登录访问。

图 10：带有单点登录功能的 IAM Identity Center 访问门户

从 Studio 界面，团队成员可以：

  • 管理 HyperPod Space – 无需编写 Kubernetes 清单或手动指定任务治理标签，即可从管理员配置的命名空间作用域 Space 模板中启动交互式开发环境。团队成员还可以启动、停止并连接到正在运行的 Space，直接在浏览器中打开关联的 IDE（如 JupyterLab）。
  • 管理 Ray 工作负载 – 创建和监控 Ray 集群，将 JupyterLab 或代码编辑器工作区连接到集群，提交分布式作业，并打开 Ray 仪表板和 Amazon Managed Grafana 可观测性仪表板，所有操作均无需编写 Kubernetes 清单或运行 kubectl 命令。

因为 Studio 通过团队的 Domain 执行角色和对应的 EKS 访问条目进行操作，所有操作都限定在团队的命名空间内。用户通过 Studio 启动 Space 或 Ray 集群时，只能在所属团队的边界内创建，这与 CLI 访问强制实施的隔离模型保持一致。

下图展示了如何通过 SageMaker Studio UI 创建 HyperPod Space，其中团队成员选择命名空间限定的 Space 模板，无需手动编写 Kubernetes 清单或指定任务治理标签。

图 11：在 SageMaker Studio 中通过命名空间限定模板创建 HyperPod Space

了解更多：Amazon SageMaker HyperPod EKS 集群上的交互式开发环境 · SageMaker HyperPod 上新 Ray 功能介绍

HyperPod 训练操作符

HyperPod 训练操作符使团队能够将分布式训练任务作为 Kubernetes 自定义资源提交（例如 HyperPodPyTorchJob）。在多租户架构中，训练任务是命名空间限定的，这意味着它们会自动继承团队的隔离边界。

团队可以通过 CLI 使用 kubectl apply 和适当的作业清单提交训练任务。任务在团队的命名空间中运行，使用团队的计算配额（如果启用了任务治理），并可以访问团队的存储卷。

当启用任务治理时，训练任务会受到团队分配的配额和优先级设置的约束。如果团队已消耗了其保证的配额，任务可能会排队，直到资源可用或低优先级工作负载被抢占。

将任务绑定到团队的两个要素是 metadata.namespace（将任务限定在团队的隔离边界内）和任务治理标签。任务治理基于 Kueue 构建，因此任务通过 kueue.x-k8s.io/queue-name 路由到团队的本地队列。它通过 kueue.x-k8s.io/priority-class 被分配调度优先级，其值是集群中定义的 WorkloadPriorityClass 的名称：

code
apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: team-a-training-job
  namespace: hyperpod-ns-team-a  # 将任务限定在 Team A 的命名空间内
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # 任务治理（Kueue）本地队列
    kueue.x-k8s.io/priority-class: training-priority  # WorkloadPriorityClass 的名称
spec:
  ...
  # replicaSpecs、容器镜像、命令、资源、卷等
  ...

了解更多：使用 HyperPod 训练操作符

HyperPod 推理操作符

HyperPod 推理操作符允许团队直接在集群上将模型部署为推理端点。与训练任务类似，推理端点是命名空间限定的，并受团队的 RBAC 策略和任务治理配额约束。

团队可以通过在自己的命名空间中创建推理端点自定义资源，从 CLI 部署模型。端点按命名空间隔离，这意味着 Team A 无法访问或干扰 Team B 的推理端点。

对于需要高可用性的生产推理工作负载，建议为推理端点分配比训练任务更高的调度优先级，以防止模型服务因批量训练工作负载而中断。

与训练任务类似，推理端点位于团队的metadata.namespace中，并携带任务治理标签。此处，kueue.x-k8s.io/priority-class引用了更高优先级的WorkloadPriorityClass，以便在团队资源受限时，模型服务可以抢占批处理训练：

code
apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: team-a-inference-endpoint
  namespace: hyperpod-ns-team-a  # 将端点作用域限定在团队A的命名空间内
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # 任务治理（Kueue）本地队列
    kueue.x-k8s.io/priority-class: inference-priority  # 更高优先级的WorkloadPriorityClass
spec:
  ...
  # 模型来源、实例类型、副本数量、自动扩展等
  ...

了解更多：在Amazon SageMaker HyperPod上部署模型

HyperPod 可观测性

所有团队都需要对集群健康状况、工作负载性能和资源利用率的可见性。HyperPod 可观测性通过 Amazon Managed Grafana 提供内置的监控和仪表板功能。

配置团队对Grafana的访问权限

团队需要访问可观测性仪表板以监控其工作负载、排查性能问题并了解资源消耗情况。然而，在多租户环境中，此访问权限通常应为只读权限：

  • 为 Amazon Managed Grafana 配置 Identity Center 认证 – 在 Amazon Managed Grafana 控制台中，导航到认证并启用 AWS IAM Identity Center。用户随后可以使用与 SageMaker Studio 相同的企业凭据登录 Grafana。
  • 将团队组分配为查看者 – 将 Identity Center 组（TeamA、TeamB）映射到 Grafana 查看者角色。这使团队成员能够以只读方式访问仪表板和指标，但无法修改仪表板或数据源。
  • 管理员访问权限 – 将管理员组分配给 Grafana 管理员或编辑角色，使他们能够创建和修改仪表板、配置告警并管理数据源。
  • 团队专用仪表板 – 考虑创建专用仪表板，通过命名空间过滤数据，使每个团队仅能看到自己的工作负载指标。Amazon Managed Grafana 支持 Grafana 团队（一种原生 Grafana RBAC 概念，与本架构中的组织团队不同），可以将 Identity Center 组映射到 Grafana 团队，以限制仪表板可见性并提供额外的数据隔离层。

下图展示了 Amazon Managed Grafana 中的 Grafana 角色分配。团队组（TeamA、TeamB）被分配为查看者角色，以获得对仪表板和指标的只读访问权限，而管理员组被分配为管理员角色，使其能够创建和修改仪表板、配置告警并管理数据源。

图12：授予团队只读查看者访问权限的Grafana角色分配

了解更多：Amazon EKS 管理的 Amazon SageMaker HyperPod 集群可观测性

成本分配与回收费用

在团队共享昂贵GPU基础设施的多租户环境中，了解谁消耗了什么对于问责、预算和回收费用至关重要。Kubecost通过将集群内支出按原生Kubernetes概念（命名空间、标签、部署和服务）分解，并将其映射到组织概念（如团队、项目或环境）来满足这一需求。

由于这种架构已经将每个团队隔离在专用的命名空间中（hyperpod-ns-team-a、hyperpod-ns-team-b），命名空间级别的成本分配可以直接与团队边界对齐。这使平台管理员能够清晰地查看每个团队的GPU、CPU、内存、存储和网络使用情况，而无需任何额外的工作负载标签。有关在HyperPod集群上部署和配置Kubecost的逐步说明，请参阅Kubecost on SageMaker HyperPod。

实现团队可见性

当Kubecost开始收集数据后，在"Allocations"仪表板中按命名空间对成本进行分组，即可查看每个团队的支出情况。由于每个团队拥有自己的命名空间，这会直接生成涵盖计算、内存、存储和网络的每个团队成本细分。与可观测性仪表板一样，团队可以从自己的成本数据中获益：

  • 为每个团队的命名空间提供视图范围 – Kubecost支持按命名空间进行过滤和保存报告，因此每个团队可以查看自己的使用情况和趋势，而不会看到其他团队的数据。
  • 设置预算和警报 – 配置每个命名空间的预算阈值和警报，当支出接近定义的限制时，团队和平台管理员将收到通知，这与HyperPod任务治理的资源公平性目标一致。
  • 支持成本回收费用核算 – 命名空间级别的分配报告可以用于内部成本回收费用（根据使用情况向团队收费）或费用核算（报告使用情况但不收费）流程，为财务和平台团队提供所需的数据，以公平地分配共享GPU成本。

下图显示了按命名空间分组的Kubecost分配仪表板，展示了每个团队命名空间在过去7天内的累计成本。

图13：按命名空间分组的Kubecost分配仪表板（用于每团队成本）

了解更多：Kubecost on SageMaker HyperPod · Kubecost

结论

本文介绍了在Amazon SageMaker HyperPod上使用EKS构建多租户环境的参考架构。通过结合AWS IAM Identity Center进行身份验证、每个团队的IAM角色进行AWS级别的授权、SageMaker AI域提供定制的工作区体验、Kubernetes命名空间进行工作负载隔离、HyperPod任务治理实现公平的资源分配，以及命名空间级别的成本分配实现每个团队的支出可见性，多个团队可以高效共享一个HyperPod EKS集群。

这是一种灵活且可组合的方法，将多个构建模块组合成一个连贯的解决方案。该架构适用于各种用例和组织结构。例如，组织可以扩展这种模式，将团队连接到HyperPod Slurm集群和EKS，从而在不同的编排后端上提供统一的多租户体验。

虽然这种方法需要组装和配置多个组件，但结果是高度的控制和定制化，可以根据每个组织的具体隔离、合规和运营需求进行调整。基础模式（身份联合、命名空间隔离、RBAC、基于配额的治理和成本分配）将保持适用性。

要开始使用，请尝试在您自己的Amazon SageMaker HyperPod EKS集群上构建这种多租户设置，并根据组织的隔离、治理和成本分配需求调整构建模块。

作者简介

'"` /think