Налаштувати зберігання даних програм, запущених у кластері Kubernetes, можна декількома способами. Одні вже застаріли, інші з'явилися зовсім недавно. У цій статті розглянемо концепцію трьох варіантів підключення СГД, у тому числі найостаннішого підключення через Container Storage Interface.
Спосіб 1. Вказівка PV у маніфесті пода
Типовий маніфест, що описує під у кластері Kubernetes:
Колір виділено частини маніфесту, де описано, який том підключається і куди.
У розділі volumeMounts вказують точки монтування (mountPath) — у який каталог усередині контейнера монтуватиметься постійний том, і навіть ім'я тома.
У розділі x перераховують усі томи, що використовуються в поді. Вказують ім'я кожного тома, а також тип (у нашому випадку: awsElasticBlockStore) та параметри підключення. Які параметри перераховуються в маніфесті, залежить від типу тому.
Один і той самий том може бути змонтований одночасно в кілька контейнерів пода. Таким чином різні процеси програми можуть мати доступ до тих самих даних.
Цей спосіб підключення придумали на самому початку, коли Kubernetes тільки зароджувався, і сьогодні спосіб застарів.
При його використанні виникає кілька проблем:
- всі томи треба створювати вручну, Kubernetes не зможе створити нічого за нас;
- параметри доступу до кожного тома унікальні, і їх треба вказувати в маніфестах всіх подів, які використовують том;
- Щоб змінити систему зберігання (наприклад, переїхати з AWS до Google Cloud), потрібно змінювати налаштування та тип підключених томів у всіх маніфестах.
Все це дуже незручно, тому насправді подібним способом користуються для підключення тільки деяких спеціальних типів томів: configMap, secret, emptyDir, hostPath:
-
configMap і secret — службові томи, що дозволяють створити в контейнері том із файлами з маніфестів Kubernetes.
-
emptyDir - тимчасовий том, що створюється тільки на час життя пода. Зручно використовувати для тестування чи зберігання тимчасових даних. Коли pod видаляється, то типу emptyDir теж видаляється і всі дані пропадають.
-
hostPath — дозволяє змонтувати всередину контейнера з програмою будь-який каталог локального диска сервера, на якому працює програма, — в тому числі /etc/kubernetes. Це небезпечна можливість, тому політики безпеки забороняють використовувати томи цього типу. Інакше додаток зловмисника зможе замонтувати всередину свого контейнера каталог HTC Kubernetes та вкрасти усі сертифікати кластера. Зазвичай, томи hostPath дозволяють використовувати лише системним додаткам, які запускаються в namespace kube-system.
наведено у документації.
Спосіб 2. Підключення до подів SC/PVC/PV
Альтернативний спосіб підключення - концепція Storage class, PersistentVolumeClaim, PersistentVolume.
Клас зберігання зберігає параметри підключення до системи зберігання даних.
PersistentVolumeClaim визначає вимоги до того, що необхідний додатку.
PersistentVolume зберігає параметри доступу та статус тома.
Суть ідеї: у маніфесті пода вказують volume типу PersistentVolumeClaim та вказують назву цієї сутності у параметрі claimName.
У маніфесті PersistentVolumeClaim описують вимоги до даних, які необхідні додатку. В тому числі:
- розмір диска;
- спосіб доступу: ReadWriteOnce або ReadWriteMany;
- посилання на Storage class — у якій системі зберігання даних хочемо створювати том.
У маніфесті Storage class зберігаються тип та параметри підключення до системи зберігання даних. Вони потрібні кублет, щоб змонтувати том до себе на вузол.
У маніфестах PersistentVolume вказується Storage class і параметри доступу до конкретного тому (ID тома, шлях і т.д.).
Створюючи PVC, Kubernetes дивиться, який розмір і з якого Storage class буде потрібно, і підбирає вільний PersistentVolume.
Якщо таких PV немає, Kubernetes може запустити спеціальну програму - Provisioner (її назву вказують в Storage class). Ця програма підключається до СХД, створює том потрібного розміру, отримує ідентифікатор та створює в кластері Kubernetes маніфест PersistentVolume, який зв'язується з PersistentVolumeClaim.
Все це безліч абстракцій дозволяє усунути інформацію про те, з якою СГД працює додаток, з рівня маніфесту додатків на рівень адміністрування.
Усі параметри підключення до системи зберігання даних знаходяться у Storage class, за який відповідають адміністратори кластера. Все, що потрібно зробити при переїзді з AWS до Google Cloud, - це в маніфестах програми змінити назву Storage class в PVC. Persistance Volume для зберігання даних будуть створені в кластері автоматично за допомогою програми Provisioner.
Спосіб 3. Container Storage Interface
Весь код, який взаємодіє з різними системами зберігання даних, є частиною ядра Kubernetes. Випуск виправлень помилок або нового функціоналу прив'язаний до нових релізів, код доводиться змінювати для всіх підтримуваних версій Kubernetes. Все це важко підтримувати та додавати новий функціонал.
Щоб вирішити проблему, розробники з Cloud Foundry, Kubernetes, Mesos та Docker створили Container Storage Interface (CSI) - простий уніфікований інтерфейс, який описує взаємодію системи управління контейнерами та спеціального драйвера (CSI Driver), що працює з конкретною СГД. Весь код взаємодії з СГД винесли з ядра Kubernetes в окрему систему.
.
Як правило, CSI Driver складається з двох компонентів: Node Plugin та Controller plugin.
Node Plugin запускається на кожному вузлі та відповідає за монтування томів та за операції на них. Controller plugin взаємодіє зі СГД: створює чи видаляє томи, призначає права доступу тощо.
Поки що в ядрі Kubernetes залишаються старі драйвери, але користуватися ними вже не рекомендують і всім радять встановлювати CSI Driver саме для тієї системи, з якою доведеться працювати.
Нововведення може налякати тих, хто вже звик налаштовувати зберігання даних через Storage class, але насправді нічого страшного не сталося. Для програмістів нічого не змінюється — вони як працювали тільки з ім'ям Storage class, так і продовжать. Для адміністраторів додалася установка helm chart та змінилася структура налаштувань. Якщо раніше налаштування вводилися в Storage class безпосередньо, то тепер їх спочатку треба задати в helm chart, а потім вже в Storage class. Якщо розібратися, нічого страшного не сталося.
Давайте, на прикладі, розглянемо які переваги можна отримати, перейшовши на підключення СГД Ceph за допомогою драйвера CSI.
При роботі з Ceph плагін CSI дає більше можливостей для роботи з СГД, ніж вбудовані драйвери.
- Динамічний створення дисків. Зазвичай диски RBD використовуються лише в режимі RWO, а CSI для Ceph дозволяє використовувати їх у режимі RWX. Декілька pod'ів на різних вузлах можуть змонтувати той самий RDB-диск до себе на вузли і працювати з ними паралельно. Заради справедливості, не все так променисто - цей диск можна підключити тільки як блоковий пристрій, тобто доведеться адаптувати програму під роботу з ним в режимі множинного доступу.
- Створення снапшотів. У кластері Kubernetes можна створити маніфест із вимогою створити снапшот. Плагін CSI його побачить та зробить снапшот із диска. На його підставі можна буде зробити або бекап, або копію PersistentVolume.
- Збільшення розміру диска на СГД та PersistentVolume в кластері Kubernetes.
- Квоти. Вбудовані в Kubernetes драйвери CephFS не підтримують квоти, а нові CSI-плагіни зі новим Ceph Nautilus можуть включати квоти на CephFS-розділи.
- Метрики. CSI-плагін може віддавати в Prometheus безліч метрик про те, які томи підключені, які йдуть взаємодії і т.д.
- Topology aware. Дозволяє вказати в маніфестах, як географічно розподілений кластер, та уникнути підключення до подів, запущених у Лондоні системи зберігання даних, розташованої в Амстердамі.
Як підключити Ceph до кластера Kubernetes через CSI, дивіться . Також можна передплатити , який буде запущено 15 жовтня.
Автор статті: Сергій Бондарєв, практикуючий архітектор Southbridge, Certified Kubernetes Administrator, один із розробників kubespray.
Трохи Post Scriptum не реклами для, а заради користі…
PS Сергій Бондарєв веде два інтенсивності: оновлений 28-30 вересня та просунутий 14–16 жовтня.
Джерело: habr.com