Skip to content

Commit b3ed6e6

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #36940 from swatisehgal/doc-deviceplugin-strict-ordering
doc: capture device-plugin stricter workflow ordering explicitly
2 parents 4cde169 + 88ecb05 commit b3ed6e6

File tree

1 file changed

+53
-48
lines changed

1 file changed

+53
-48
lines changed

‎content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md

Lines changed: 53 additions & 48 deletions
Original file line numberDiff line numberDiff line change
@@ -87,60 +87,65 @@ spec:
8787

8888
The general workflow of a device plugin includes the following steps:
8989

90-
* Initialization. During this phase, the device plugin performs vendor specific
90+
1. Initialization. During this phase, the device plugin performs vendor-specific
9191
initialization and setup to make sure the devices are in a ready state.
9292

93-
* The plugin starts a gRPC service, with a Unix socket under host path
93+
1. The plugin starts a gRPC service, with a Unix socket under the host path
9494
`/var/lib/kubelet/device-plugins/`, that implements the following interfaces:
9595

96-
```gRPC
97-
service DevicePlugin {
98-
// GetDevicePluginOptions returns options to be communicated with Device Manager.
99-
rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
100-
101-
// ListAndWatch returns a stream of List of Devices
102-
// Whenever a Device state change or a Device disappears, ListAndWatch
103-
// returns the new list
104-
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
105-
106-
// Allocate is called during container creation so that the Device
107-
// Plugin can run device specific operations and instruct Kubelet
108-
// of the steps to make the Device available in the container
109-
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
110-
111-
// GetPreferredAllocation returns a preferred set of devices to allocate
112-
// from a list of available ones. The resulting preferred allocation is not
113-
// guaranteed to be the allocation ultimately performed by the
114-
// devicemanager. It is only designed to help the devicemanager make a more
115-
// informed allocation decision when possible.
116-
rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
117-
118-
// PreStartContainer is called, if indicated by Device Plugin during registeration phase,
119-
// before each container start. Device plugin can run device specific operations
120-
// such as resetting the device before making devices available to the container.
121-
rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
122-
}
123-
```
124-
125-
{{< note >}}
126-
Plugins are not required to provide useful implementations for
127-
`GetPreferredAllocation()` or `PreStartContainer()`. Flags indicating which
128-
(if any) of these calls are available should be set in the `DevicePluginOptions`
129-
message sent back by a call to `GetDevicePluginOptions()`. The `kubelet` will
130-
always call `GetDevicePluginOptions()` to see which optional functions are
131-
available, before calling any of them directly.
132-
{{< /note >}}
133-
134-
* The plugin registers itself with the kubelet through the Unix socket at host
96+
```gRPC
97+
service DevicePlugin {
98+
// GetDevicePluginOptions returns options to be communicated with Device Manager.
99+
rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
100+
101+
// ListAndWatch returns a stream of List of Devices
102+
// Whenever a Device state change or a Device disappears, ListAndWatch
103+
// returns the new list
104+
rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
105+
106+
// Allocate is called during container creation so that the Device
107+
// Plugin can run device specific operations and instruct Kubelet
108+
// of the steps to make the Device available in the container
109+
rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
110+
111+
// GetPreferredAllocation returns a preferred set of devices to allocate
112+
// from a list of available ones. The resulting preferred allocation is not
113+
// guaranteed to be the allocation ultimately performed by the
114+
// devicemanager. It is only designed to help the devicemanager make a more
115+
// informed allocation decision when possible.
116+
rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
117+
118+
// PreStartContainer is called, if indicated by Device Plugin during registeration phase,
119+
// before each container start. Device plugin can run device specific operations
120+
// such as resetting the device before making devices available to the container.
121+
rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
122+
}
123+
```
124+
125+
{{< note >}}
126+
Plugins are not required to provide useful implementations for
127+
`GetPreferredAllocation()` or `PreStartContainer()`. Flags indicating
128+
the availability of these calls, if any, should be set in the `DevicePluginOptions`
129+
message sent back by a call to `GetDevicePluginOptions()`. The `kubelet` will
130+
always call `GetDevicePluginOptions()` to see which optional functions are
131+
available, before calling any of them directly.
132+
{{< /note >}}
133+
134+
1. The plugin registers itself with the kubelet through the Unix socket at host
135135
path `/var/lib/kubelet/device-plugins/kubelet.sock`.
136136

137-
* After successfully registering itself, the device plugin runs in serving mode, during which it keeps
138-
monitoring device health and reports back to the kubelet upon any device state changes.
139-
It is also responsible for serving `Allocate` gRPC requests. During `Allocate`, the device plugin may
140-
do device-specific preparation; for example, GPU cleanup or QRNG initialization.
141-
If the operations succeed, the device plugin returns an `AllocateResponse` that contains container
142-
runtime configurations for accessing the allocated devices. The kubelet passes this information
143-
to the container runtime.
137+
{{< note >}}
138+
The ordering of the workflow is important. A plugin MUST start serving gRPC
139+
service before registering itself with kubelet for successful registration.
140+
{{< /note >}}
141+
142+
1. After successfully registering itself, the device plugin runs in serving mode, during which it keeps
143+
monitoring device health and reports back to the kubelet upon any device state changes.
144+
It is also responsible for serving `Allocate` gRPC requests. During `Allocate`, the device plugin may
145+
do device-specific preparation; for example, GPU cleanup or QRNG initialization.
146+
If the operations succeed, the device plugin returns an `AllocateResponse` that contains container
147+
runtime configurations for accessing the allocated devices. The kubelet passes this information
148+
to the container runtime.
144149

145150
### Handling kubelet restarts
146151

0 commit comments

Comments
 (0)