Edit This Page

设备插件

从1.8版本开始,Kubernetes 提供了一套 设备插件框架, 使得供应商能够在不改动 Kubernetes 核心代码的情况下,向 kubelet 发布它们的资源。 供应商可以实现一个手动或以 DaemonSet 形式部署的插件,而不是编写自定义的 Kubernetes 代码。 插件的目标设备包括 GPUs、 高性能 NICs、 FPGAs、 InfiniBand 和其他类似的可能需要供应商特定的初始化和设置的计算资源。

设备插件注册

设备插件功能通过 DevicePlugins 功能入口控制, 该功能默认是禁用的。 当设备插件功能被启用时,kubelet 会对外提供一个 Registration gRPC 服务:

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

设备插件通过该 gRPC 服务将自身注册到 kubelet 。 注册过程中,设备插件需要发送:

注册成功后,设备插件将其管理的设备列表发送至 kubelet ,然后 kubelet 负责将这些资源作为 kubelet 节点状态更新的一部分,通知 apiserver 。 例如, 设备插件注册 vendor-domain/foo 到 kubelet , 并上报了节点上的两个健康的设备后,节点状态将更新, 发布2个 vendor-domain/foo

然后,开发者可以在 容器 规格中通过使用与 不透明整数型资源 中同样的流程来请求使用设备。 在1.8版本中, 扩展资源仅支持整型的资源,且容器规格中声明的 limitrequest 必须相等。

设备插件实现

设备插件的工作流程一般包括以下步骤:

  service DevicePlugin {
        // ListAndWatch returns a stream of List of Devices
        // Whenever a Device state change or a Device disappears, ListAndWatch
        // returns the new list
        rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

        // Allocate is called during container creation so that the Device
        // Plugin can run device specific operations and instruct Kubelet
        // of the steps to make the Device available in the container
        rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
  }

我们期望设备插件能够监测到 kubelet 重启,并将自身重新注册到新的 kubelet 实例中。 在1.8版本中,新的 kubelet 实例启动时,会清理当前 /var/lib/kubelet/device-plugins 路径下已存在的 Unix 套接字。 通过这一事件,设备插件能够监测到其 Unix 套接字被删除,并重新对自身进行注册。

设备插件部署

设备插件可以手动部署,也可以作为 DaemonSet 进行部署。 以 DaemonSet 形式部署的好处是设备插件故障时, Kubernetes能够重新启动 Pods 。 否则就需要额外的设备插件故障恢复机制。 目录 /var/lib/kubelet/device-plugins 需要访问特权, 所以设备插件必须在特权的安全上下文环境下运行。 如果设备插件以 DaemonSet 形式运行, /var/lib/kubelet/device-plugins 目录必须在插件的 PodSpec 中以 Volume 的形式挂载。

示例

设备插件实现的示例,参考 基于 COS 操作系统的 nvidia GPU 设备插件

FEATURE STATE: Kubernetes v1.11 feature-state-alpha.txt
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.