Amazon SageMaker HyperPod 如何构建多团队共享 GPU 集群的隔离与公平架构

同一家公司内的多个团队日益需要共享访问昂贵的 GPU 集群来运行其生成式 AI 业务，同时还要保持隔离边界、资源公平性和运营独立性。设想一个数据科学团队在训练大语言模型，一个计算机视觉团队在运行推理工作负载，还有一个研究团队在试验新的模型架构。他们可能都需要访问同一个集群。如果没有设计良好的多租户（多团队）架构，组织将面临资源消耗失控、团队之间隔离薄弱、无法将共享 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 Task Governance 实现公平的资源分配，并通过命名空间级别的成本分配实现按团队的开支可见性和费用分摊。读完本文后，您将获得一个清晰的蓝图，让多个团队高效地共享同一个 HyperPod EKS 集群。

架构概览

下图展示了多租户 HyperPod EKS 部署的高层架构。在本示例中，两个团队（Team A 和 Team B）共享同一个 HyperPod EKS 集群，各自在自己隔离的命名空间中运行。

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

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

用户与身份验证

在最左侧，每个团队的个人用户（Team A 的用户 1 和 Team 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 role”）。当用户通过 aws sso login 进行身份验证时，该角色充当 IAM 主体。

SageMaker AI 域

从 Identity Center 门户，用户会被路由到其团队专属的 SageMaker AI 域。每个域（SageMaker AI domain Team A 和 SageMaker AI domain 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 Observability（用于监控和仪表板）和 HyperPod Task Governance（用于计算配额管理和调度优先级）。在这些层之下，集群被划分为 Namespace A（Team A）和 Namespace B（Team B）。在每个命名空间内，团队可以运行自己的 HyperPod Spaces（交互式开发环境）、HyperPod PyTorch 作业（分布式训练工作负载）和 HyperPod Inference 端点（模型服务）。

存储

在集群下方，该架构包含两个存储层。第一层是符合 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 Single Sign-On 的继任者）提供了一个统一的位置来管理跨 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 提供商。

配置涉及：

1. 身份提供商中的组结构 – 在 Entra ID 中，创建与组织团队相对应的组。在我们的示例中，我们定义了三个组：TeamA、TeamB 和 Admin。每个组包含属于该团队的用户（例如，TeamA 组中的 [email protected]）。
2. SCIM 预置 – 在 Entra ID 与 AWS IAM Identity Center 之间启用 SCIM（跨域身份管理系统）同步。SCIM 提供用户和组的自动预置与取消预置。当新用户被添加到 Entra ID 中的 TeamA 组时，会自动同步到 Identity Center 并获得相应的访问权限，无需人工干预。
3. 基于 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 作为可信主体，这样当用户通过 Studio 操作时，SageMaker AI 才能代表用户代入该角色。如果你计划将同一个执行角色复用为 EKS Pod Identity 关联以用于集群内工作负载（将在后文 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 权限集提供了这种能力。

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

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

用户通过 AWS Command Line Interface（AWS CLI）使用 aws sso login 获取临时凭证，然后用它来配置 kubectl，以直接与 EKS 集群交互。

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

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

了解更多：使用权限集管理 AWS 账户

配置 AWS CLI

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

最终的配置为 Identity Center 门户定义了一个共享的 sso-session 块，并为每个团队创建一个命名配置文件，各自指向该团队的权限集。然后团队成员运行 aws sso login --profile <team> 以获取限定在其权限集范围内的临时凭证：

[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 域（domain）

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。每个域按如下方式配置：

1. 默认执行角色——将域的默认执行角色设置为在授权步骤中创建的团队专属 IAM 角色。通过 Studio 执行的所有操作因此都会继承相应的权限。
2. Identity Center 组分配——将相应的 Identity Center 组（例如 TeamA 组）添加到域中。这会为该组的所有成员激活 SageMaker Studio 应用程序，授予他们访问 Studio 界面的权限。
3. 应用程序分配验证——配置组访问权限后，在 Identity Center 中检查应用程序分配，确认正确的组已映射到正确的域。
4. 导航自定义——为每个域配置默认导航设置，仅呈现相关功能。例如，你可以隐藏与 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。命名空间在集群内提供逻辑边界，将各团队的工作负载（Spaces、训练作业、推理端点）相互隔离。

注意：命名空间是一种隔离边界，而非硬性安全边界。此架构面向单一组织内的多团队：即在共同管理域和基本互信之下共享一个集群的团队。它并非为互不信任的租户之间的多客户隔离而设计。

命名空间、RBAC 和配额可以防止意外的干扰（如团队相互覆盖资源或超出其计算配额），但无法防御蓄意的恶意租户：命名空间内的 Pod 共享相同的节点和内核，而集群范围的资源（节点、PersistentVolumes、CRD、部分 operator 组件）位于任何命名空间之外。

对于不可信的租户或严格的合规隔离要求，应使用更强的边界，例如独立集群或账户、专用节点池以及运行时沙箱。对于本文的多团队场景，命名空间隔离结合 RBAC、Task Governance 配额以及后文所述的 POSIX 身份控制，可以在隔离性与运维简便性之间取得恰当的平衡。

命名空间可以通过 kubectl create namespace 手动创建，也可以通过 HyperPod Task Governance 自动预置，后者在配额和调度配置中管理命名空间。

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

图 7：每个团队一个专用 Kubernetes 命名空间，实现工作负载隔离

了解更多：Kubernetes 命名空间

网络隔离

命名空间不会限制网络流量。默认情况下，Kubernetes 网络是扁平的：每个 Pod 都可以访问所有命名空间中的其他 Pod。因此，除非添加控制措施，hyperpod-ns-team-a 中的 Pod 可以打开与 hyperpod-ns-team-b 中 Pod 的连接。要沿团队边界限定 Pod 间的可达范围，请使用 Kubernetes NetworkPolicy 资源。

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

# 1. Default-deny all ingress in the team's namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}  # applies to all pods in the namespace
  policyTypes:
  - Ingress
---
# 2. Allow ingress only from pods within the same namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # any pod in this namespace

NetworkPolicy 的实施依赖于支持它的容器网络接口（CNI）。在 EKS 上，您可以在 Amazon Virtual Private Cloud（Amazon VPC）CNI 中启用网络策略支持。

与命名空间类似，NetworkPolicies 可以减少意外的跨团队可达性并缩小影响范围，但它们本身并不是共享节点上对抗性安全边界。要实现更强的隔离，请考虑为每个团队使用专用节点池或单独的集群，如前所述。

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

EKS 访问条目

EKS 访问条目将 IAM 主体连接到 Kubernetes RBAC 权限。为每个团队创建两个访问条目：

• Studio 访问条目 – IAM 主体是该团队的 SageMaker AI 域执行角色。当操作源自 SageMaker Studio GUI 时使用此条目。
• CLI 访问条目 – IAM 主体是 Identity Center 为该团队的权限集创建的 SSO 预置角色（遵循 AWSReservedSSO_<permission-set-name>_<unique-id> 的模式）。当用户通过 kubectl 与集群交互时使用此条目。

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

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

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

下图显示了团队 B 角色的 EKS 访问条目，其作用域限定为 hyperpod-ns-team-b 命名空间，因此其权限仅适用于团队 B 的命名空间内。

图 8：作用域限定为团队 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 还支持访问点（access points），可通过将不同的挂载点映射到具有强制 UID 和 GID 的不同目录，简化各团队之间的目录隔离。

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

• 每团队共享目录 – 每个团队有一个共享目录（例如，/fsx/TeamA、/fsx/TeamB），用于存放所有团队成员都需要访问的数据集、模型和产物。
• 每用户主目录 – 每个用户有一个个人主目录（例如，/home/User1、/home/User2），用于个人工作、实验和 notebook。

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

# 1. Extract the caller's session identity from the admission request.
# On EKS, requests from IAM-assumed roles (including IAM Identity Center)
# surface the STS session name in userInfo.extra["sessionName"]. Its format
# depends on how the session is created (e.g., an SSO short name, an email,
# or a role-session-name); align your identity mapping with this value.
def extract_username(admission_request):
    extra = admission_request["userInfo"]["extra"]
    ...
    return extra["sessionName"][0]

# 2. Look up the POSIX identity from a mapping table (e.g. DynamoDB).
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. Patch the Pod security context with the resolved POSIX identity.
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 Roles for Service Accounts（IRSA）或 Pod Identity 来向 S3 进行身份验证。为简单起见，您可以将 SageMaker AI 域上配置的相同执行角色关联到团队命名空间内的 Kubernetes 服务账户，从而在 Studio 和集群工作负载中提供一致的 S3 访问。

了解更多：IAM roles for service accounts (IRSA) · EKS Pod Identity

HyperPod Spaces

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

Space 模板

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

启用 HyperPod Task Governance 后，模板应包含治理系统所需的默认标签（例如团队标识符和优先级标签）。集群管理员会预先配置这些标签，这样团队成员在启动 Spaces 时无需手动指定它们。

以下示例展示了一个限定于 Team A 的 JupyterLab Space 模板。团队特定的部分包括 metadata.namespace、baseLabels 下的 Task Governance 队列标签，以及挂载团队共享文件系统和用户主目录的 defaultVolumes：

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jl-smd-custom
  namespace: hyperpod-ns-team-a  # scopes the template to Team A's namespace
spec:
  displayName: "JupyterLab (team-a)"
  description: "SageMaker Distribution"
  appType: jupyterlab
  baseLabels:
  - key: kueue.x-k8s.io/queue-name  # Task Governance (Kueue) local queue for Team A
    value: hyperpod-ns-team-a-localqueue
  ...
  # container command, default CPU/memory resources, security context, access type, etc.
  ...
  defaultVolumes:
  - name: home-dir  # per-user home directory
    mountPath: /home
    persistentVolumeClaimName: fsx-openzfs-claim
  - name: shared-data  # Team A's shared directory
    mountPath: /fsx
    persistentVolumeClaimName: fsx-lustre-claim
  ...
  # primary (EBS) storage defaults and limits
  ...

持久卷声明（PVC）

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

仅所有者可见的 Spaces 和共享 Spaces

请考虑贵组织对 Space 共享方面的要求：

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

了解更多：Amazon SageMaker HyperPod EKS 集群上的交互式开发环境

Studio 体验

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

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

图 10：提供对被分配应用程序单点登录的 IAM Identity Center 访问门户

在 Studio 界面中，团队成员可以：

• 管理 HyperPod Spaces – 从管理员已配置的命名空间范围的 Space 模板启动交互式开发环境，无需编写 Kubernetes 清单或手动指定 Task Governance 标签。团队成员还可以启动、停止并连接到正在运行的 Spaces，直接在浏览器中打开关联的 IDE（例如 JupyterLab）。
• 管理 Ray 工作负载 – 创建并监控 Ray 集群，将 JupyterLab 或 Code Editor 工作区连接到集群，提交分布式作业，以及打开 Ray Dashboard 和 Amazon Managed Grafana 可观测性仪表板，这一切都无需编写 Kubernetes 清单或运行 kubectl 命令。

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

下图展示了如何在 SageMaker Studio 界面中创建 HyperPod Space，团队成员选择一个命名空间范围的 Space 模板，无需编写 Kubernetes 清单或手动指定 Task Governance 标签。

图 11：在 SageMaker Studio 中从命名空间范围的模板创建 HyperPod Space

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

HyperPod Training Operator

HyperPod Training Operator 使团队能够以 Kubernetes 自定义资源（例如 HyperPodPyTorchJob）的形式提交分布式训练任务。在多租户架构中，训练任务是命名空间范围的，也就是说它们会自动继承所在团队的隔离边界。

团队可以通过命令行界面使用 kubectl apply 以及相应的任务清单来提交训练任务。任务在团队的命名空间中运行，使用团队的计算配额（如果启用了 Task Governance），并且可以访问团队的存储卷。

启用 Task Governance 后，训练任务将受到团队已分配配额和优先级设置的约束。如果某个团队已用完其保证配额，任务可能会排队等待，直到资源可用或较低优先级的工作负载被抢占。

将任务锚定到某个团队的两个要素是 metadata.namespace（它将任务限定在团队的隔离边界内）和 Task Governance 标签。Task Governance 构建在 Kueue 之上，因此任务会通过 kueue.x-k8s.io/queue-name 被路由到团队的本地队列，并通过 kueue.x-k8s.io/priority-class 获得一个调度优先级，其值是集群上定义的某个 WorkloadPriorityClass 的名称：

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: team-a-training-job
  namespace: hyperpod-ns-team-a  # scopes the job to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: training-priority  # name of a WorkloadPriorityClass
spec:
  ...
  # replicaSpecs, container image, command, resources, volumes, etc.
  ...

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

HyperPod Inference Operator

HyperPod Inference Operator 允许团队直接在集群上把模型部署为推理端点。与训练任务类似，推理端点是命名空间范围的，并受团队的 RBAC 策略和 Task Governance 配额的约束。

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

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

与训练任务一样，推理端点会被放置在团队的 metadata.namespace 中，并带有 Task Governance 标签。在这里，kueue.x-k8s.io/priority-class 引用了一个更高优先级的 WorkloadPriorityClass，以便在团队资源受限时，模型服务可以抢占批量训练任务：

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: team-a-inference-endpoint
  namespace: hyperpod-ns-team-a  # scopes the endpoint to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: inference-priority  # higher-priority WorkloadPriorityClass
spec:
  ...
  # model source, instance type, replica count, autoscaling, etc.
  ...

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

HyperPod 可观测性

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

配置团队对 Grafana 的访问权限

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

1. 为 Amazon Managed Grafana 配置 Identity Center 身份验证 – 在 Amazon Managed Grafana 控制台中，导航到 Authentication 并启用 AWS IAM Identity Center。用户随后即可使用与 SageMaker Studio 相同的企业凭据登录 Grafana。
2. 将团队组指定为 Viewer（查看者） – 将 Identity Center 组（TeamA、TeamB）映射到 Grafana 的 Viewer 角色。这将为团队成员授予对仪表板和指标的只读访问权限，而无法修改仪表板或数据源。
3. 管理员访问权限 – 将 Admin 组指定为 Grafana 的 Admin（管理员）或 Editor（编辑者）角色，使其能够创建和修改仪表板、配置告警以及管理数据源。
4. 团队专属仪表板 – 可以考虑创建按命名空间筛选数据的专用仪表板，使每个团队只能看到自己的工作负载指标。Amazon Managed Grafana 支持 Grafana Teams（Grafana 原生的 RBAC 概念，与本架构中的组织团队不同），可以从 Identity Center 组映射而来，以限制仪表板的可见性并提供额外的数据隔离层。

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

图 12：授予团队只读 Viewer 访问权限的 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 Task Governance 相同的资源公平性目标。
• 支持退费与费用展示 – 命名空间级别的分配报告可以用于内部退费（计费团队按使用量收费）或费用展示（仅报告使用量而不计费）流程，为财务和平台团队提供公平分摊共享 GPU 成本所需的数据。

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

图 13：按命名空间分组的 Kubecost Allocations 仪表板，展示各团队成本

了解更多：SageMaker HyperPod 上的 Kubecost · Kubecost

结论

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

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

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

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

关于作者