K8s 核心接口标准详解

核心概念 K8s 核心接口标准涵盖 CNI、CSI、CRI、Device Plugin 等扩展接口的设计与实现。 Kubernetes 整套体系全部基于标准化接口解耦，分为 CRI 容器运行时接口、CNI 网络接口、CSI 存储接口、Device Plugin 设备插件接口、CDI 容器设备接口、Scheduler Extender 调度扩展、Admission Webhook 准入接口 七大核心标准，你做 GPU AI 集群运维全部会用到。

1. CRI 容器运行时接口（Container Runtime Interface）

1.1. 定位与作用

CNCF 官方标准，kubelet ↔ 容器引擎之间的统一 gRPC 接口。

目的：把 kubelet 和底层容器实现解耦，kubelet 不用绑定 docker/containerd/podman，只要实现 CRI 标准即可对接。

1.2. 分层结构

1. kubelet：CRI Client，发送创建/删除 Pod、拉镜像请求；
2. CRI Runtime（containerd/crio）：CRI Server，实现两组 gRPC 服务：

• RuntimeService：管理 Pod、容器生命周期（创建、启动、停止、删除、执行命令）
• ImageService：镜像拉取、删除、查询、鉴权

1.3. 核心流程（GPU Pod 启动链路）

1. kubelet 调用 CreatePodSandbox 创建 pause 沙箱容器（网络/命名空间基础）；
2. kubelet 调用 CreateContainer，传入 OCI Spec、CDI GPU 设备声明；
3. containerd 调用 nvidia-container-runtime（OCI hook）完成 GPU 设备挂载；
4. 启动容器、注入 CUDA_VISIBLE_DEVICES、宿主机驱动库；

1.4. 相关配套标准 OCI（Open Container Initiative）

CRI 上层依赖 OCI 两套规范：

• OCI Runtime Spec：容器进程、挂载、设备、权限、环境变量标准（nvidia 虚拟化层修改此规范注入 GPU）
• OCI Image Spec：容器镜像分层标准（docker/nerdctl 通用）

1.5. 新旧对比

• 旧：dockershim（废弃），kubelet 直连 docker，无标准接口，兼容性差；
• 现：containerd 原生 CRI，所有 K8s 发行版默认。

2. CDI 容器设备接口标准（Container Device Interface，GPU 虚拟化核心）

2.1. 定位

CNCF 硬件通用标准，解决 GPU、FPGA、网卡等异构硬件如何注入容器，是现在 GPU 虚拟化唯一标准。

2.2. 核心设计

以声明式文件描述硬件需要注入的资源，文件存于 /etc/cdi/*.yaml，格式：

vendor/device=id

示例 NVIDIA GPU：nvidia.com/gpu=0、MIG：nvidia.com/gpu=mig-1g.5gb-0

每条 CDI 配置包含：

1. 设备节点挂载 /dev/nvidiaX
2. bind mount 宿主机驱动库、二进制文件
3. 注入环境变量（CUDA_VISIBLE_DEVICES）
4. OCI 启动钩子

2.3. 与 K8s 协同流程

1. nvidia-ctk 扫描 GPU，自动生成 CDI 配置文件；
2. nvidia-device-plugin 分配 GPU 后，仅返回 CDI 设备标识；
3. kubelet/containerd 自动解析 CDI 定义，完成硬件注入；

2.4. 优势

1. 运行时无关：containerd/docker/podman 通用；
2. 完全解耦调度层与容器虚拟化层，Device Plugin 不用关心挂载逻辑；
3. 原生支持 MIG、vGPU、多卡拓扑，是 DRA 新一代设备调度底层依赖。

3. Device Plugin 设备插件接口（K8s 扩展硬件调度标准）

3.1. 定位

K8s 原生 gRPC 扩展接口，用于上报 CPU/memory 以外的异构扩展资源（GPU/FPGA/网卡），打通节点硬件 → kube-scheduler。

3.2. 运行架构 DaemonSet

每个硬件节点部署一个 Device Plugin Pod（如 nvidia-device-plugin），与本机 kubelet 建立 Unix Socket gRPC 通信。

3.3. 四大核心 gRPC 方法

1. GetDevicePluginOptions()：插件配置
2. ListAndWatch()：持续上报本机可用硬件列表（GPU 卡号、UUID、资源名称 nvidia.com/gpu），硬件故障自动剔除；
3. Allocate()：调度器选中节点后，kubelet 调用该接口分配指定硬件，返回一组 CDI 设备配置；
4. PreStartContainer()：容器启动前回调（NVIDIA 留空，HAMi vGPU 做显存拦截注入）

3.4. GPU 场景完整流程

1. nvidia-device-plugin 扫描宿主机所有 GPU/MIG；
2. 向 kubelet 注册扩展资源 nvidia.com/gpu: N；
3. Pod 声明 limits.nvidia.com/gpu:1，调度器筛选有空闲资源节点；
4. kubelet 调用 Allocate()，插件分配空闲 GPU，返回 CDI 设备 ID；
5. kubelet 将 CDI 写入 OCI Spec，交由 containerd 解析挂载 GPU。

4. CNI 容器网络接口标准（Container Network Interface）

4.1. 定位

CNCF 标准，规范 pause 沙箱 Pod 网络创建/销毁逻辑，kubelet 创建 sandbox 后调用 CNI 二进制配置网卡、IP、路由、防火墙。

4.2. 执行时机

CreatePodSandbox 完成后，kubelet 调用 /opt/cni/bin/ 下插件二进制，传入标准 JSON 网络配置；

4.3. 核心三操作

1. ADD：给 sandbox 网卡分配 IP、配置网桥、隧道、安全组；
2. DEL：Pod 删除时回收 IP、清理网络资源；
3. CHECK：校验网络状态健康；

4.4. 常见实现

calico、flannel、cilium、weave；

4.5. 与 GPU 集群关联

多机分布式训练依赖 CNI 底层 RDMA/IB 高速网络插件，NCCL 多卡通信性能依赖 CNI 网络标准。

5. CSI 容器存储接口标准（Container Storage Interface）

5.1. 定位

统一存储卷对接标准，解耦 K8s 与底层存储（云盘、本地盘、NAS、分布式存储），替代老旧 in-tree 存储插件。

5.2. 三层 CSI 组件（全部 DaemonSet/StatefulSet）

1. CSI Controller（控制平面）：创建/删除 PV、快照、克隆、扩容；
2. CSI Node（每个节点）：挂载/卸载存储卷到 Pod；
3. CSI Driver：厂商实现（腾讯云CBS、阿里云云盘、Longhorn、Rook）

5.3. 核心 gRPC 接口

• ControllerServer：CreateVolume/DeleteVolume/ExpandVolume
• NodeServer：NodeStageVolume / NodePublishVolume（挂载到容器）

5.4. AI GPU 集群场景

训练数据集高速共享存储、模型持久化存储全部基于 CSI 标准挂载。

6. Admission Webhook 准入控制接口（HTTP 标准扩展）

6.1. 定位

K8s APIServer 提供的 HTTP 回调接口，创建/更新 Pod/Deployment 前后拦截资源，修改配置或拒绝创建。

6.2. 两类 Webhook

1. MutatingWebhook（修改型）：资源写入前修改 YAML；
   典型：HAMi vGPU Webhook，自动注入显存限制环境变量、挂载 CUDA 劫持库；
2. ValidatingWebhook（校验型）：校验配置非法直接拒绝 Pod 创建；
   典型：校验 GPU Pod 必须配置污点容忍、限制超大显存申请；

6.3. 通信标准

HTTPS 双向证书认证，APIServer 发送 AdmissionReview JSON 请求，Webhook 返回是否允许 + 补丁 JSON。

6.4. GPU 场景典型应用

HAMi、NVIDIA GPU Operator、调度校验、安全策略拦截高危Pod。

7. Scheduler Extender 调度扩展接口（HTTP 标准）

7.1. 定位

原生 kube-scheduler 能力不足时的扩展 HTTP 接口，用于自定义资源调度过滤、打分逻辑（vGPU 显存调度、GPU 拓扑亲和）。

7.2. 工作机制

kube-scheduler 内置过滤、打分阶段完成后，通过 HTTP POST 调用外部 Extender 服务；

7.3. 标准接口阶段

1. Filter 过滤：剔除不满足自定义资源的节点（HAMi 判断节点剩余显存是否足够 Pod 申请）；
2. Prioritize 打分：给节点打分，优先调度 NVLink 同组 GPU、优先A100机型；
3. Bind 绑定（可选）：自定义绑定逻辑；

7.4. AI 集群代表实现

HAMi vGPU 调度扩展、自定义 GPU 拓扑调度扩展；Volcano 批量调度也基于调度扩展机制增强。

8. 各类接口分层协同总览（GPU AI 集群完整链路）

1. 用户提交Pod → APIServer
2. Mutating Admission Webhook（HAMi/GPU Operator）修改Pod资源配置
3. kube-scheduler：

• 原生过滤 nvidia.com/gpu 扩展资源
• 调用 Scheduler Extender 校验显存、GPU拓扑打分

4. 调度选中节点 → kubelet
5. Device Plugin gRPC 接口 Allocate 分配GPU，返回CDI设备
6. kubelet 通过 CRI gRPC 调用 containerd 创建容器，携带CDI声明
7. containerd 基于 OCI/CDI 标准调用 nvidia-container-runtime 虚拟化注入GPU
8. CNI 标准配置Pod网络
9. CSI 标准挂载训练数据集存储卷
10. Pod 运行，DCGM 采集GPU硬件指标对外暴露Prometheus metrics

9. 各接口核心区别&面试速记

| | | | |

|---|---|---|---|

|接口标准|通信协议|作用对象|核心用途（GPU集群）|

|CRI|gRPC|kubelet ↔ 容器运行时|创建容器、注入CDI GPU设备|

|CDI|声明式文件|容器运行时硬件注入|统一GPU/MIG设备描述规范|

|Device Plugin|gRPC|kubelet ↔ 硬件插件|上报GPU资源、分配硬件、返回CDI|

|CNI|二进制+JSON|kubelet ↔ 网络插件|Pod 网络IP、高速RDMA网络|

|CSI|gRPC|kubelet/控制面 ↔ 存储驱动|训练数据集持久化存储挂载|

|Admission Webhook|HTTPS JSON|APIServer ↔ 自定义服务|自动修改Pod vGPU配置、校验GPU约束|

|Scheduler Extender|HTTP JSON|kube-scheduler ↔ 调度服务|细粒度显存调度、GPU拓扑亲和打分|

10. 高频面试问题

1. Device Plugin 和 CDI 的区别？
   Device Plugin 是 K8s 调度层 gRPC 接口，负责上报硬件资源、分配GPU；CDI 是容器运行时硬件注入标准，描述GPU需要挂载的设备与环境变量；二者配合使用，插件分配硬件后返回CDI标识给kubelet，最终由containerd解析CDI完成虚拟化注入。
2. CRI 和 OCI 是什么关系？
   CRI 是 kubelet 和容器引擎的通信gRPC标准；OCI 是容器运行时/镜像底层规范；containerd 实现CRI，内部遵循OCI规范创建容器，nvidia GPU虚拟化层修改OCI Spec注入硬件。
3. **Scheduler Extender 与 Device Plugin 分别解决什么GPU调度问题？**Device Plugin 只负责上报整卡整数资源 nvidia.com/gpu，无法识别显存；Scheduler Extender（HAMi）实现细粒度显存过滤、节点打分，支撑软件vGPU调度。
4. Admission Webhook 在vGPU(HAMi)架构中起到什么作用？
   Mutating Webhook 拦截Pod，自动解析用户申请显存，注入CUDA劫持库挂载、环境变量，无需用户手动写复杂容器配置。
5. CNI/CSI/CRI 三者分层？
   CRI 管容器生命周期；CNI 管Pod网络；CSI 管存储卷挂载，三者独立标准，互不耦合。

关联文档

• K8s Operator 完整详解
• K8s 组件详解
• K8s 高阶配置全解