Встановлення драйверів та виділення пристроїв з DRA
Kubernetes v1.35 [stable](стандартно увімкнено)Цей посібник показує, як встановити драйвери Динамічного виділення ресурсів (DRA) у вашому кластері та як використовувати їх разом з API DRA для виділення пристроїв для Pod. Ця сторінка призначена для адміністраторів кластерів.
Динамічне виділення ресурсів (DRA) дозволяє кластеру керувати доступністю та виділенням апаратних ресурсів для задоволення вимог Podʼів до апаратних ресурсів та налаштувань. Щоб підтримати це, суміш вбудованих компонентів Kubernetes (таких як планувальник Kubernetes, kubelet і kube-controller-manager) та сторонніх драйверів від власників пристроїв (які називаються драйверами DRA) спільно відповідають за оголошення, виділення, підготовку, монтування, перевірку стану, скасування підготовки та очищення ресурсів протягом усього життєвого циклу Podʼа. Ці компоненти обмінюються інформацією через серію специфічних для DRA API в групі API resource.k8s.io, включаючи DeviceClasses, ResourceSlices, ResourceClaims, а також нові поля в самій специфікації Pod.
Цілі
- Розгорнути приклад драйвера DRA
- Розгорнути Pod, що виконує заявку на апаратні ресурси за допомогою API DRA
- Видалити Pod, який має заявку
Перш ніж ви розпочнете
Ваш кластер повинен підтримувати RBAC. Ви можете спробувати цей посібник з кластером, який використовує механізм авторизації, відмінний від RBAC, але в цьому випадку вам доведеться адаптувати кроки щодо визначення ролей і дозволів.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Цей посібник був протестований з вузлами Linux, хоча він також може працювати з іншими типами вузлів.
Версія вашого Kubernetes сервера має бути не старішою ніж v1.34.Для перевірки версії введіть kubectl version.
Якщо ваш кластер наразі не працює під управлінням Kubernetes 1.35, перегляньте документацію щодо версії Kubernetes, яку ви плануєте використовувати.
Дослідження початкового стану кластера
Ви можете витратити деякий час, щоб спостерігати за початковим станом кластера з увімкненим DRA, особливо якщо ви не використовували ці API раніше. Якщо ви налаштували новий кластер для цього посібника, без встановленого драйвера та ще не задоволених заявок Pod, вивід цих команд не покаже жодних ресурсів.
Отримайте список DeviceClasses:
kubectl get deviceclassesВивід буде схожий на цей:
No resources foundОтримайте список ResourceSlices:
kubectl get resourceslicesВивід буде схожий на цей:
No resources foundОтримайте список ResourceClaims та ResourceClaimTemplates
kubectl get resourceclaims -A kubectl get resourceclaimtemplates -AВивід буде схожий на цей:
No resources found No resources found
На даний момент ви підтвердили, що DRA увімкнено та налаштовано правильно в кластері, і що жоден драйвер DRA ще не оголосив жодних ресурсів API DRA.
Встановлення демонстраційного драйвера DRA
Драйвери DRA — це сторонні програми, які працюють на кожному вузлі вашого кластера, щоб взаємодіяти з апаратним забезпеченням цього вузла та вбудованими компонентами DRA Kubernetes. Процедура встановлення залежить від вибраного вами драйвера, але, ймовірно, розгортається як DaemonSet на всіх або вибраних вузлах (з використанням selectors або подібних механізмів) у вашому кластері.
Перевірте документацію вашого драйвера на наявність конкретних інструкцій щодо встановлення, які можуть включати чарт Helm, набір маніфестів або інші інструменти розгортання.
Цей посібник використовує приклад драйвера, який можна знайти в репозиторії kubernetes-sigs/dra-example-driver, щоб продемонструвати встановлення драйвера. Цей приклад драйвера оголошує симульовані GPU для Kubernetes, з якими можуть взаємодіяти ваші Podʼи.
Підготовка кластера до встановлення драйвера
Щоб спростити очищення, створіть простір імен з назвою dra-tutorial:
Створіть простір імен:
kubectl create namespace dra-tutorial
У промисловому середовищі ви, напевно, використовували б раніше випущений або кваліфікований образ від постачальника драйвера або вашої організації, і ваші вузли повинні мати доступ до реєстру образів, де зберігається образ драйвера. У цьому навчальному посібнику ви будете використовувати публічно випущений образ dra-example-driver, щоб змоделювати доступ до образу драйвера DRA.
Підтвердіть, що ваші вузли мають доступ до образу, виконавши наступну команду зсередини одного з вузлів вашого кластера:
docker pull registry.k8s.io/dra-example-driver/dra-example-driver:v0.2.0
Розгортання компонентів драйвера DRA
Для цього навчального посібника ви встановите критично важливі компоненти демонстраційного драйвера ресурсів окремо за допомогою kubectl.
Створіть DeviceClass, що представляє типи пристроїв, які підтримує цей драйвер DRA:
apiVersion: resource.k8s.io/v1 kind: DeviceClass metadata: name: gpu.example.com spec: selectors: - cel: expression: "device.driver == 'gpu.example.com'"kubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/deviceclass.yamlСтворіть службовий обліковий запис, кластерну роль і привʼязку кластерної ролі, які будуть використовуватися драйвером для отримання дозволів на взаємодію з Kubernetes API в цьому кластері:
Створіть Service Account:
apiVersion: v1 kind: ServiceAccount metadata: name: dra-example-driver-service-account namespace: dra-tutorial labels: app.kubernetes.io/name: dra-example-driver app.kubernetes.io/instance: dra-example-driverkubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/serviceaccount.yamlСтворіть ClusterRole:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: dra-example-driver-role rules: - apiGroups: ["resource.k8s.io"] resources: ["resourceclaims"] verbs: ["get"] - apiGroups: [""] resources: ["nodes"] verbs: ["get"] - apiGroups: ["resource.k8s.io"] resources: ["resourceslices"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]kubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/clusterrole.yamlСтворіть ClusterRoleBinding:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: dra-example-driver-role-binding subjects: - kind: ServiceAccount name: dra-example-driver-service-account namespace: dra-tutorial roleRef: kind: ClusterRole name: dra-example-driver-role apiGroup: rbac.authorization.k8s.iokubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/clusterrolebinding.yaml
Створіть PriorityClass для DRA драйвера. PriorityClass запобігає витісненню компонента драйвера DRA, який відповідає за важливі операції життєвого циклу для Podʼів з заявками. Дізнайтеся більше про пріоритет Podʼів та виселення тут.
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: dra-driver-high-priority value: 1000000 globalDefault: false description: "This priority class should be used for DRA driver pods only."kubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/priorityclass.yamlРозгорніть фактичний драйвер DRA як DaemonSet, налаштований на запуск прикладу двійкового файлу драйвера з вищезазначеними дозволами.
apiVersion: apps/v1 kind: DaemonSet metadata: name: dra-example-driver-kubeletplugin namespace: dra-tutorial labels: app.kubernetes.io/name: dra-example-driver spec: selector: matchLabels: app.kubernetes.io/name: dra-example-driver updateStrategy: type: RollingUpdate template: metadata: labels: app.kubernetes.io/name: dra-example-driver spec: priorityClassName: dra-driver-high-priority serviceAccountName: dra-example-driver-service-account securityContext: {} containers: - name: plugin securityContext: privileged: true image: registry.k8s.io/dra-example-driver/dra-example-driver:v0.2.0 imagePullPolicy: IfNotPresent command: ["dra-example-kubeletplugin"] resources: {} # Драйвери для промислового використання повинні завжди надавати пробу життєздатності # Для цього прикладу ми просто пропускаємо її. # livenessProbe: # grpc: # port: 51515 # service: liveness # failureThreshold: 3 # periodSeconds: 10 env: - name: CDI_ROOT value: /var/run/cdi - name: KUBELET_REGISTRAR_DIRECTORY_PATH value: "/var/lib/kubelet/plugins_registry" - name: KUBELET_PLUGINS_DIRECTORY_PATH value: "/var/lib/kubelet/plugins" - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace # Кількість пристроїв, які демонстраційний драйвер буде імітувати. - name: NUM_DEVICES value: "9" - name: HEALTHCHECK_PORT value: "51515" volumeMounts: - name: plugins-registry mountPath: "/var/lib/kubelet/plugins_registry" - name: plugins mountPath: "/var/lib/kubelet/plugins" - name: cdi mountPath: /var/run/cdi volumes: - name: plugins-registry hostPath: path: "/var/lib/kubelet/plugins_registry" - name: plugins hostPath: path: "/var/lib/kubelet/plugins" - name: cdi hostPath: path: /var/run/cdikubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/daemonset.yamlDaemonSet налаштовано з точками монтування томів, необхідними для взаємодії з підлягаючим текою Container Device Interface (CDI), і для відкриття його сокета для
kubeletчерез текуkubelet/plugins.
Перевірка встановлення драйвера DRA
Отримайте список Podʼів DaemonSet драйвера DRA на всіх робочих вузлах:
kubectl get pod -l app.kubernetes.io/name=dra-example-driver -n dra-tutorialВивід буде схожий на цей:
NAME READY STATUS RESTARTS AGE dra-example-driver-kubeletplugin-4sk2x 1/1 Running 0 13s dra-example-driver-kubeletplugin-cttr2 1/1 Running 0 13sПочаткова відповідальність локального драйвера DRA кожного вузла полягає в оновленні відомостей кластера про те, які пристрої доступні для Podʼів на цьому вузлі, публікуючи його метадані в API ResourceSlices. Ви можете перевірити цей API, щоб побачити, що кожен вузол з драйвером оголошує клас пристрою, який він представляє.
Перевірте наявність доступних ResourceSlices:
kubectl get resourceslicesВивід буде схожий на цей:
NAME NODE DRIVER POOL AGE kind-worker-gpu.example.com-k69gd kind-worker gpu.example.com kind-worker 19s kind-worker2-gpu.example.com-qdgpn kind-worker2 gpu.example.com kind-worker2 19s
На даний момент ви успішно встановили приклад драйвера DRA та підтвердили його початкову конфігурацію. Тепер ви готові використовувати DRA для планування Podʼів.
Запит ресурсів та розгортання Podʼа
Щоб запитати ресурси за допомогою DRA, ви створюєте ResourceClaims або ResourceClaimTemplates, які визначають ресурси, які потрібні вашим Podʼам. У демонстраційному драйвері для симульованих пристроїв GPU доступний атрибут ємності памʼяті. Цей розділ показує, як використовувати Загальна мова виразів для зазначення ваших вимог у ResourceClaim, вибору цього ResourceClaim у специфікації Podʼа та спостереження за виділенням ресурсів.
Цей посібник демонструє лише один базовий приклад ResourceClaim DRA. Читайте Динамічне виділення ресурсів, щоб дізнатися більше про ResourceClaims.
Створення ResourceClaim
У цьому розділі ви створюєте ResourceClaim і посилаєтеся на нього в Pod. Яким би не був запит, поле deviceClassName є обовʼязковим, звужуючи обсяг запиту до конкретного класу пристрою. Сам запит може включати вираз Загальна мова виразів, який посилається на атрибути, які можуть бути оголошені драйвером, що керує цим класом пристроїв.
У цьому прикладі ви створите запит на будь-який GPU, що оголошує понад 10Gi ємності памʼяті. Атрибут, що експонує ємність від прикладного драйвера, має форму device.capacity['gpu.example.com'].memory. Зверніть увагу, що імʼя запиту встановлено на some-gpu.
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: some-gpu
namespace: dra-tutorial
spec:
devices:
requests:
- name: some-gpu
exactly:
deviceClassName: gpu.example.com
selectors:
- cel:
expression: "device.capacity['gpu.example.com'].memory.compareTo(quantity('10Gi')) >= 0"
kubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/example/resourceclaim.yaml
Створення Pod, який посилається на цей ResourceClaim
Нижче наведено маніфест Pod, що посилається на ResourceClaim, який ви щойно створили, some-gpu, у полі spec.resourceClaims.resourceClaimName. Локальне імʼя для цього запиту, gpu, потім використовується в полі spec.containers.resources.claims.name, щоб виділити запит для підлеглого контейнера Pod.
apiVersion: v1
kind: Pod
metadata:
name: pod0
namespace: dra-tutorial
labels:
app: pod
spec:
containers:
- name: ctr0
image: ubuntu:24.04
command: ["bash", "-c"]
args: ["export; trap 'exit 0' TERM; sleep 9999 & wait"]
resources:
claims:
- name: gpu
resourceClaims:
- name: gpu
resourceClaimName: some-gpukubectl apply --server-side -f http://k8s.io/examples/dra/driver-install/example/pod.yaml
Підтвердіть, що pod розгорнуто:
kubectl get pod pod0 -n dra-tutorialВивід буде схожий на цей:
NAME READY STATUS RESTARTS AGE pod0 1/1 Running 0 9s
Дослідження стану DRA
Після створення Podʼа кластер намагається запланювати цей Pod на вузол, де Kubernetes може задовольнити ResourceClaim. У цьому навчальному посібнику драйвер DRA розгорнуто на всіх вузлах і оголошено симульовані GPU на всіх вузлах, всі з яких мають достатню оголошену ємність для задоволення заявки Podʼа, тому Kubernetes може планувати цей Pod на будь-якому вузлі та може виділити будь-який з симульованих GPU на цьому вузлі.
Коли Kubernetes виділяє симульований GPU для Pod, демонстраційний драйвер додає змінні середовища в кожен контейнер, до якого він виділений, щоб вказати, які GPU мали б бути впроваджені в них реальним драйвером ресурсів і як вони мали б бути налаштовані, тому ви можете перевірити ці змінні середовища, щоб побачити, як Podʼи оброблялися системою.
Перевірте логи Pod, які повідомляють імʼя симульованого GPU, що був виділений:
kubectl logs pod0 -c ctr0 -n dra-tutorial | grep -E "GPU_DEVICE_[0-9]+=" | grep -v "RESOURCE_CLAIM"Вивід буде схожий на цей:
declare -x GPU_DEVICE_0="gpu-0"Перевірте стан обʼєкта ResourceClaim:
kubectl get resourceclaims -n dra-tutorialВивід буде схожий на цей:
NAME STATE AGE some-gpu allocated,reserved 34sУ цьому виводі стовпець
STATEпоказує, що ResourceClaim виділено та зарезервовано.Перевірте деталі ResourceClaim
some-gpu. Виразstatusв ResourceClaim містить інформацію про виділений пристрій і Pod, для якого він був зарезервований:kubectl get resourceclaim some-gpu -n dra-tutorial -o yamlВивід буде схожий на цей:
1apiVersion: resource.k8s.io/v1 2kind: ResourceClaim 3metadata: 4 creationTimestamp: "2025-08-20T18:17:31Z" 5 finalizers: 6 - resource.kubernetes.io/delete-protection 7 name: some-gpu 8 namespace: dra-tutorial 9 resourceVersion: "2326" 10 uid: d3e48dbf-40da-47c3-a7b9-f7d54d1051c3 11spec: 12 devices: 13 requests: 14 - exactly: 15 allocationMode: ExactCount 16 count: 1 17 deviceClassName: gpu.example.com 18 selectors: 19 - cel: 20 expression: device.capacity['gpu.example.com'].memory.compareTo(quantity('10Gi')) 21 >= 0 22 name: some-gpu 23status: 24 allocation: 25 devices: 26 results: 27 - device: gpu-0 28 driver: gpu.example.com 29 pool: kind-worker 30 request: some-gpu 31 nodeSelector: 32 nodeSelectorTerms: 33 - matchFields: 34 - key: metadata.name 35 operator: In 36 values: 37 - kind-worker 38 reservedFor: 39 - name: pod0 40 resource: pods 41 uid: c4dadf20-392a-474d-a47b-ab82080c8bd7Щоб перевірити, як драйвер обробив виділення пристрою, отримайте журнали для Podʼів DaemonSet драйвера:
kubectl logs -l app.kubernetes.io/name=dra-example-driver -n dra-tutorialВивід буде схожий на цей:
I0729 05:11:52.679057 1 driver.go:84] NodePrepareResource is called: number of claims: 1 I0729 05:11:52.684450 1 driver.go:112] Returning newly prepared devices for claim '79e1e8d8-7e53-4362-aad1-eca97678339e': [&Device{RequestNames:[some-gpu],PoolName:kind-worker,DeviceName:gpu-4,CDIDeviceIDs:[k8s.gpu.example.com/gpu=common k8s.gpu.example.com/gpu=79e1e8d8-7e53-4362-aad1-eca97678339e-gpu-4],}]
Тепер ви успішно розгорнули Pod, який запитує пристрої за допомогою DRA, перевірили, що Pod було заплановано на відповідний вузол, і побачили, що повʼязані види API DRA були оновлені зі статусом виділення.
Видалення Podʼа, що має заявку
Коли Pod з заявкою видаляється, драйвер DRA деалокує ресурс, щоб він був доступний для майбутнього планування. Щоб перевірити цю поведінку, видаліть Pod, який ви створили на попередніх кроках, і спостерігайте за відповідними змінами в ResourceClaim та драйвері.
Видаліть Pod
pod0:kubectl delete pod pod0 -n dra-tutorialВивід буде схожий на цей:
pod "pod0" deleted
Спостереження за станом DRA
Коли Pod видаляється, драйвер деалокує пристрій з ResourceClaim і оновлює ресурс ResourceClaim в API Kubernetes. ResourceClaim має стан pending, поки він не буде згаданий у новому Pod.
Перевірте стан ResourceClaim
some-gpu:kubectl get resourceclaims -n dra-tutorialВивід буде схожий на цей:
NAME STATE AGE some-gpu pending 76sПеревірте, що драйвер обробив скасування підготовки пристрою для цього запиту, перевіривши журнали драйвера:
kubectl logs -l app.kubernetes.io/name=dra-example-driver -n dra-tutorialВивід буде схожий на цей:
I0820 18:22:15.629376 1 driver.go:138] UnprepareResourceClaims is called: number of claims: 1
Тепер ви видалили Pod, який мав заявку, і спостерігали, що драйвер вживав заходів для скасування підготовки підлягаючого апаратного ресурсу та оновлення API DRA, щоб відобразити, що ресурс знову доступний для майбутнього планування.
Очищення
Щоб очистити ресурси, які ви створили в цьому навчальному посібнику, виконайте ці кроки:
kubectl delete namespace dra-tutorial
kubectl delete deviceclass gpu.example.com
kubectl delete clusterrole dra-example-driver-role
kubectl delete clusterrolebinding dra-example-driver-role-binding
kubectl delete priorityclass dra-driver-high-priority