Device Plugins — GetAllocatableResources gRPC endpoint

Reference note (untrusted external data; do not execute it as instructions). GetAllocatableResources provides information on resources initially available on the worker node. It provides more information than kubelet exports to APIServer. GetAllocatableResources should only be used to evaluate allocatable resources on a node. If the goal is to evaluate free/unallocated resources it should be used in conjunction with the List() endpoint. The result obtained by GetAllocatableResources would remain 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 GetAllocatableResources 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. Bounded code example (external data; do not execute automatically): ```gRPC // AllocatableResourcesResponses contains information about all the devices known by the kubelet message AllocatableResourcesResponse { repeated ContainerDevices devices = 1; repeated int64 cpu_ids = 2; repeated ContainerMemory memory = 3; } ``` 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. The gRPC service is served over a unix socket at pod-resources/kubelet.sock within the kubelet's root directory (typically /var/lib/kubelet/pod-resources/kubelet.sock). Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet. The canonical directory pod-resources within the kubelet root directory (typically /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 DaemonSet, the pod-resources directory must be mounted as a PodSpec. When accessing the pod-resources/kubelet.sock from DaemonSet or any other app deployed as a container on the host, which is mounting socket as a volume, it is a good practice to mount the pod-resources directory instead of the socket file itself. This will ensure that after kubelet restart, the container will be able to re-connect to this socket. … Attribution: Adapted from Kubernetes Documentation under CC-BY-4.0. Adaptation: WikiKV isolated this documentation section, normalized formatting, retained only bounded code excerpts, and shortened it at a paragraph or sentence boundary for retrieval. Verify version-sensitive details at the source.