Merge pull request #37217 from tengqm/tweak-device-plugins

Tweak line wrappings in the device-plugin concepts page

Author: k8s-ci-robot

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

@@ -1,6 +1,8 @@
 ---
 title: Device Plugins
-description: Device plugins let you configure your cluster with support for devices or resources that require vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory.
+description: >
+  Device plugins let you configure your cluster with support for devices or resources that require
+  vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory.
 content_type: concept
 weight: 20
 ---
@@ -33,12 +35,12 @@ service Registration {
 A device plugin can register itself with the kubelet through this gRPC service.
 During the registration, the device plugin needs to send:
 
-  * The name of its Unix socket.
-  * The Device Plugin API version against which it was built.
-  * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
-    [extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
-    as `vendor-domain/resourcetype`.
-    (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
+* The name of its Unix socket.
+* The Device Plugin API version against which it was built.
+* The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the
+  [extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources)
+  as `vendor-domain/resourcetype`.
+  (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)
 
 Following a successful registration, the device plugin sends the kubelet the
 list of devices it manages, and the kubelet is then in charge of advertising those
@@ -133,12 +135,12 @@ The general workflow of a device plugin includes the following steps:
   path `/var/lib/kubelet/device-plugins/kubelet.sock`.
 
 * 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.
-It is also responsible for serving `Allocate` gRPC requests. During `Allocate`, the device plugin may
-do device-specific preparation; for example, GPU cleanup or QRNG initialization.
-If the operations succeed, the device plugin returns an `AllocateResponse` that contains container
-runtime configurations for accessing the allocated devices. The kubelet passes this information
-to the container runtime.
+  monitoring device health and reports back to the kubelet upon any device state changes.
+  It is also responsible for serving `Allocate` gRPC requests. During `Allocate`, the device plugin may
+  do device-specific preparation; for example, GPU cleanup or QRNG initialization.
+  If the operations succeed, the device plugin returns an `AllocateResponse` that contains container
+  runtime configurations for accessing the allocated devices. The kubelet passes this information
+  to the container runtime.
 
 ### Handling kubelet restarts
 
@@ -156,8 +158,7 @@ The canonical directory `/var/lib/kubelet/device-plugins` requires privileged ac
 so a device plugin must run in a privileged security context.
 If you're deploying a device plugin as a DaemonSet, `/var/lib/kubelet/device-plugins`
 must be mounted as a {{< glossary_tooltip term_id="volume" >}}
-in the plugin's
-[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
+in the plugin's [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 
 If you choose the DaemonSet approach you can rely on Kubernetes to: place the device plugin's
 Pod onto Nodes, to restart the daemon Pod after failure, and to help automate upgrades.
@@ -202,7 +203,8 @@ service PodResourcesLister {
 
 The `List` endpoint provides information on resources of running pods, with details such as the
 id of exclusively allocated CPUs, device id as it was reported by device plugins and id of
-the NUMA node where these devices are allocated. Also, for NUMA-based machines, it contains the information about memory and hugepages reserved for a container.
+the NUMA node where these devices are allocated. Also, for NUMA-based machines, it contains the
+information about memory and hugepages reserved for a container.
 
 ```gRPC
 // ListPodResourcesResponse is the response returned by List function
@@ -273,6 +275,7 @@ conjunction with the List() endpoint. The result obtained by `GetAllocatableReso
 the same unless the underlying resources exposed to kubelet change. This happens rarely but when
 it does (for example: hotplug/hotunplug, device health changes), client is expected to call
 `GetAlloctableResources` endpoint.
+
 However, calling `GetAllocatableResources` endpoint is not sufficient in case of cpu and/or memory
 update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable.
 {{< /note >}}
@@ -285,20 +288,22 @@ message AllocatableResourcesResponse {
     repeated int64 cpu_ids = 2;
     repeated ContainerMemory memory = 3;
 }
-
 ```
+
 Starting from Kubernetes v1.23, the `GetAllocatableResources` is enabled by default.
-You can disable it by turning off the
-`KubeletPodResourcesGetAllocatable` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+You can disable it by turning off the `KubeletPodResourcesGetAllocatable`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
 
 Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started with the following flag:
 
-`--feature-gates=KubeletPodResourcesGetAllocatable=true`
-
-`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 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).
+```
+--feature-gates=KubeletPodResourcesGetAllocatable=true
+```
 
+`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
+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).
 
 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.
@@ -308,15 +313,17 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
 {{< glossary_tooltip term_id="volume" >}} in the device monitoring agent's
 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 
-Support for the `PodResourcesLister service` requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
+Support for the `PodResourcesLister service` requires `KubeletPodResources`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
 It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
 
 ## Device plugin integration with the Topology Manager
 
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-The Topology Manager is a Kubelet component that allows resources to be co-ordinated in a Topology aligned manner. In order to do this, the Device Plugin API was extended to include a `TopologyInfo` struct.
-
+The Topology Manager is a Kubelet component that allows resources to be co-ordinated in a Topology
+aligned manner. In order to do this, the Device Plugin API was extended to include a
+`TopologyInfo` struct.
 
 ```gRPC
 message TopologyInfo {
@@ -327,11 +334,17 @@ message NUMANode {
     int64 ID = 1;
 }
 ```
-Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo struct as part of the device registration, along with the device IDs and the health of the device. The device manager will then use this information to consult with the Topology Manager and make resource assignment decisions.
 
-`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.
+Device Plugins that wish to leverage the Topology Manager can send back a populated TopologyInfo
+struct as part of the device registration, along with the device IDs and the health of the device.
+The device manager will then use this information to consult with the Topology Manager and make
+resource assignment decisions.
+
+`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.
 
-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.
+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.
 
 An example `TopologyInfo` struct populated for a device by a Device Plugin:
 
@@ -346,20 +359,24 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
 Here are some examples of device plugin implementations:
 
 * The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
-* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for Intel GPU, FPGA, QAT, VPU, SGX, DSA, DLB and IAA devices
-* The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for hardware-assisted virtualization
+* The [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) for
+  Intel GPU, FPGA, QAT, VPU, SGX, DSA, DLB and IAA devices
+* The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for
+  hardware-assisted virtualization
 * The [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
 * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
 * The [SocketCAN device plugin](https://github.com/collabora/k8s-socketcan)
 * The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
 * The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
 * The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-device-plugin) for Xilinx FPGA devices
 
-
 ## {{% heading "whatsnext" %}}
 
-
-* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
-* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
+* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device
+  plugins
+* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/)
+  on a node
 * 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/) with Kubernetes
+* 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
+