Concepts

Detailed explanations of Kubernetes system concepts and abstractions.

Edit This Page

设备插件

FEATURE STATE: Kubernetes v1.9 alpha

This feature is currently in a alpha state, meaning:

  • The version names contain alpha (e.g. v1alpha1).
  • Might be buggy. Enabling the feature may expose bugs. Disabled by default.
  • Support for feature may be dropped at any time without notice.
  • The API may change in incompatible ways in a later software release without notice.
  • Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.

从1.8版本开始,Kubernetes 提供一种 设备插件框架,该框架能够让第三方设备资源开发者在不修改 Kubernetes 核心代码的前提下将设备接入 Kubernetes,从而使得 Kubernetes 能够使用第三方设备资源。通过该框架,第三方开发者可以实现一种通过手工或者 DaemonSet 部署的设备插件。这些设备一般包括如 GPU、高性能NIC、FPGA 和 InfiniBand 等需要第三方开发者进行特定初始化和设置的计算资源。

设备插件的注册

设备插件特性由 feature gate 中的 DevicePlugins 特性开关控制,该特性默认关闭。当启用该框架后,kubelet 将会对外暴露一个名为 Registration 的 gRPC 服务。服务描述如下:

service Registration {
	rpc Register(RegisterRequest) returns (Empty) {}
}

通过这个 gRPC 服务,设备插件就能向 kubelet 进行注册。在发起注册时,设备插件还需要发送以下内容:

当成功注册资源后,设备插件还需要向 kubelet 发送其可用设备的列表,之后 kubelet 会将这些资源作为节点状态的一部分上报给 API server。例如,有一个名为 vendor-domain/foo 的设备插件向 kubelet 进行注册,并发送两个可用设备的列表,这时候查看 node status 就能看到有两个可用的 vendor-domain/foo 设备了。

然后,开发人员可以在申请 容器资源 时使用和 不透明整数资源 相同的过程来请求第三方设备资源。在1.8版本中,可扩展资源只支持按整数分配,并且在容器规格定义中的 limit 必须和 request 相等。

设备插件的实现

设备插件的一般实现流程包括下列步骤:

当 kubelet 重启时,设备插件必须能够感知并且重新发起注册。在1.8版本中,kubelet 启动时将会清空 /var/lib/kubelet/device-plugins 目录下的所有 Unix Socket 文件,设备插件可以通过监控自己的 Unix Socket 文件是否被删除从而重新发起注册。

设备插件的部署

设备插件能够通过手工或者 DaemonSet 部署。通过 DaemonSet 部署的优势在于,当设备插件自身运行出错时,Kubernetes 将会自动重启该设备插件。否则,设备插件需要实现额外的机制来确保其自身的错误恢复。同时,对于指定的 /var/lib/kubelet/device-plugins 目录需要特定的访问权限,所以设备插件需要确保拥有这些访问权限。如果以 DaemonSet 的模式部署,/var/lib/kubelet/device-plugins 目录必须要在 PodSpec 中以 Volume 方式进行挂载。

案例

具体案例可见 基于 COS 操作系统的 nvidia GPU 设备插件

Analytics

Create an Issue Edit this Page