← До списку лабораторних по Kubernetes
Повний опис / сценарій лабораторної:
Мета: навчитися використовувати nodeAffinity щоб направляти pod на потрібні ноди. Крок 1. Додати labels до групи нод. Команда: kubectl label node <імя-ноди-1> env=prod; kubectl label node <імя-ноди-2> env=stage Пояснення: так ми розділяємо ноди за середовищами. Крок 2. Згенерувати yaml deployment. Команда: kubectl create deployment node-aff-demo --image=nginx --replicas=3 -o yaml --dry-run=client > node-aff-demo.yaml Пояснення: далі додамо до нього nodeAffinity. Крок 3. Додати requiredDuringScheduling nodeAffinity. Дія: у spec template spec додай nodeAffinity з вимогою env=prod. Пояснення: pod мають запускатися тільки на нодах з env=prod. Крок 4. Застосувати deployment. Команда: kubectl apply -f node-aff-demo.yaml Пояснення: scheduler перевіряє labels нод при розміщенні pod. Крок 5. Перевірити розміщення pod. Команда: kubectl get pods -l app=node-aff-demo -o wide Пояснення: дивись щоб всі pod були на нодах з env=prod. Крок 6. Змінити правило на preferredDuringScheduling. Дія: заміни required на preferred зі певною weight і дозволи fallback на інші ноди. Пояснення: тепер scheduler намагається але не зобовязаний ставити pod на prod ноди. Крок 7. Оновити deployment. Команда: kubectl apply -f node-aff-demo.yaml Пояснення: при нестачі ресурсів pod можуть опинитися і на інших нодах. Крок 8. Штучно перевищити ресурси на env=prod нодах. Пояснення: створивши додаткові pod можна змусити scheduler розмістити частину replica на інших нодах. Крок 9. Знову перевірити розподіл pod. Команда: kubectl get pods -l app=node-aff-demo -o wide Пояснення: порівняй з попереднім станом і зафіксуй відмінності. Крок 10. Міні звіт. Завдання: опиши коли варто використовувати required а коли preferred node affinity.