设备插件

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

设备插件注册

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

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

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

• 它的 Unix 套接字名称。
• 所基于的设备插件 API 版本。
• 希望发布的 ResourceName 。 这里的 ResourceName 需要符合扩展资源命名方案，形如 vendor-domain/resource 。例如，Nvidia GPU 资源被发布为 nvidia.com/gpu 。

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

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

设备插件实现

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

• 初始化。 在这个阶段，设备插件执行供应商特定的初始化和设置，以确保设备处于就绪状态。

• 插件通过主机路径 /var/lib/kubelet/device-plugins/ 下的一个 Unix 套接字启动 gRPC 服务，该服务实现了以下接口：

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) {}
}

• 插件通过主机路径 /var/lib/kubelet/device-plugins/kubelet.sock 下的 Unix 套接字将自身注册到 kubelet 。

• 注册成功之后，设备插件以服务模式运行，其间持续监测设备健康状态，并在任何设备状态变化时上报到 kubelet 。插件也负责服务 Allocate gRPC 请求。 在 Allocate 过程中，插件可能会做设备特定的准备动作； 如 GPU 清理 或 QRNG 初始化。如操作成功，设备插件会返回一个 AllocateResponse ，它包含了用于访问分配的设备的容器运行时配置信息。 kubelet 将该信息传递到容器运行时。

我们期望设备插件能够监测到 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.16feature-state-alpha.txtThis 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.

反馈

此页是否对您有帮助？

感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题，可以访问Stack Overflow.在 GitHub 仓库上登记新的问题报告问题或者提出改进建议.