#Request GPU Resources

After Alauda GPU Management is installed, workloads request NVIDIA GPUs through the Kubernetes extended resource name.

This page covers direct whole-GPU allocation through Alauda GPU Management. For GPU sharing, memory or compute partitioning, or HAMi scheduling on NVIDIA GPUs, use the HAMi documentation.

#Resource key

The resource key must match what the device plugin reports in node allocatable resources. Confirm it from the live cluster rather than assuming it:

kubectl get node ${nodeName} -o jsonpath='{.status.allocatable}'

Requesting more than one GPU is a matter of the requested count; there is no separate multi-GPU procedure.

#Workload example

Request the GPU as a resource limit. With the container toolkit configured by the operator, the nvidia RuntimeClass gives the container access to the device.

apiVersion: v1
kind: Pod
metadata:
  name: gpu-workload
spec:
  restartPolicy: Never
  containers:
  - name: app
    image: <your-cuda-image>
    resources:
      limits:
        nvidia.com/gpu: 1

For a whole-GPU workload, set requests equal to limits for nvidia.com/gpu. A GPU is allocated as a whole device in this path; fractional or shared allocation is a HAMi capability.

Confirm the workload sees the GPU:

kubectl logs gpu-workload
# nvidia-smi -L output lists the allocated GPU

#Quota fields in ACP

If a node reports the resource but ACP quota pages do not show it, configure accelerator resource metadata in ACP. See Accelerator Resource Quota.

#RuntimeClass behavior

The container toolkit configures the containerd nvidia runtime handler. A GPU workload runs under the nvidia RuntimeClass so that the driver libraries and device nodes are injected into the container. If your environment requires it to be set explicitly, add runtimeClassName: nvidia to the Pod spec.