Модуль 2.3: Оркестрація зберігання

Складність: [СЕРЕДНІЙ] - Концепції зберігання

Час на виконання: 25-30 хвилин

Передумови: Модуль 2.2 (Масштабування)

Що ви зможете робити

Після завершення цього модуля ви зможете:

Пояснити взаємозв’язок між Volume, PersistentVolume, PersistentVolumeClaim та StorageClass
Порівняти режими доступу (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) та їхні варіанти використання
Визначити коли використовувати ефемерне або постійне сховище для різних типів навантажень
Оцінити драйвери CSI та їхню роль у забезпеченні підключних бекендів зберігання

Чому цей модуль важливий

Контейнери ефемерні — коли вони перезапускаються, дані втрачаються. Kubernetes надає абстракції зберігання, які дозволяють застосункам зі станом зберігати дані при перезапусках та переплануванні Подів. KCNA перевіряє ваше розуміння того, як Kubernetes керує зберіганням.

Огляд концепцій зберігання

┌─────────────────────────────────────────────────────────────┐
│              МОДЕЛЬ ЗБЕРІГАННЯ KUBERNETES                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Три ключові ресурси:                                      │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  PersistentVolume (PV)                              │   │
│  │  • Фактичний ресурс зберігання                     │   │
│  │  • Забезпечується адміністратором АБО динамічно    │   │
│  │  • Ресурс на рівні кластера                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↑                                   │
│                         │ прив'язується до                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  PersistentVolumeClaim (PVC)                        │   │
│  │  • Запит на зберігання                              │   │
│  │  • Створюється користувачами/застосунками           │   │
│  │  • Ресурс на рівні простору імен                   │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ↑                                   │
│                         │ використовується                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Pod                                                │   │
│  │  • Монтує PVC як том                               │   │
│  │  • Читає/записує до сховища                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

PersistentVolume (PV)

PersistentVolume — це частина зберігання у кластері:

Ключові атрибути:

capacity: Скільки зберігання (напр., 10Gi)
accessModes: Як можна отримати доступ

Режими доступу:

ReadWriteOnce (RWO): Один вузол може монтувати для читання-запису
ReadOnlyMany (ROX): Багато вузлів можуть монтувати тільки для читання
ReadWriteMany (RWX): Багато вузлів можуть монтувати для читання-запису

Політики повернення:

Retain: Зберегти дані після видалення PVC (ручне очищення)
Delete: Видалити зберігання при видаленні PVC
Recycle: (Застаріла) Базове очищення та повторне використання

StorageClass

StorageClass забезпечує динамічне забезпечення:

┌─────────────────────────────────────────────────────────────┐
│              СТАТИЧНЕ проти ДИНАМІЧНОГО                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  СТАТИЧНЕ ЗАБЕЗПЕЧЕННЯ:                                    │
│  1. Адміністратор створює PV вручну                       │
│  2. Користувач створює PVC                                 │
│  3. PVC прив'язується до існуючого PV                     │
│                                                             │
│  Плюси: Повний контроль, попередній розподіл              │
│  Мінуси: Адмін повинен створювати PV заздалегідь          │
│                                                             │
│  ДИНАМІЧНЕ ЗАБЕЗПЕЧЕННЯ:                                   │
│  1. Адміністратор створює StorageClass один раз            │
│  2. Користувач створює PVC з посиланням на StorageClass   │
│  3. PV створюється автоматично!                           │
│                                                             │
│  Плюси: Самообслуговування, на вимогу, ефективне          │
│  Мінуси: Потребує хмарного провайдера або системи зберіг. │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Типи томів

Тип	Опис	Постійний
emptyDir	Тимчасовий каталог, видаляється з Подом	Ні
hostPath	Монтування з файлової системи вузла	Специфічний для вузла
persistentVolumeClaim	Використання PVC для зберігання	Так
configMap	Монтування ConfigMap як файлів	Ні
secret	Монтування Secret як файлів	Ні
nfs	Network File System	Так
awsElasticBlockStore	Том AWS EBS	Так
gcePersistentDisk	Постійний диск GCP	Так
azureDisk	Керований диск Azure	Так

Чи знали ви?

Прив’язка томів - Kubernetes прив’язує PV до PVC тільки коли Под фактично потребує його (режим WaitForFirstConsumer). Це забезпечує забезпечення зберігання в тій же зоні, що й Под.
StorageClass має область кластера - На відміну від PVC (область простору імен), StorageClasses доступні всім просторам імен.
emptyDir переживає перезапуски контейнерів - Дані в emptyDir втрачаються тільки при видаленні Пода, а не при перезапуску контейнера.
CSI — це стандарт - Container Storage Interface (CSI) — це сучасний спосіб інтеграції систем зберігання з Kubernetes. Старі вбудовані плагіни томів мігрують на CSI.

Типові помилки

Помилка	Чому це шкодить	Правильне розуміння
emptyDir для постійних даних	Дані втрачаються при видаленні Пода	Використовуйте PVC для постійних даних
Очікування RWX скрізь	Не все зберігання підтримує	Перевіряйте можливості зберігання
Забування політики повернення	Можна випадково видалити дані	Встановіть Retain для важливих даних
Статичне забезпечення у масштабі	Забагато роботи адміністратора	Використовуйте динамічне забезпечення

Вікторина

Яка різниця між PV та PVC?

Відповідь
PV (PersistentVolume) — це фактичний ресурс зберігання у кластері. PVC (PersistentVolumeClaim) — це запит на зберігання від користувача/застосунку. PVC прив'язується до відповідного PV для отримання фактичного зберігання.
Що означає ReadWriteOnce (RWO)?

Відповідь
Том може бути змонтований для читання-запису одним вузлом. Кілька Подів на тому ж вузлі можуть його спільно використовувати, але Поди на інших вузлах — ні.
Що таке динамічне забезпечення?

Відповідь
Коли PVC посилається на StorageClass, Kubernetes автоматично створює PV для задоволення запиту. Адміністратору не потрібно попередньо створювати PV — вони створюються на вимогу.
Що відбувається з даними при видаленні PVC з політикою Retain?

Відповідь
PV переходить у стан "Released", але дані зберігаються. Адміністратор повинен вручну очистити PV та дані. Це захищає від випадкової втрати даних.
Чому використовувати StorageClass замість попереднього створення PV?

Відповідь
StorageClass забезпечує самообслуговування зберігання: користувачі можуть створювати PVC без втручання адміністратора. Це ефективніше (немає марнування попередньо розподіленого зберігання) та краще масштабується.

Підсумок

Ресурси зберігання:

PersistentVolume (PV): Фактичне зберігання
PersistentVolumeClaim (PVC): Запит на зберігання
StorageClass: Забезпечує динамічне забезпечення

Режими доступу:

RWO: Один вузол читання-запис
ROX: Багато вузлів тільки читання
RWX: Багато вузлів читання-запис

Забезпечення:

Статичне: Адміністратор створює PV вручну
Динамічне: PV створюються автоматично через StorageClass

Політики повернення:

Retain: Зберегти дані після видалення PVC
Delete: Видалити зберігання при видаленні PVC

Наступний модуль

Модуль 2.4: Конфігурація - Керування конфігурацією застосунків за допомогою ConfigMaps та Secrets.