1 - Привіт Minikube
З цього навчального матеріалу ви дізнаєтесь, як запустити у Kubernetes простий Hello World застосунок на Node.js за допомогою Minikube і Katacoda. Katacoda надає безплатне Kubernetes середовище, що доступне у вашому браузері.
Примітка:
Також ви можете навчатись за цим матеріалом, якщо встановили
Minikube локально.
Цілі
- Розгорнути Hello World застосунок у Minikube.
- Переглянути логи застосунку.
Перш ніж ви розпочнете
У цьому навчальному матеріалі ми використовуємо образ контейнера, зібраний із наступних файлів:
var http = require('http');
var handleRequest = function(request, response) {
console.log('Received request for URL: ' + request.url);
response.writeHead(200);
response.end('Hello World!');
};
var www = http.createServer(handleRequest);
www.listen(8080);
FROM node:6.14.2
EXPOSE 8080
COPY server.js .
CMD [ "node", "server.js" ]
Більше інформації про команду docker build ви знайдете у документації Docker.
Створення Minikube кластера
-
Натисніть кнопку Запуск термінала
Примітка:
Якщо Minikube встановлений локально, виконайте команду minikube start.
-
Відкрийте Kubernetes дашборд у браузері:
- Тільки для Katacoda: у верхній частині вікна термінала натисніть знак плюс, а потім -- Select port to view on Host 1.
- Тільки для Katacoda: введіть
30000, а потім натисніть Display Port.
Створення Deployment
Pod у Kubernetes -- це група з одного або декількох контейнерів, що об'єднані разом з метою адміністрування і роботи у мережі. У цьому навчальному матеріалі Pod має лише один контейнер. Kubernetes Deployment перевіряє стан Pod'а і перезапускає контейнер Pod'а, якщо контейнер перестає працювати. Створювати і масштабувати Pod'и рекомендується за допомогою Deployment'ів.
-
За допомогою команди kubectl create створіть Deployment, який керуватиме Pod'ом. Pod запускає контейнер на основі наданого Docker образу.
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
-
Перегляньте інформацію про запущений Deployment:
У виводі ви побачите подібну інформацію:
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
-
Перегляньте інформацію про запущені Pod'и:
У виводі ви побачите подібну інформацію:
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
-
Перегляньте події кластера:
-
Перегляньте конфігурацію kubectl:
Створення Service
За умовчанням, Pod доступний лише за внутрішньою IP-адресою у межах Kubernetes кластера. Для того, щоб контейнер hello-node став доступний за межами віртуальної мережі Kubernetes, Pod необхідно відкрити як Kubernetes Service.
-
Відкрийте Pod для публічного доступу з інтернету за допомогою команди kubectl expose:
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
Прапорець `--type=LoadBalancer` вказує, що ви хочете відкрити доступ до Service за межами кластера.
-
Перегляньте інформацію про Service, який ви щойно створили:
У виводі ви побачите подібну інформацію:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
Для хмарних провайдерів, що підтримують балансування навантаження, доступ до Service надається через зовнішню IP-адресу. Для Minikube, тип `LoadBalancer` робить Service доступним ззовні за допомогою команди `minikube service`.
-
Виконайте наступну команду:
minikube service hello-node
- Тільки для Katacoda: натисніть знак плюс, а потім -- Select port to view on Host 1.
-
Тільки для Katacoda: запишіть п'ятизначний номер порту, що відображається напроти 8080 у виводі сервісу. Номер цього порту генерується довільно і тому може бути іншим у вашому випадку. Введіть номер порту у призначене для цього текстове поле і натисніть Display Port. У нашому прикладі номер порту 30369.
Це відкриє вікно браузера, в якому запущений ваш застосунок, і покаже повідомлення "Hello World".
Увімкнення розширень
Minikube має ряд вбудованих розширень, які можна увімкнути, вимкнути і відкрити у локальному Kubernetes оточенні.
-
Перегляньте перелік підтримуваних розширень:
У виводі ви побачите подібну інформацію:
addon-manager: enabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
-
Увімкніть розширення, наприклад metrics-server:
minikube addons enable metrics-server
У виводі ви побачите подібну інформацію:
metrics-server was successfully enabled
-
Перегляньте інформацію про Pod і Service, які ви щойно створили:
kubectl get pod,svc -n kube-system
У виводі ви побачите подібну інформацію:
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
-
Вимкніть metrics-server:
minikube addons disable metrics-server
У виводі ви побачите подібну інформацію:
metrics-server was successfully disabled
Вивільнення ресурсів
Тепер ви можете видалити ресурси, які створили у вашому кластері:
kubectl delete service hello-node
kubectl delete deployment hello-node
За бажанням, зупиніть віртуальну машину (ВМ) з Minikube:
За бажанням, видаліть ВМ з Minikube:
Що далі
9 - Встановлення драйверів та виділення пристроїв з DRA
СТАН ФУНКЦІОНАЛУ:
GA since Kubernetes v1.35
More information about this feature
This is a stable feature in Kubernetes, and has been since version v1.35. It was first available in the v1.30 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate DynamicResourceAllocation, Kubernetes ignores it but does not report any error.
Цей посібник показує, як встановити драйвери динамічного виділення ресурсів (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. Ви можете спробувати цей посібник з кластером, який використовує інший механізм авторизації, але в цьому випадку вам доведеться адаптувати кроки щодо визначення ролей і дозволів.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Цей посібник був протестований з вузлами Linux, хоча він також може працювати з іншими типами вузлів.
Версія вашого Kubernetes сервера має бути не старішою ніж v1.34.
Для перевірки версії введіть kubectl version.
Якщо ваш кластер наразі не працює під управлінням Kubernetes 1.37, перегляньте документацію щодо версії 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 на всіх або вибраних вузлах (з використанням селекторів або подібних механізмів) у вашому кластері.
Перевірте документацію вашого драйвера на наявність конкретних інструкцій щодо встановлення, які можуть включати чарт Helm, набір маніфестів або інші інструменти розгортання.
Цей посібник використовує приклад драйвера, який можна знайти в репозиторії kubernetes-sigs/dra-example-driver, щоб продемонструвати встановлення драйвера. Цей приклад драйвера оголошує для Kubernetes симульовані GPU, з якими можуть взаємодіяти ваші 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 https://k8s.io/examples/dra/driver-install/deviceclass.yaml
-
Створіть ServiceAccount, ClusterRole та ClusterRoleBinding, які будуть використовуватися драйвером для отримання дозволів на взаємодію з API Kubernetes в цьому кластері:
-
Створіть 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-driver
kubectl apply --server-side -f https://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 https://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.io
kubectl apply --server-side -f https://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 https://k8s.io/examples/dra/driver-install/priorityclass.yaml
-
Розгорніть фактичний драйвер DRA як DaemonSet, налаштований на запуск двійкового файлу демонстраційного драйвера з наданими вище дозволами. DaemonSet має дозволи, які ви надали ServiceAccount на попередніх кроках.
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:
{}
# Production drivers should always implement a liveness probe
# For the tutorial we simply omit it
# 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
# Simulated number of devices the example driver will pretend to have.
- 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/cdi
kubectl apply --server-side -f https://k8s.io/examples/dra/driver-install/daemonset.yaml
DaemonSet налаштовано з точками монтування томів, необхідними для взаємодії з базовою текою 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 доступний атрибут ємності памʼяті. Цей розділ показує, як використовувати Common Expression Language для зазначення ваших вимог у ResourceClaim, вибрати цей ResourceClaim у специфікації Podʼа та спостерігати за виділенням ресурсів.
Цей посібник демонструє лише один базовий приклад ResourceClaim DRA. Прочитайте Динамічне виділення ресурсів, щоб дізнатися більше про ResourceClaims.
Створення ResourceClaim
У цьому розділі ви створюєте ResourceClaim і посилаєтеся на нього в Podʼі. Якою б не була заявка, поле deviceClassName є обовʼязковим, воно звужує обсяг запиту до конкретного класу пристроїв. Сам запит може включати вираз Common Expression Language, який посилається на атрибути, які можуть бути оголошені драйвером, що керує цим класом пристроїв.
У цьому прикладі ви створите запит на будь-який 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 https://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-gpu
kubectl apply --server-side -f https://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
Вивід буде схожий на цей:
I0820 18:17:44.131324 1 driver.go:106] PrepareResourceClaims is called: number of claims: 1
I0820 18:17:44.135056 1 driver.go:133] Returning newly prepared devices for claim 'd3e48dbf-40da-47c3-a7b9-f7d54d1051c3': [{[some-gpu] kind-worker gpu-0 [k8s.gpu.example.com/gpu=common k8s.gpu.example.com/gpu=d3e48dbf-40da-47c3-a7b9-f7d54d1051c3-gpu-0]}]
Тепер ви успішно розгорнули 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
Що далі
