【中阶·融合】如何隔离多租户 AI 推理平台的 GPU 资源：从 Namespace 到 MIG/Kata 的五层纵深防御

【中阶·融合】如何隔离多租户 AI 推理平台的 GPU 资源：从 Namespace 到 MIG/Kata 的五层纵深防御

• 专栏：《AI 工程与安全深度实战》· 第11轮·第3篇

• 核心痛点：多个团队共享同一组昂贵的 GPU 集群，为什么一个租户的 OOM 崩溃能拖垮另一个租户的生产推理服务？Namespace 隔离真的能保护 GPU 显存中的模型权重吗？
• 适配人群：AI 平台工程师、Kubernetes 运维工程师、安全架构师，以及正在规划或运营多租户 GPU 推理平台的技术团队
• 收获能力：掌握从 K8s Namespace/RBAC 到 NVIDIA MIG 硬件分区、再到 Kata Containers VM 级隔离的五层纵深防御架构，具备在生产环境落地多租户 GPU 隔离方案的完整能力

• 技术背景与演进逻辑

  • 企业 AI 基础设施正从"一个团队独占一组 GPU"向"多团队共享 GPU 池"演进
    • 驱动力1：GPU 硬件成本极高（H100 节点云端每小时超 30 美元），独占模式导致利用率普遍低于 40%
    • 驱动力2：AI 推理负载具有突发性，独占分配意味着大量算力在低谷期闲置
    • 驱动力3：企业内部多团队（算法、产品、业务线）需要共享统一的 GPU 平台以降低运维复杂度
  • 但共享带来了严峻的隔离挑战
    • 性能干扰：一个租户的训练任务占满显存，导致另一个租户的推理 Pod 被 OOM Kill
    • 安全风险：GPU 驱动运行在宿主内核 Ring 0，容器边界对 ioctl 调用无任何拦截
    • 数据泄露：GPU 显存在 CUDA context 销毁后不会清零，下一个租户可读取上一个租户的模型权重和 KV-Cache
  • 技术演进必然性：从逻辑隔离到硬件隔离，多层防御缺一不可
  • 演进时间线（text 树表达）：多租户 GPU 隔离技术演进
    ├── 2016 -> NVIDIA Docker 发布: GPU 设备直接挂载到容器，无隔离
    ├── 2020 -> NVIDIA MIG 随 A100 发布: 首次实现 GPU 硬件级分区隔离
    ├── 2021 -> Kata Containers 支持 VFIO GPU 直通: VM 级内核隔离
    ├── 2023 -> CVE-2023-0184 披露: NVKM 堆溢出可从容器提权到宿主 root
    ├── 2024 -> Kueue GA + DRA Beta: K8s 原生 GPU 调度与资源分配框架成熟
    └── 2026 -> vCluster/HAMi v2.9: 控制面隔离 + 异构 GPU 虚拟化成为生产标配

• 核心原理深度解析

  • 多租户 GPU 隔离的本质是一个"五层纵深防御"问题

    • 五层隔离模型

      • 隔离层级分解（text 树）：多租户 GPU 五层隔离模型
        ├── 第1层 逻辑隔离层
        │ ├── 机制: Namespace + RBAC + ResourceQuota
        │ ├── 隔离粒度: API 层面的资源可见性与配额控制
        │ └── 局限: 不保护 GPU 显存、不拦截 ioctl 调用
        ├── 第2层 调度隔离层
        │ ├── 机制: PriorityClass + Kueue ClusterQueue + 拓扑感知调度
        │ ├── 隔离粒度: GPU 资源分配公平性与抢占策略
        │ └── 局限: 不阻止已分配 GPU 上的跨租户干扰
        ├── 第3层 GPU 虚拟化隔离层
        │ ├── 机制: NVIDIA MIG 硬件分区 / MPS 时间切片 / HAMi vGPU
        │ ├── 隔离粒度: GPU 显存与算力的物理或逻辑分区
        │ └── 局限: MIG 仅限 A100/H100/H200；MPS 无故障隔离
        ├── 第4层 运行时隔离层
        │ ├── 机制: Kata Containers + VFIO 直通 / gVisor 用户态内核
        │ ├── 隔离粒度: 每个租户独立内核，ioctl 攻击面被 VM 边界阻断
        │ └── 局限: Kata 增加冷启动延迟（500-1500ms）；gVisor 不支持 GPU
        └── 第5层 可观测性与策略执行层
        ├── 机制: DCGM Exporter + Prometheus + Falco + OPA/Gatekeeper
        ├── 隔离粒度: 实时监控 GPU 指标 + 异常访问检测 + 准入策略强制
        └── 局限: 检测而非预防，需配合前四层形成闭环
    • 逻辑推导：每一层解决一类特定的隔离失败模式，任何单一层被绕过都不会导致全面失守
    • 设计思想：纵深防御的核心不是"加更多墙"，而是"每一层解决不同的失败模式"
  • GPU 共享内核攻击面分析

    • GPU 驱动的共享内核问题

      • 攻击面分解（text 树）：GPU 共享内核攻击面
        ├── 宿主内核模块（Ring 0）
        │ ├── nvidia (NVKM): 核心设备驱动，处理所有 ioctl 调用
        │ ├── nvidia-uvm: 统一虚拟内存子系统
        │ ├── nvidia-modeset: 显示与模式设置
        │ └── nvidia-peermem: GPUDirect RDMA 对等内存访问
        ├── 容器内挂载的设备文件
        │ ├── /dev/nvidia0 ~ /dev/nvidiaX: 每块 GPU 一个字符设备
        │ ├── /dev/nvidiactl: 控制设备
        │ └── /dev/nvidia-uvm: 统一虚拟内存设备
        ├── 关键漏洞模式
        │ ├── CVE-2023-0184: NVKM 堆溢出（NV_ESC_RM_ALLOC ioctl）
        │ ├── CVE-2021-1076: NVKM 释放后重用（NV_ESC_REGISTER_FD）
        │ ├── CVE-2022-28181: nvidia-vgpu-mgr 越界写入
        │ └── CVE-2024-0074: nvidia-uvm 空指针解引用导致内核恐慌
        └── GPU 显存残留问题
        ├── CUDA context 销毁后显存不清零（性能权衡）
        ├── torch.cuda.empty_cache() 仅释放到 PyTorch 缓存分配器
        └── 下一个租户可读取上一个租户的模型权重与 KV-Cache
      • 逻辑推导：nvidia-device-plugin 将 /dev/nvidia0 直接挂载到 Pod，容器运行时不拦截 ioctl -> 所有容器共享同一个 NVKM 内核模块 -> 任何 NVKM 漏洞都可从容器提权到宿主 root
      • 设计思想：容器边界提供的是文件系统和 PID 命名空间隔离，对 GPU ioctl 攻击面提供零保护

• 核心模块详解

  • 第1层：Namespace + RBAC + ResourceQuota 逻辑隔离

    • 机制：Kubernetes Namespace 将集群划分为独立的虚拟空间，RBAC 控制每个租户的 API 访问范围，ResourceQuota 限制 GPU 资源消耗上限
    • 配置流程（text 树 + 箭头）：逻辑隔离部署流程
      ├── 创建 Namespace -> 配置 RBAC Role + RoleBinding
      ├── 配置 RBAC -> 设置 ResourceQuota（GPU 上限）
      ├── 设置 ResourceQuota -> 配置 LimitRange（默认请求值）
      └── 配置 LimitRange -> 验证租户只能看到自己的资源
    • 核心配置：apiVersion: v1
      kind: ResourceQuota
      metadata:
      name: gpu–quota–team–a
      namespace: team–a
      spec:
      hard:
      requests.nvidia.com/gpu: "4"
      limits.nvidia.com/gpu: "4"
      pods: "20"
      —
      apiVersion: v1
      kind: LimitRange
      metadata:
      name: gpu–limit–range
      namespace: team–a
      spec:
      limits:
      – default:
      nvidia.com/gpu: "1"
      defaultRequest:
      nvidia.com/gpu: "1"
      type: Container
    • 关键局限：Namespace 隔离不保护 GPU 显存。/dev/nvidia0 是宿主文件系统上的字符设备，nvidia-device-plugin 基于资源请求将其挂载到 Pod。两个不同 Namespace 的 Pod 在同一节点上，都请求 nvidia.com/gpu: “1”，它们可能共享同一块物理 GPU（通过 MPS 或时间切片）。Namespace 边界不阻止任何一个 Pod 的代码读取另一个 Pod 的 GPU DRAM

  • 第2层：PriorityClass + Kueue 调度隔离

    • 机制：PriorityClass 定义工作负载优先级，高优先级 Pod 可抢占低优先级 Pod 的 GPU 资源；Kueue 提供租户级 ClusterQueue 配额管理与公平调度
    • 核心配置：apiVersion: scheduling.k8s.io/v1
      kind: PriorityClass
      metadata:
      name: gpu–production
      value: 1000000
      globalDefault: false
      description: "生产推理服务优先级"
      —
      apiVersion: scheduling.k8s.io/v1
      kind: PriorityClass
      metadata:
      name: gpu–dev–test
      value: 100
      globalDefault: false
      description: "开发测试工作负载优先级"
    • Kueue ClusterQueue 配置（为每个租户设置独立的 GPU 配额）：apiVersion: kueue.x–k8s.io/v1beta1
      kind: ClusterQueue
      metadata:
      name: team–a–gpu–queue
      spec:
      resourceGroups:
      – coveredResources: ["cpu", "memory", "nvidia.com/gpu"]
      flavors:
      – name: gpu–h100
      resources:
      – name: nvidia.com/gpu
      nominalQuota: "8"
      borrowingLimit: "2"
      namespaceSelector:
      matchLabels:
      team: team–a
    • 调度策略优化：默认调度器倾向于 Spread（分散）调度，导致多节点部分利用。配置 MostAllocated 策略实现 Bin-Pack，将 GPU 工作负载集中到最少节点，空闲节点可通过 Cluster Autoscaler 缩容profiles:
      – schedulerName: default–scheduler
      pluginConfig:
      – name: NodeResourcesFit
      args:
      scoringStrategy:
      type: MostAllocated

  • 第3层：NVIDIA MIG 硬件级 GPU 分区隔离

    • 机制：MIG（Multi-Instance GPU）在硬件层面将单块物理 GPU 划分为最多 7 个独立实例，每个实例拥有独立的 DRAM 分区、L2 缓存切片和流式多处理器
    • MIG 隔离特性矩阵（text 树）：MIG vs MPS vs 时间切片对比
      ├── MIG（硬件分区）
      │ ├── 显存隔离: 硬件强制，跨实例不可读
      │ ├── 计算隔离: 独立 SM 分配，互不影响
      │ ├── 故障隔离: 一个实例崩溃不影响其他实例
      │ ├── 适用硬件: A100 / H100 / H200 / L40S
      │ └── 最大实例数: A100-80GB 可分 7 个 1g.10gb
      ├── MPS（多进程服务）
      │ ├── 显存隔离: 无，所有客户端共享同一地址空间
      │ ├── 计算隔离: SM 资源并发共享
      │ ├── 故障隔离: 无，一个客户端 CUDA 错误杀死所有客户端
      │ ├── 适用硬件: 所有支持 CUDA 的 GPU
      │ └── 安全警告: 仅适用于互相信任的 HPC 工作负载
      └── 时间切片（Time-Slicing）
      ├── 显存隔离: 无，所有进程共享同一显存空间
      ├── 计算隔离: 上下文切换，延迟不可预测
      ├── 故障隔离: 无
      ├── 适用硬件: 所有 NVIDIA GPU（含 T4/V100）
      └── 适用场景: 开发测试环境，非生产多租户
    • MIG 部署配置：# 在 A100 节点启用 MIG 模式
      sudo nvidia-smi -mig 1

      # 创建 7 个 1g.10gb 实例
      sudo nvidia-smi mig -cgi 1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb,1g.10gb -C

      # 通过 gpu-operator 的 MIG 策略配置
      helm install nvdp nvdp/nvidia-device-plugin \\n –version=0.17.0 \\n –namespace nvidia-device-plugin \\n –create-namespace \\n –set migStrategy=mixed

    • Pod 请求 MIG 资源：apiVersion: v1
      kind: Pod
      metadata:
      name: inference–tenant–a
      spec:
      containers:
      – name: vllm–server
      image: vllm/vllm–openai:v0.8.5
      resources:
      limits:
      nvidia.com/mig-1g.10gb: "1"
    • 关键安全价值：MIG 分区后，租户 A 的 Pod 无法寻址租户 B 的 DRAM，无论任何 CUDA API 调用或驱动漏洞。GPU 显存残留问题在 MIG 实例之间被硬件彻底消除

  • 第4层：Kata Containers + VFIO GPU 直通运行时隔离

    • 机制：Kata Containers 为每个 Pod 提供轻量级 VM 内核，GPU 通过 VFIO/IOMMU 直通到 VM 内部。NVKM ioctl 攻击面被限制在 VM 内核中，即使触发 CVE-2023-0184 级别的漏洞，也只能获得 VM root 而非宿主 root
    • 隔离架构（text 树 + 箭头）：Kata + VFIO GPU 隔离架构
      ├── 宿主节点
      │ ├── 宿主内核: nvidia 驱动 unbind -> vfio-pci 绑定
      │ ├── Kata Runtime: 创建轻量级 QEMU VM
      │ └── VFIO IOMMU: GPU 设备直通到 VM，DMA 边界由硬件强制
      ├── VM 内部（每个租户独立）
      │ ├── Guest 内核: 独立的 nvidia 驱动实例
      │ ├── /dev/nvidia0: 挂载在 VM 内部，不暴露到宿主
      │ └── NVKM ioctl: 在 Guest 内核中处理，攻击面被 VM 边界阻断
      └── 安全边界
      ├── CVE-2023-0184 利用: 获得 VM root，非宿主 root
      ├── GPU 显存: 每个 VM 有独立的 IOMMU DMA 映射
      └── 冷启动延迟: 500-1500ms（VM 启动时间）
    • Kata RuntimeClass 配置：apiVersion: node.k8s.io/v1
      kind: RuntimeClass
      metadata:
      name: kata–vfio–gpu
      handler: kata
      scheduling:
      nodeSelector:
      katacontainers.io/kata-runtime: "true"
    • Pod 使用 Kata 运行时：apiVersion: v1
      kind: Pod
      metadata:
      name: isolated–inference–pod
      spec:
      runtimeClassName: kata–vfio–gpu
      containers:
      – name: inference
      image: vllm/vllm–openai:v0.8.5
      resources:
      limits:
      nvidia.com/gpu: "1"
      securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
    • 适用场景：运行不受信任的推理代码（如用户提供模型制品）、合规敏感环境（金融/医疗）、需要最强隔离保障的生产租户

  • 第5层：DCGM + Falco + OPA/Gatekeeper 可观测性与策略执行

    • 机制：DCGM Exporter 采集每块 GPU 的详细指标（利用率、显存、温度、PCIe 带宽），Falco 检测异常 GPU 设备访问，OPA/Gatekeeper 在准入阶段强制执行安全策略
    • Falco GPU 异常访问检测规则：– rule: Unexpected GPU device access
      desc: >
      非已知 ML 运行时的进程访问 NVIDIA GPU 设备节点，
      可能是容器逃逸或配置错误
      condition: >
      (open_read or open_write) and
      fd.name startswith "/dev/nvidia" and
      not proc.name in (python3, vllm, tritonserver,
      nvidia-smi, dcgm-exporter) and
      container.id != host
      output: >
      异常 GPU 设备访问
      (proc=%proc.name container=%container.name
      pod=%k8s.pod.name ns=%k8s.ns.name)
      priority: WARNING
    • OPA/Gatekeeper 准入策略（强制 GPU Pod 设置安全上下文）：apiVersion: constraints.gatekeeper.sh/v1beta1
      kind: K8sPSPAllowedUsers
      metadata:
      name: gpu–pod–security–context
      spec:
      match:
      kinds:
      – apiGroups: [""]
      kinds: ["Pod"]
      scope: Namespaces
      parameters:
      runAsUser:
      rule: MustRunAsNonRoot
      runAsNonRoot: true
    • DCGM + Prometheus + Grafana 监控栈：采集 GPU 利用率、显存使用、温度、PCIe 带宽等指标，按租户 Namespace 聚合展示，设置显存 85% 告警阈值预防 OOM 级联故障

• 技术优缺点与适用场景

  • 对比总览（text 树表达）：五层隔离方案对比
    ├── 逻辑隔离（Namespace/RBAC/Quota）
    │ ├── 优势: 零额外开销，所有 K8s 集群原生支持
    │ ├── 局限: 不保护 GPU 显存，不拦截 ioctl
    │ ├── 性能影响: 无
    │ └── 适用规模: 任何规模的基础隔离
    ├── 调度隔离（Kueue/PriorityClass）
    │ ├── 优势: 公平配额管理，生产工作负载优先保障
    │ ├── 局限: 不阻止已分配 GPU 上的跨租户干扰
    │ ├── 性能影响: 无
    │ └── 适用规模: 多团队共享 GPU 池的中大型集群
    ├── MIG 硬件分区
    │ ├── 优势: 硬件强制显存隔离，消除跨实例数据泄露
    │ ├── 局限: 仅 A100/H100/H200 支持，分区粒度固定
    │ ├── 性能影响: 每个实例算力按比例缩减
    │ └── 适用规模: A100+ 硬件的生产推理集群
    ├── Kata + VFIO 运行时隔离
    │ ├── 优势: VM 级内核隔离，NVKM 漏洞影响限制在 VM 内
    │ ├── 局限: 冷启动延迟 500-1500ms，运维复杂度高
    │ ├── 性能影响: CUDA context 创建增加 1-3ms
    │ └── 适用规模: 不受信任代码 / 合规敏感环境
    └── 可观测性与策略执行
    ├── 优势: 实时检测异常，准入阶段拦截违规配置
    ├── 局限: 检测而非预防，需配合前四层
    ├── 性能影响: DCGM 采集约 1% 开销
    └── 适用规模: 所有生产 GPU 集群必选
  • 适用场景
    • 中小团队内部共享（3-5 个团队）：Namespace + RBAC + ResourceQuota + MIG（如有 A100+）即可满足
    • 企业级多租户平台（10+ 租户）：五层全部启用，Kata 仅对不受信任租户启用
    • AI 云服务提供商：五层 + vCluster 控制面隔离 + GPU 驱动版本钉死 + CVE 72 小时 P1 补丁 SLA
  • 禁忌场景
    • MPS 用于多租户生产环境：所有 MPS 客户端共享同一地址空间，一个租户的 CUDA 错误杀死所有租户
    • 仅依赖 Namespace 隔离保护 GPU 显存中的模型权重：Namespace 不拦截 ioctl，不保护 GPU DRAM
    • 时间切片用于对延迟敏感的生产推理：上下文切换引入不可预测的延迟抖动

• 实战落地

  • 完整部署流程

    • 部署链路（text 树 + 箭头）：多租户 GPU 隔离部署链路
      ├── 阶段1: 基础隔离
      │ ├── 创建租户 Namespace -> 配置 RBAC
      │ ├── 配置 RBAC -> 设置 ResourceQuota + LimitRange
      │ └── 验证: kubectl auth can-i –as=team-a-sa list pods -n team-b（应拒绝）
      ├── 阶段2: GPU 驱动安全加固
      │ ├── 钉死 GPU 驱动版本 -> 在 gpu-operator ClusterPolicy 中设置 version
      │ ├── 禁用 MPS -> 在 nvidia-device-plugin ConfigMap 中清空 mps.resources
      │ └── 验证: nvidia-smi –query-gpu=driver_version 确认版本一致
      ├── 阶段3: MIG 分区（A100+ 节点）
      │ ├── 启用 MIG 模式 -> 创建 MIG 实例 -> 配置 mixed 策略
      │ ├── 节点标记 nvidia.com/mig.config -> 重启 Device Plugin
      │ └── 验证: Pod 请求 mig-1g.10gb，确认 nvidia-smi 只显示自己的实例
      ├── 阶段4: 调度策略
      │ ├── 部署 Kueue -> 为每个租户创建 ClusterQueue
      │ ├── 配置 PriorityClass -> 生产 > 测试 > 开发
      │ └── 配置 Bin-Pack -> MostAllocated 调度策略
      ├── 阶段5: 运行时隔离（按需）
      │ ├── 部署 Kata Containers -> 配置 VFIO GPU 直通
      │ ├── 创建 kata-vfio-gpu RuntimeClass
      │ └── 验证: 不受信任租户的 Pod 使用 kata 运行时
      └── 阶段6: 可观测性与策略
      ├── 部署 DCGM Exporter + Prometheus + Grafana
      ├── 部署 Falco GPU 异常访问检测规则
      ├── 部署 OPA/Gatekeeper 准入策略
      └── 验证: 模拟异常 GPU 访问，确认 Falco 告警触发

  • GPU 驱动版本钉死与 CVE 追踪

    • 驱动版本钉死配置：apiVersion: nvidia.com/v1
      kind: ClusterPolicy
      metadata:
      name: gpu–cluster–policy
      spec:
      driver:
      enabled: true
      repository: nvcr.io/nvidia
      image: driver
      version: "560.35.03"
      operator:
      upgradeCRD: true
      daemonsets:
      updateStrategy: RollingUpdate
    • CVE 追踪要点：订阅 NVIDIA PSIRT RSS 和 NVD CPE cpe:2.3🅰️nvidia:gpu_driver 提要；CVSS >= 7.0 的内核模块漏洞视为 P1，72 小时内打补丁，受影响节点立即 cordon + drain

  • 避坑经验

    • MPS 用于多租户是最常见的致命错误：NVIDIA 文档明确说明 MPS 仅适用于互相信任的 HPC 工作负载。在多租户环境中启用 MPS 消除了故障隔离，一个租户的 CUDA 断言错误可杀死所有共置租户的推理进程
    • Namespace 隔离不等于 GPU 隔离：Kubernetes Namespace 是控制面概念，控制 Pod 通信、RBAC 和 NetworkPolicy。它不保护 GPU 显存。/dev/nvidia0 是宿主文件系统上的字符设备，Namespace 边界不阻止一个 Pod 的代码读取另一个 Pod 的 GPU DRAM
    • GPU 驱动 CVE 不在 Linux 发行版安全公告中：NVIDIA 驱动是闭源二进制，不通过发行版仓库分发。依赖 OS 厂商安全公告的团队会完全错过 NVIDIA 驱动 CVE。需要独立追踪 NVIDIA 安全公告页面和 NVD
    • MIG 分区变更需要 drain 节点：MIG 分区配置变更需要终止节点上所有 GPU 工作负载，不能热切换。规划分区方案时应预留足够余量
    • 显存残留是真实威胁：CUDA context 销毁后 GPU DRAM 不会清零。在非 MIG 环境中，下一个租户可通过 torch.empty() 读取上一个租户的模型权重和 KV-Cache。MIG 通过硬件分区消除此问题；非 MIG 环境需在应用层显式清零（tensor.zero_() + torch.cuda.synchronize()）

• 全文总结

  • 核心原理：多租户 GPU 隔离不是单一技术能解决的问题，必须在逻辑隔离、调度隔离、GPU 虚拟化隔离、运行时隔离、可观测性五个层面构建纵深防御
  • 关键结论：Namespace 隔离是必要基础但远不充分；MIG 是 A100+ 硬件上性价比最高的隔离手段；Kata + VFIO 是运行不受信任代码时的唯一可靠选择
  • 落地重点：先建立 Namespace/RBAC/Quota 基础，再启用 MIG 硬件分区，最后按需叠加 Kata 运行时隔离和 Falco 异常检测
  • 技术本质：GPU 驱动运行在宿主内核 Ring 0，容器边界对 GPU ioctl 攻击面提供零保护。真正的多租户安全必须在硬件层面（MIG/IOMMU）和运行时层面（VM 隔离）建立不可绕过的边界

• 免责声明

  • 本文所有技术内容仅供安全研究与教学目的使用。文中涉及的攻击面分析基于公开的 CVE 和学术研究，所有安全加固配置均在可控的隔离环境中验证。严禁将文中技术用于非法用途。实际部署安全方案前请结合自身业务场景进行充分测试。

• 本期专栏更新说明

  • 本文为《AI 工程与安全深度实战》订阅专栏持续迭代内容，专栏按初/中/高阶递进规划，长期更新 AI 云原生架构、GPU 算力工程、LLMOps 运维智能化、模型安全攻防、供应链安全、安全治理与合规实践，一次订阅，永久持续更新。

• 专栏推荐

  • AI 工程与安全深度实战
  • TypeScript 从入门到精通
  • LangChain/LangGraph 从入门到精通
  • Rust 从入门到精通

• 参考资料

  • Designing multitenant GPU infrastructure: Isolation across virtualization and Kubernetes platforms – Red Hat (2026)
  • GPU Tenant Isolation in Kubernetes: Strategies for AI Cloud Operators – vCluster (2025)
  • GPU Shared-Kernel Attacks: Isolation Failures in Multi-Tenant AI Inference Clusters – System Hardening (2025)
  • NVIDIA Multi-Instance GPU (MIG) 技术文档
  • Kata Containers: Kubernetes workload isolation for secure AI
  • HAMi v2.9: Kubernetes as the GPU Control Plane
  • Improve GPU utilization with Kueue in OpenShift AI – Red Hat Developer (2025)
  • CVE-2023-0184: NVIDIA GPU Driver Vulnerability – NVD