Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.
Kubernetes was built to schedule CPU and memory, which it understands natively. A GPU is none of those things — the kubelet has no idea a GPU exists until something tells it. That something is the device plugin framework, which lets vendors advertise hardware as a named extended resource like nvidia.com/gpu. Until you grasp that a GPU is just a counted, opaque resource the scheduler matches against pod requests, every GPU-scheduling decision later in this course will feel arbitrary. This task plants the single mental model the rest of the course extends: a GPU is an extended resource a node advertises and a pod requests.
Inspect a GPU node and you'll see nvidia.com/gpu listed under Capacity and Allocatable, right next to cpu and memory. That line is the device plugin doing its job — the node is telling the scheduler how many GPUs it has to hand out.
Use these three in order. Each builds on the one before.
In one paragraph, explain how Kubernetes 'sees' a GPU when it has no built-in concept of one. What is an extended resource like nvidia.com/gpu?
Walk me through, step by step, how a GPU goes from physical hardware to appearing as nvidia.com/gpu in a node's Allocatable list. What component reports it and to whom?
Given a node where kubectl describe node shows nvidia.com/gpu under Capacity but Allocatable shows 0, how would the scheduler behave for a pod requesting one GPU, and what are the likely causes?
# Ask a node what resources it advertises
kubectl describe node gpu-node-1 | grep -A12 "Capacity:"
# Expected to include nvidia.com/gpu among the standard resources:
# Capacity:
# cpu: 32
# memory: 257698Mi
# nvidia.com/gpu: 4
# Allocatable:
# nvidia.com/gpu: 4
# List GPU counts across all nodes at a glance
kubectl get nodes -o custom-columns=NAME:.metadata.name,GPUs:.status.allocatable."nvidia\.com/gpu"