打通任督二脉 - Device Plugin 让 k8s “看见” GPU
打通任督二脉 - Device Plugin 让 k8s “看见” GPU
上一篇咱们聊了为啥要把 GPU 这个“计算猛兽”拉进 Kubernetes (k8s) 这个“智能调度中心”。目标很美好：提高效率、简化管理、弹性伸缩。但现实是，k8s 天生并不认识 GPU 这位“新朋友”。就像你的电脑操作系统，默认只认识 CPU、内存、硬盘这些“老伙计”，你要插个新奇特的硬件，总得装个驱动或者做点啥，系统才能认出来，对吧？
那么，k8s 是怎么做到“认识”并管理像 GPU 这样的非原生硬件资源的呢？答案就是今天要隆重介绍的 Device Plugin 框架！
什么是 Device Plugin 框架？
你可以把 k8s 的 Device Plugin 框架想象成一个开放的“硬件接入标准”，有点像电脑上的 USB 接口标准。
- 类比：有了 USB 标准，无论是鼠标、键盘、U 盘还是摄像头，只要硬件厂商按照这个标准来设计接口，你的电脑就能识别并使用它们，而不需要电脑厂商为市面上每一款新硬件都单独修改操作系统。
k8s 的 Device Plugin 框架也是类似：
- 标准接口：它定义了一套标准的通信协议（基于 gRPC），让外部程序（就是所谓的 Device Plugin）可以和
kubelet（运行在每个k8s节点上的“管家进程”）对话。 - 硬件厂商负责：硬件厂商（比如 NVIDIA、Intel、AMD 等）或者社区可以为他们的特定硬件开发一个 Device Plugin 程序。
- 解耦核心：这样做的好处是，
k8s的核心代码不需要为每一种新硬件都做修改，保持了核心的简洁和稳定。想支持新硬件？开发一个对应的 Device Plugin 就行了！
工作流程简化版：
- 一个特定硬件的 Device Plugin 程序（通常打包在容器里）在安装了该硬件的
k8s节点上运行起来。 - 它会侦测节点上存在的自家硬件（比如 NVIDIA Device Plugin 会去找 NVIDIA GPU 卡）。
- 然后，它会主动连接到该节点上的
kubelet进程。 - 通过标准的 gRPC 接口，它向
kubelet注册自己，并报告：“嘿，kubelet老兄，我在这儿发现了 X 块 Y 型号的硬件（比如nvidia.com/gpu: 2），以后你要分配这种资源就找我哈！” kubelet收到信息后，会更新节点的状态，并将这些新发现的“可分配资源”上报给k8s的大脑——API Server。
这样一来，整个集群就都知道这个节点上有多少块可用的特定硬件资源了。
明星选手：NVIDIA Device Plugin
既然咱们主要关注 GPU，那最常打交道的自然就是 NVIDIA Device Plugin 了。这是 NVIDIA 官方提供的，专门用来让 k8s 识别和管理 NVIDIA GPU 的插件。
为了确保每个安装了 NVIDIA GPU 的节点都能被 k8s 识别，这个插件通常会以 DaemonSet 的形式部署。
- 小科普
DaemonSet：它是k8s的一种工作负载类型，能确保在集群中的每一个（或指定的某一些）节点上都运行一个 Pod 副本。非常适合用来部署节点级别的监控、日志收集或者像咱们 Device Plugin 这样的“常驻代表”。
实战：部署 NVIDIA Device Plugin
好了，理论讲得差不多，咱们来看看实际操作。部署 NVIDIA Device Plugin 通常就是向 k8s 集群应