Перейти до вмісту

Модуль 5.4: Сховища та управління даними в EKS

Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Модуль 5.1 (Архітектура та Control Plane EKS)

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

Розділ «Чому цей модуль важливий»

У червні 2023 року компанія з розробки рекламних технологій вирішила зекономити і перенесла свою базу даних PostgreSQL з керованого сервісу RDS прямо у кластер EKS як StatefulSet. Все працювало чудово, доки не настав час планового оновлення серверів кластера. Kubernetes переніс под бази даних на інший сервер у сусідній зоні доступності (AZ). Под запустився, але диск EBS не зміг підключитися. Проблема в тому, що диски EBS фізично прив’язані до однієї AZ. База даних “зависла” в очікуванні на 18 хвилин, поки інженер зрозумів, що сталося. Протягом цього часу компанія втрачала по $19 000 за кожну хвилину простою.

Сховища в Kubernetes — це сфера, де легко припуститися помилок, які проявляються тільки під час збоїв. У світі звичайних серверів ви просто підключаєте диск і забуваєте про нього. В Kubernetes поди постійно “переїжджають” між вузлами та зонами. Якщо ваша архітектура сховищ не враховує ці обмеження, ваша “висока доступність” — це лише ілюзія.

У цьому модулі ви навчитеся використовувати EBS CSI драйвер для швидких дисків gp3, опануєте EFS для спільного доступу до файлів між багатьма подами одночасно, навчитеся підключати S3 бакети як звичайні папки та дізнаєтеся, як проєктувати StatefulSets так, щоб вони виживали при падінні цілих дата-центрів.


EBS CSI Driver: Блочне сховище (RWO)

Розділ «EBS CSI Driver: Блочне сховище (RWO)»

Amazon Elastic Block Store (EBS) — це стандартний “жорсткий диск” для ваших подів.

Важливі налаштування StorageClass

Розділ «Важливі налаштування StorageClass»

Для EKS критично важливо використовувати параметр volumeBindingMode: WaitForFirstConsumer.

  • Чому: Це змушує Kubernetes спочатку обрати сервер для пода, а вже потім створювати диск у тій же самій зоні доступності (AZ). Без цього ви гарантовано отримаєте помилку підключення диска.

Переваги дисків gp3:

Розділ «Переваги дисків gp3:»
  • Ціна: на 20% дешевше за старий gp2.
  • Швидкість: ви отримуєте 3000 IOPS безкоштовно навіть для найменшого диска в 1 ГБ.
  • Гнучкість: можна збільшувати розмір диска “на льоту” без зупинки бази даних.

EFS: Спільна файлова система (RWX)

Розділ «EFS: Спільна файлова система (RWX)»

Диски EBS мають обмеження: один диск — один сервер. Якщо вам потрібно, щоб 10 подів на 5 різних серверах читали і писали в одну папку (напр. завантажені фото користувачів), вам потрібен Amazon EFS.

ФункціяEBS (gp3)EFS
ДоступОдин под за раз (RWO)Багато подів одночасно (RWX)
Область діїОдна зона (AZ)Весь регіон (Multi-AZ)
ШвидкістьДуже швидка (БД)Повільніша (Файли)
ЦінаФіксована за ГБЗа обсяг та трафік

Mountpoint for S3: Бакет як диск

Розділ «Mountpoint for S3: Бакет як диск»

Це нова технологія, яка дозволяє монтувати бакет S3 прямо в контейнер.

  • Ідеально для: навчання нейромереж (читання великих масивів даних) або обробки медіа.
  • Обмеження: не підтримує випадковий запис та редагування файлів. Тільки читання або створення нових файлів. Ніколи не ставте на S3 бази даних!

Стійкість StatefulSet до збоїв зон

Розділ «Стійкість StatefulSet до збоїв зон»

Щоб ваша база даних вижила при падінні цілої AZ:

  1. Реплікація на рівні додатка: Запускайте 3 репліки бази (напр. Postgres + Patroni).
  2. Розподіл по зонах: Використовуйте topologySpreadConstraints, щоб кожна репліка жила у своїй зоні зі своїм власним диском EBS.
  3. Бекапи: Використовуйте EBS Snapshots (знімки), які зберігаються в S3 і доступні в будь-якій зоні регіону для відновлення.

ПомилкаЧому це стаєтьсяЯк виправити
Диск і Под у різних зонахBindingMode: ImmediateЗавжди використовуйте WaitForFirstConsumer у StorageClass
EBS для спільних папок”Я думав, це можливо”EBS не підтримує RWX. Використовуйте EFS для спільних файлів
Відсутність шифрування”Це ж внутрішні дані”Завжди вмикайте encrypted: "true" в StorageClass. Це стандарт безпеки
Немає лімітів на розмір”Хай диск росте”Код може забити диск логами за ніч. Ставте квоти та налаштовуйте алерти на вільне місце

1. Чому не можна перенести под із диском EBS із зони us-east-1a в us-east-1b?

Тому що диск EBS — це фізичне залізо в конкретному дата-центрі. Він не може “протягнути кабель” у сусідній дата-центр. Щоб перенести дані, треба зробити знімок (snapshot) і створити з нього новий диск у новій зоні.

2. Коли варто використовувати EFS замість EBS?

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


Практична вправа: Створення стійкої бази

Розділ «Практична вправа: Створення стійкої бази»
  1. Встановіть EBS CSI Add-on у ваш кластер.
  2. Створіть StorageClass gp3-delayed з параметром WaitForFirstConsumer.
  3. Розгорніть PostgreSQL як StatefulSet із використанням volumeClaimTemplates.
  4. Перевірте, у якій зоні (AZ) створився диск і чи співпадає вона із зоною вашого сервера.
  5. Збільште розмір диска в PVC і переконайтеся, що база побачила нове місце без перезавантаження.

Ви опанували дані, тепер час навчитися керувати витратами та масштабом. Переходьте до Модуля 5.5: EKS у продакшні — Масштабування та витрати, де ми розберемо роботу з Karpenter та Kubecost.