Kubernetes原生只管理CPU、内存这类通用资源，FPGA、GPU等加速硬件要进集群，必须借助设备插件框架。设备插件本质上是运行在节点上的一个守护进程，它负责把底层硬件抽象成kubelet可识别的资源，再由调度器统一分配。这篇文章以FPGA加速卡为例，从原理、插件编写、集群部署到故障排查，完整讲清楚整条链路。
一、设备插件机制是如何让FPGA被Kubernetes发现的
Kubernetes的Device Plugin框架从1.8版本引入，1.10之后逐渐稳定。它的核心思路很简单：kubelet在节点上暴露一个Unix Socket，路径通常是/var/lib/kubelet/device-plugins/kubelet.sock，任何想注册硬件的进程都可以通过gRPC连接这个socket，调用Register接口上报资源名称和自己的监听地址。
注册完成后，kubelet会回调插件提供的ListAndWatch接口，持续获取设备列表和健康状态。当调度器把一个请求FPGA资源的Pod调度到该节点时，kubelet在创建容器前会调用插件的Allocate接口，插件返回设备需要挂载到容器里的路径、环境变量等信息，运行时据此完成设备注入。整个过程对用户完全透明，Pod只需要在资源请求中写上自定义资源名即可。
需要特别注意的是，注册时指定的ResourceName必须符合vendor-domain/resource-type的格式，比如intel.com/fpga。这个前缀不能和kubernetes.io冲突，否则注册会被拒绝。FPGA插件上报的设备数量取决于厂商实现，有的按物理卡上报，有的按FPGA上的分区或AFU（Accelerator Function Unit）上报，这点在评估资源容量时要弄清楚。
二、编写一个FPGA设备插件的核心逻辑
理解了框架之后，自己实现一个FPGA插件并不复杂。插件需要实现DevicePluginServer的三个关键接口：ListAndWatch负责设备发现与状态推送，Allocate负责返回容器挂载信息，GetDevicePluginOptions可以返回可选能力。下面是一个简化版的Go实现骨架，展示了最核心的交互逻辑。
package main
import (
"context"
"fmt"
"net"
"path/filepath"
"time"
"golang.org/x/net/context"
"google.golang.org/grpc"
pluginapi "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1"
)
const (
serverSock = pluginapi.DevicePluginPath + "fpga.sock"
resourceName = "ippipp.com/fpga"
)
type FPGAPlugin struct {
devices []*pluginapi.Device
}
// ListAndWatch 持续上报FPGA设备状态
func (p *FPGAPlugin) ListAndWatch(s pluginapi.DevicePlugin_ListAndWatchServer) error {
for {
// 实际场景中这里应该探测 /dev 下设备节点是否正常
s.Send(&pluginapi.ListAndWatchResponse{Devices: p.devices})
time.Sleep(30 * time.Second)
}
return nil
}
// Allocate 返回容器需要挂载的设备路径和环境变量
func (p *FPGAPlugin) Allocate(ctx context.Context, reqs *pluginapi.AllocateRequest) (*pluginapi.AllocateResponse, error) {
resp := &pluginapi.AllocateResponse{}
for _, req := range reqs.ContainerRequests {
var mounts []*pluginapi.Mount
var envs []*pluginapi.ContainerEnvs
for _, id := range req.DevicesIDs {
// FPGA字符设备节点，例如 /dev/fpga0
mounts = append(mounts, &pluginapi.Mount{
ContainerPath: "/dev/" + id,
HostPath: "/dev/" + id,
ReadOnly: false,
})
}
resp.ContainerResponses = append(resp.ContainerResponses,
&pluginapi.ContainerAllocateResponse{
Mounts: mounts,
Envs: envs,
})
}
return resp, nil
}
func (p *FPGAPlugin) GetDevicePluginOptions(context.Context, *pluginapi.Empty) (*pluginapi.DevicePluginOptions, error) {
return &pluginapi.DevicePluginOptions{}, nil
}
func main() {
p := &FPGAPlugin{
devices: []*pluginapi.Device{
{ID: "fpga0", Health: pluginapi.Healthy},
{ID: "fpga1", Health: pluginapi.Healthy},
},
}
lis, _ := net.Listen("unix", serverSock)
s := grpc.NewServer()
pluginapi.RegisterDevicePluginServer(s, p)
s.Serve(lis)
}
这段代码演示了两个关键点：一是设备ID的命名要能直接映射到宿主机的设备文件路径，二是Allocate返回的Mount列表决定了容器内能看到哪些硬件。真实的FPGA插件还要考虑更多细节，比如PCIe BAR空间的映射、固件加载状态检查、以及多进程共享同一张卡时的隔离策略。
健康监测是容易被忽视的部分。FPGA卡可能因为固件崩溃、PCIe链路降速而失效，插件在ListAndWatch里如果只发一次设备列表就不再更新，kubelet会一直认为设备可用，导致Pod反复调度到坏卡上。正确做法是定期检查/sys/bus/pci/devices下的设备状态，或者调用厂商SDK的健康检查接口，一旦发现异常立即把设备Health改成Unhealthy，调度器就不会再把新Pod分过来。
三、集群侧部署与运行环境准备
插件写好后，推荐用DaemonSet方式部署，保证每个有FPGA卡的节点都运行一个实例。部署清单有几个容易踩坑的地方：需要挂载/var/lib/kubelet/device-plugins目录让插件能访问kubelet的socket；需要设置securityContext.privileged为true，否则插件可能没有权限访问设备节点；还要根据实际情况添加节点选择器，避免插件跑到没有卡的节点上白白消耗资源。
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fpga-device-plugin
namespace: kube-system
spec:
selector:
matchLabels:
app: fpga-device-plugin
template:
metadata:
labels:
app: fpga-device-plugin
spec:
nodeSelector:
fpga: "true" # 提前给FPGA节点打标签
containers:
- name: plugin
image: ippipp.com/fpga-plugin:v1.2.0
securityContext:
privileged: true
volumeMounts:
- name: device-plugin
mountPath: /var/lib/kubelet/device-plugins
- name: dev
mountPath: /dev
volumes:
- name: device-plugin
hostPath:
path: /var/lib/kubelet/device-plugins
- name: dev
hostPath:
path: /dev
节点侧的准备工作同样重要。FPGA驱动必须在宿主机安装完成，确保ls /dev能看到对应的字符设备，例如/dev/fpga0或厂商提供的/dev/dri渲染节点。如果容器运行时是containerd，还需要确认设备插件相关的配置没有被禁用。此外，FPGA管理工具（如厂商的烧写工具、调试工具）如果需要在Pod内使用，相关二进制和库文件要么打进容器镜像，要么通过挂载的方式注入。
部署完成后验证很简单，执行kubectl describe node查看Allocatable资源，应该能看到类似ippipp.com/fpga: 2的条目。然后提交一个测试Pod，在resources里请求这个资源名，进入容器后执行ls /dev/fpga*确认设备已经挂载进来了。
四、常见问题排查与进阶配置
实际运维中最常见的三类问题是：设备注册成功但Pod无法调度、容器内看不到设备、以及节点重启后资源消失。第一类问题通常是ResourceName格式不合法或者kubelet的设备插件目录被清理，kubelet重启后会删除旧的socket文件，插件进程必须监听socket变化并自动重新注册，否则资源就会消失。Kubernetes官方提供的kubelet-preferred-address-types与插件无关，但插件重连逻辑是必须自己实现的。
容器内看不到设备多数是Allocate返回的挂载路径写错了，或者设备节点的属主权限不对。FPGA设备通常属于root，容器以非特权用户运行时可能没有读写权限，这时要么在插件里返回正确的设备组信息，要么在Pod安全上下文中配置 supplementalGroups。另外，某些FPGA卡需要访问巨大的PCIe BAR地址空间，容器的默认ulimit可能不够，需要在运行时配置里调大锁定内存限制。
进阶场景方面，如果FPGA卡插在特定NUMA节点上，配合CPU Manager的静态策略可以减少跨NUMA访问带来的延迟；使用Topology Manager时插件可以上报设备的NUMA亲和信息。SR-IOV场景下，一张物理FPGA卡可以被虚拟成多个VF，插件按VF粒度上报资源，配合sriov-network-device-plugin可以让网络功能加速和计算加速跑在同一套体系里。对于需要按需加载不同AFU的工作负载，Intel的FPGA Operator提供了可编程区域管理，比裸设备插件更进一步，适合bitstream频繁切换的业务。
最后建议在生产环境给插件加上完善的日志和监控指标，把设备健康状态、注册成功次数暴露给Prometheus，这样FPGA资源池的异常可以在用户报障之前被发现，整个云原生加速平台的稳定性才有保障。
Kubernetes设备插件FPGA加速卡Device Plugin修改时间：2026-09-05 14:46:40