如何在共享AI集群中实现GPU资源与网络层面的硬隔离？

在多租户（Multi-Tenant）AI集群环境中，资源共享是常态，但“邻里喧嚣”（Noisy Neighbor）和数据安全问题是核心挑战。本文将深入探讨如何利用NVIDIA的硬件级隔离技术Multi-Instance GPU (MIG)和Kubernetes的网络策略（Network Policy），实现AI工作负载的GPU资源与网络层面的“硬”隔离。

1. GPU 资源硬隔离：NVIDIA MIG 实践

传统的GPU隔离依赖于Cgroups或调度器限制，但这只能限制算力使用比例，无法阻止恶意程序或失控进程占用全部显存，也无法保证低延迟。NVIDIA A100/H100等支持MIG技术的GPU，允许将单个物理GPU在硬件层面划分为多个完全隔离的实例（GPU Instances, GI）。

1.1 MIG 的原理与优势

MIG通过硬件隔离，为每个实例分配专用的SMs、L2缓存、显存带宽和显存。这意味着即使一个租户的进程崩溃或试图溢出显存，也不会影响到其他MIG实例，实现了真正的硬隔离。

1.2 集群配置步骤

步骤一：启用MIG模式（节点侧）

首先，确保您的操作系统驱动和NVIDIA工具（如nvidia-smi）支持MIG，并将其设置为MIG模式。这通常需要在BIOS中启用SR-IOV，并使用命令行工具。

1
2
3
4
5
6
7
8
9
10
11
12
# 检查当前状态

nvidia-smi -L



# 开启MIG模式

sudo nvidia-smi -i 0 -mig 1



# 创建MIG实例（例如，将GPU 0划分为7个1g.5gb实例）

# 1g.5gb 代表 1个计算单元，5GB显存

sudo nvidia-smi mig -i 0 -cgi 19 -C



# 确认创建结果

nvidia-smi -L

步骤二：Kubernetes 集成

Kubernetes集群需要部署最新的NVIDIA Device Plugin。该插件会自动识别MIG创建的资源并将其暴露给Kubernetes调度器，资源名称格式通常为nvidia.com/mig-g.gb。

步骤三：Pod 请求MIG资源

租户在部署工作负载时，可以直接请求专用的MIG实例，而不是整个GPU。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1

kind: Pod

metadata:

  name: tenant-a-job

  namespace: tenant-a

spec:

  containers:

  - name: ai-model-trainer

    image: tensorflow/tensorflow:latest-gpu

    resources:

      limits:

        # 请求一个40GB A100上的 4g.20gb MIG 实例

        nvidia.com/mig-4g.20gb: 1 

        # 注意：此处必须请求整数1，MIG实例不能被拆分

通过MIG，我们确保了GPU计算资源和显存的物理隔离。

2. 网络层面硬隔离：Kubernetes Network Policies

在共享集群中，默认情况下，所有Pod之间都可以相互通信（除非使用了特定的CNI配置）。为了实现网络隔离，防止租户A访问租户B的服务或数据存储，我们需要使用Kubernetes的Network Policy。

Network Policy 依赖于一个支持它的CNI插件（如Calico或Cilium）。它定义了Pod组之间如何被允许通信的规则。

2.1 隔离目标：Namespace Scope Hardening

目标是实现“默认拒绝”（Default Deny）策略，即除非明确允许，否则任何进出租户命名空间（Namespace）的网络流量都被阻止。

2.2 实施步骤：Default Deny 策略

以下策略应用于 tenant-a 命名空间，实现Ingress和Egress的全面隔离。

NetworkPolicy YAML 示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: default-deny-all

  namespace: tenant-a

spec:

  podSelector: {}

  # 作用于 namespace tenant-a 下的所有 Pod

  policyTypes:

  - Ingress

  - Egress



  # Ingress 规则：默认拒绝所有传入流量

  ingress: []



  # Egress 规则：默认拒绝所有传出流量，但允许必要的DNS查询

  egress:

  - to:

    - ipBlock:

        # 允许访问集群内部的DNS服务 (假设服务IP为 10.96.0.10)

        # 实际操作中，您可能需要允许对特定内部服务IP或CIDR范围的访问

        cidr: 10.96.0.10/32

    ports:

    - protocol: UDP

      port: 53

将此策略应用到每个租户命名空间后，该命名空间内的Pod将无法主动访问集群内的其他Pod，也无法向集群外部发起连接（除了必要的DNS）。

2.3 允许特定通信（如访问存储/监控）

如果租户需要访问共享服务（例如Ceph存储集群或外部S3），则需要添加特定的允许规则。例如，允许Egress到存储子网：

1
2
3
4
5
6
7
8
9
10
# 允许访问存储服务器子网

  egress:

  - to:

    - ipBlock:

        cidr: 192.168.1.0/24 

        # 假设存储服务位于此子网

    ports:

    - protocol: TCP

      port: 8080

# ... 接着是原有的 DNS 规则 ...

3. 总结

通过NVIDIA MIG实现硬件层面的GPU资源切分，可以保证工作负载的性能隔离和显存安全。结合Kubernetes Network Policy的默认拒绝策略，可以有效隔离不同租户间的网络通信，共同构成了共享AI集群中实现高性能、高安全的“硬隔离”基础设施。