继CRI CNI CSI后，CNCF对三方设备的管理也将推行标准化接口了

第三方设备在runtime和编排系统下的现状如何？

Kubernetes支持Device Plugins

Nomad有自己的Device Plugins概念

Docker有一个in tree plugin机制

Podman有一个hooks概念

LXC有自己的钩子概念

Singularity（HPC运行时）有一个plugins的概念

还有些运行时几乎不支持第三方设备（例如：gVisor）

...

还有更多！

 

为什么说

“-- device  /dev/myDevice”是不够的？

 

在Linux系统下，一些简单的设备只需要能上报到节点即可。

然而，更多复杂的设备需要更加复杂的操作：

• 需要上报到更多的设备节点

• 需要检查容器和设备的兼容性（设备是否支持在该容器中运行）

• 执行一些runtime的特殊操作

• 执行一些设备的特殊操作（GPU内存释放或重新配置FPGA）

 

为什么

需要定义容器设备接口规范？

 

• 用户体验不一致：

在runtime和编排系统上的体验各不相同（即使使用的是相同的runtime）；

某些设备不支持特定的runtime。

• 供应商体验更糟糕：

设备插件不能兼容所有runtime，无法直接切换；

维护成本高（大量的时间花费在特性兼容运行时上）。

 

使用场景

 

• 使用场景1：Intel FPGA

英特尔FPGA被用于数据中心和工作站的许多不同使用场景（嵌入式SRAM、高速I/O、逻辑块等）

需要在容器中执行的操作：

1、挂载控