Модуль 1.6: Ресурси навантажень
Складність:
[СЕРЕДНІЙ]- Основні концепції ресурсівЧас на виконання: 30-35 хвилин
Передумови: Модуль 1.5 (Поди)
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Порівняти Deployment, ReplicaSet, DaemonSet, StatefulSet та Job за варіантами використання
- Визначити який ресурс навантаження використовувати для даного сценарію застосунку
- Пояснити як Deployment керує поступовими оновленнями та відкатами через ReplicaSet
- Оцінити взаємозв’язок між контролерами та Pod, якими вони керують
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Ви рідко створюєте Поди напряму — ви використовуєте ресурси навантажень, які керують Подами за вас. Розуміння Deployments, ReplicaSets, DaemonSets та інших контролерів є важливим для KCNA.
Ієрархія ресурсів навантажень
Розділ «Ієрархія ресурсів навантажень»┌─────────────────────────────────────────────────────────────┐│ ІЄРАРХІЯ РЕСУРСІВ НАВАНТАЖЕНЬ │├─────────────────────────────────────────────────────────────┤│ ││ Ви створюєте: Deployment ││ │ ││ │ створює та керує ││ ▼ ││ Авто-створений: ReplicaSet ││ │ ││ │ створює та керує ││ ▼ ││ Авто-створені: Под Под Под ││ ││ Чому ця ієрархія? ││ ───────────────────────────────────────────────────────── ││ • Deployment: Обробляє оновлення та відкати ││ • ReplicaSet: Підтримує бажану кількість Подів ││ • Под: Запускає фактичні контейнери ││ │└─────────────────────────────────────────────────────────────┘Deployments
Розділ «Deployments»Deployment — найпоширеніший спосіб запуску застосунків:
┌─────────────────────────────────────────────────────────────┐│ DEPLOYMENT │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Декларативно керує ReplicaSets та Подами ││ • Забезпечує послідовні оновлення ││ • Підтримує відкати ││ • Масштабує застосунки вгору/вниз ││ ││ Коли використовувати: Застосунки без стану ││ │└─────────────────────────────────────────────────────────────┘Послідовні оновлення
Розділ «Послідовні оновлення»┌─────────────────────────────────────────────────────────────┐│ ПОСЛІДОВНЕ ОНОВЛЕННЯ │├─────────────────────────────────────────────────────────────┤│ ││ Оновлення з nginx:1.25 до nginx:1.26: ││ ││ Крок 1: Створення нового ReplicaSet ││ ┌─────────────────────────────────────────────────────┐ ││ │ Старий RS (nginx:1.25): ●●● (3 поди) │ ││ │ Новий RS (nginx:1.26): ○ (1 под запускається) │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Крок 2: Збільшення нового, зменшення старого ││ ┌─────────────────────────────────────────────────────┐ ││ │ Старий RS (nginx:1.25): ●● (2 поди) │ ││ │ Новий RS (nginx:1.26): ○○ (2 поди) │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Крок 3: Завершення ││ ┌─────────────────────────────────────────────────────┐ ││ │ Старий RS (nginx:1.25): (0 подів, збережений │ ││ │ для відкату) │ ││ │ Новий RS (nginx:1.26): ○○○ (3 поди) │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Переваги: ││ • Нульовий простій ││ • Поступове розгортання ││ • Автоматичний відкат при збої ││ │└─────────────────────────────────────────────────────────────┘ReplicaSets
Розділ «ReplicaSets»ReplicaSet підтримує стабільний набір реплік Подів:
┌─────────────────────────────────────────────────────────────┐│ REPLICASET │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Забезпечує вказану кількість працюючих Подів ││ • Створює нові Поди, якщо їх замало ││ • Видаляє Поди, якщо їх забагато ││ • Використовує мітки для ідентифікації своїх Подів ││ ││ Важливо: ││ ───────────────────────────────────────────────────────── ││ Ви рідко створюєте ReplicaSets напряму! ││ Використовуйте Deployments — вони керують ReplicaSets. ││ │└─────────────────────────────────────────────────────────────┘StatefulSets
Розділ «StatefulSets»Для застосунків зі станом, які потребують стабільних ідентифікаторів:
┌─────────────────────────────────────────────────────────────┐│ STATEFULSET │├─────────────────────────────────────────────────────────────┤│ ││ Що забезпечує: ││ ───────────────────────────────────────────────────────── ││ • Стабільні, унікальні мережеві ідентифікатори ││ • Стабільне, постійне сховище ││ • Впорядковане, плавне розгортання та масштабування ││ • Впорядковане, плавне видалення та завершення ││ ││ Приклад: Кластер бази даних ││ ───────────────────────────────────────────────────────── ││ ┌─────────────────────────────────────────────────────┐ ││ │ StatefulSet: mysql │ ││ │ │ ││ │ mysql-0 ──→ PVC: mysql-data-0 (10ГБ) │ ││ │ mysql-1 ──→ PVC: mysql-data-1 (10ГБ) │ ││ │ mysql-2 ──→ PVC: mysql-data-2 (10ГБ) │ ││ │ │ ││ │ DNS: mysql-0.mysql.default.svc.cluster.local │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Ключові відмінності від Deployment: ││ • Поди отримують постійні імена (mysql-0, mysql-1) ││ • Кожен Под отримує власний PVC ││ • Створюються по порядку (0, потім 1, потім 2) ││ ││ Коли використовувати: Бази даних, кластерні застосунки, ││ впорядкований запуск ││ │└─────────────────────────────────────────────────────────────┘DaemonSets
Розділ «DaemonSets»Для запуску Пода на кожному вузлі:
┌─────────────────────────────────────────────────────────────┐│ DAEMONSET │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ ───────────────────────────────────────────────────────── ││ • Запускає один Под на кожному вузлі ││ • Автоматично додає Под при приєднанні нового вузла ││ • Видаляє Под при вилученні вузла ││ ││ Типові випадки використання: ││ • Збирачі логів (Fluentd, Fluent Bit) ││ • Агенти моніторингу (Prometheus Node Exporter) ││ • Мережеві плагіни (CNI) ││ • Драйвери сховищ ││ │└─────────────────────────────────────────────────────────────┘Jobs та CronJobs
Розділ «Jobs та CronJobs»Для пакетних та запланованих навантажень:
┌─────────────────────────────────────────────────────────────┐│ JOB │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ • Створює Поди, що працюють до завершення ││ • Повторює спроби при збої Пода ││ • Відстежує успішні завершення ││ ││ Приклад: Резервне копіювання бази даних ││ Job "backup" → Створює Под → Под виконує резервне ││ копіювання → Завершується ││ │└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐│ CRONJOB │├─────────────────────────────────────────────────────────────┤│ ││ Що він робить: ││ • Створює Jobs за розкладом ││ • Використовує синтаксис cron ││ ││ Приклад: Нічне резервне копіювання ││ schedule: "0 2 * * *" # Кожного дня о 2:00 ││ │└─────────────────────────────────────────────────────────────┘Порівняння ресурсів навантажень
Розділ «Порівняння ресурсів навантажень»| Ресурс | Призначення | Ідентифікація Подів | Репліки |
|---|---|---|---|
| Deployment | Застосунки без стану | Випадкові імена | Змінна |
| ReplicaSet | Підтримка кількості | Випадкові імена | Фіксована |
| StatefulSet | Застосунки зі станом | Стабільні імена | Впорядковані |
| DaemonSet | Агент на вузлі | По вузлу | Один на вузол |
| Job | Виконання до завершення | Тимчасові | До завершення |
| CronJob | Заплановані Jobs | Тимчасові | За розкладом |
Коли що використовувати?
Розділ «Коли що використовувати?»┌─────────────────────────────────────────────────────────────┐│ ВИБІР РЕСУРСУ НАВАНТАЖЕННЯ │├─────────────────────────────────────────────────────────────┤│ ││ Це одноразове завдання? ││ └─→ ТАК: Job ││ ││ Потрібно запускати за розкладом? ││ └─→ ТАК: CronJob ││ ││ Потрібно запускати на кожному вузлі? ││ └─→ ТАК: DaemonSet ││ ││ Потрібна стабільна ідентифікація та сховище? ││ └─→ ТАК: StatefulSet ││ ││ Це застосунок без стану? ││ └─→ ТАК: Deployment (найпоширеніший!) ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
Deployments зберігають старі ReplicaSets - За замовчуванням Kubernetes зберігає 10 старих ReplicaSets для можливості відкату. Це налаштовується.
-
Поди StatefulSet створюються послідовно - Pod-0 повинен працювати перед створенням Pod-1. Це забезпечує впорядкований запуск.
-
DaemonSets обходять планувальник - Спочатку DaemonSets розміщували Поди напряму. Тепер вони використовують планувальник за замовчуванням.
-
Часовий пояс CronJob - Це часовий пояс менеджера контролерів. Будьте обережні з часовими поясами при плануванні CronJobs.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це шкодить | Правильне розуміння |
|---|---|---|
| Створення ReplicaSets напряму | Втрата функцій оновлення | Використовуйте Deployments |
| Deployment для баз даних | Втрата даних при переплануванні | Використовуйте StatefulSet |
| Ручне масштабування | Немає автоматизації | Використовуйте HPA або задайте replicas |
| Ігнорування збоїв Job | Тихі помилки | Перевіряйте completions та status |
Вікторина
Розділ «Вікторина»-
Який ресурс навантаження керує ReplicaSets?
Відповідь
Deployment. Коли ви створюєте Deployment, він створює та керує ReplicaSets, які в свою чергу створюють та керують Подами. -
Чим StatefulSet відрізняється від Deployment?
Відповідь
StatefulSet забезпечує стабільну, постійну ідентифікацію (імена Подів як mysql-0), стабільне сховище (кожен Под отримує власний PVC) та впорядковане розгортання/масштабування. Поди Deployment мають випадкові імена та спільне сховище. -
Коли б ви використали DaemonSet?
Відповідь
Коли потрібно рівно один Под на кожному вузлі (або підмножині вузлів). Типові випадки: збирачі логів, агенти моніторингу, мережеві плагіни. -
Яка різниця між Job та Deployment?
Відповідь
Job запускає Поди до завершення (кінцеві завдання як резервне копіювання). Deployment запускає Поди безперервно (тривалі сервіси). Jobs завершуються; Deployments продовжують працювати. -
Що робить ReplicaSet?
Відповідь
ReplicaSet забезпечує, що вказана кількість ідентичних Подів працює постійно. Якщо Поди падають, він створює нові. Якщо їх забагато, він видаляє деякі.
Підсумок
Розділ «Підсумок»Ресурси навантажень керують Подами:
| Ресурс | Випадок використання |
|---|---|
| Deployment | Застосунки без стану (веб-сервери, API) |
| StatefulSet | Застосунки зі станом (бази даних, кеші) |
| DaemonSet | Агенти на вузлі (логування, моніторинг) |
| Job | Одноразові завдання (резервні копії, міграції) |
| CronJob | Заплановані завдання (нічні задачі) |
Ключова ієрархія:
- Deployment → ReplicaSet → Поди
- Ви створюєте Deployment
- K8s створює решту
Найкраща практика: Майже ніколи не створюйте Поди або ReplicaSets напряму. Використовуйте ресурси вищого рівня.
Наступний модуль
Розділ «Наступний модуль»Модуль 1.7: Сервіси - Як Поди доступні та виявляються всередині та зовні кластера.