Clean up page device-plugins
parent
c475d558e0
commit
d08ae655fd
|
@ -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
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue