Clean up page device-plugins

pull/39517/head
zhuzhenghao 2023-02-18 01:07:55 +08:00
parent c475d558e0
commit d08ae655fd
1 changed files with 42 additions and 44 deletions

View File

@ -88,56 +88,56 @@ spec:
The general workflow of a device plugin includes the following steps: The general workflow of a device plugin includes the following steps:
1. Initialization. During this phase, the device plugin performs vendor-specific 1. Initialization. During this phase, the device plugin performs vendor-specific
initialization and setup to make sure the devices are in a ready state. initialization and setup to make sure the devices are in a ready state.
1. The plugin starts a gRPC service, with a Unix socket under the host path 1. The plugin starts a gRPC service, with a Unix socket under the host path
`/var/lib/kubelet/device-plugins/`, that implements the following interfaces: `/var/lib/kubelet/device-plugins/`, that implements the following interfaces:
```gRPC ```gRPC
service DevicePlugin { service DevicePlugin {
// GetDevicePluginOptions returns options to be communicated with Device Manager. // GetDevicePluginOptions returns options to be communicated with Device Manager.
rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {} rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
// ListAndWatch returns a stream of List of Devices // ListAndWatch returns a stream of List of Devices
// Whenever a Device state change or a Device disappears, ListAndWatch // Whenever a Device state change or a Device disappears, ListAndWatch
// returns the new list // returns the new list
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {} rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
// Allocate is called during container creation so that the Device // Allocate is called during container creation so that the Device
// Plugin can run device specific operations and instruct Kubelet // Plugin can run device specific operations and instruct Kubelet
// of the steps to make the Device available in the container // of the steps to make the Device available in the container
rpc Allocate(AllocateRequest) returns (AllocateResponse) {} rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
// GetPreferredAllocation returns a preferred set of devices to allocate // GetPreferredAllocation returns a preferred set of devices to allocate
// from a list of available ones. The resulting preferred allocation is not // from a list of available ones. The resulting preferred allocation is not
// guaranteed to be the allocation ultimately performed by the // guaranteed to be the allocation ultimately performed by the
// devicemanager. It is only designed to help the devicemanager make a more // devicemanager. It is only designed to help the devicemanager make a more
// informed allocation decision when possible. // informed allocation decision when possible.
rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {} rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
// PreStartContainer is called, if indicated by Device Plugin during registeration phase, // PreStartContainer is called, if indicated by Device Plugin during registeration phase,
// before each container start. Device plugin can run device specific operations // before each container start. Device plugin can run device specific operations
// such as resetting the device before making devices available to the container. // such as resetting the device before making devices available to the container.
rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {} rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
} }
``` ```
{{< note >}} {{< note >}}
Plugins are not required to provide useful implementations for Plugins are not required to provide useful implementations for
`GetPreferredAllocation()` or `PreStartContainer()`. Flags indicating `GetPreferredAllocation()` or `PreStartContainer()`. Flags indicating
the availability of these calls, if any, should be set in the `DevicePluginOptions` the availability of these calls, if any, should be set in the `DevicePluginOptions`
message sent back by a call to `GetDevicePluginOptions()`. The `kubelet` will message sent back by a call to `GetDevicePluginOptions()`. The `kubelet` will
always call `GetDevicePluginOptions()` to see which optional functions are always call `GetDevicePluginOptions()` to see which optional functions are
available, before calling any of them directly. available, before calling any of them directly.
{{< /note >}} {{< /note >}}
1. The plugin registers itself with the kubelet through the Unix socket at host 1. The plugin registers itself with the kubelet through the Unix socket at host
path `/var/lib/kubelet/device-plugins/kubelet.sock`. path `/var/lib/kubelet/device-plugins/kubelet.sock`.
{{< note >}} {{< note >}}
The ordering of the workflow is important. A plugin MUST start serving gRPC The ordering of the workflow is important. A plugin MUST start serving gRPC
service before registering itself with kubelet for successful registration. service before registering itself with kubelet for successful registration.
{{< /note >}} {{< /note >}}
1. After successfully registering itself, the device plugin runs in serving mode, during which it keeps 1. After successfully registering itself, the device plugin runs in serving mode, during which it keeps
monitoring device health and reports back to the kubelet upon any device state changes. monitoring device health and reports back to the kubelet upon any device state changes.
@ -297,7 +297,6 @@ However, calling `GetAllocatableResources` endpoint is not sufficient in case of
update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable. update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable.
{{< /note >}} {{< /note >}}
```gRPC ```gRPC
// AllocatableResourcesResponses contains informations about all the devices known by the kubelet // AllocatableResourcesResponses contains informations about all the devices known by the kubelet
message AllocatableResourcesResponse { message AllocatableResourcesResponse {
@ -318,14 +317,14 @@ Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started wit
``` ```
`ContainerDevices` do expose the topology information declaring to which NUMA cells the device is `ContainerDevices` do expose the topology information declaring to which NUMA cells the device is
affine. The NUMA cells are identified using a opaque integer ID, which value is consistent to affine. The NUMA cells are identified using a opaque integer ID, which value is consistent to
what device plugins report what device plugins report
[when they register themselves to the kubelet](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager). [when they register themselves to the kubelet](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager).
The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`. The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`.
Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet. Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet.
The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring
agents must run in a privileged security context. If a device monitoring agent is running as a agents must run in a privileged security context. If a device monitoring agent is running as a
DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
{{< glossary_tooltip term_id="volume" >}} in the device monitoring agent's {{< glossary_tooltip term_id="volume" >}} in the device monitoring agent's
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
@ -360,7 +359,7 @@ resource assignment decisions.
`TopologyInfo` supports setting a `nodes` field to either `nil` or a list of NUMA nodes. This `TopologyInfo` supports setting a `nodes` field to either `nil` or a list of NUMA nodes. This
allows the Device Plugin to advertise a device that spans multiple NUMA nodes. allows the Device Plugin to advertise a device that spans multiple NUMA nodes.
Setting `TopologyInfo` to `nil` or providing an empty list of NUMA nodes for a given device Setting `TopologyInfo` to `nil` or providing an empty list of NUMA nodes for a given device
indicates that the Device Plugin does not have a NUMA affinity preference for that device. indicates that the Device Plugin does not have a NUMA affinity preference for that device.
An example `TopologyInfo` struct populated for a device by a Device Plugin: An example `TopologyInfo` struct populated for a device by a Device Plugin:
@ -396,4 +395,3 @@ Here are some examples of device plugin implementations:
* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/) * Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
* Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) * Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/)
with Kubernetes with Kubernetes