NFS-сервер у Kubernetes: де ламається сховище
Типова схема виглядає так: один NFS-сервер у Kubernetes піднімають «нашвидкуруч» — єдиний експорт каталогу, доступ за адресою вузла, монтування у спільну теку для контейнерів.
У тестовому контурі це працює, а в проді першим проявляється зависле монтування тому: процес на вузлі не отримує відповіді й не може завершити операцію.
Зависле монтування тому — це не локальна проблема одного застосунку. Под застрягає в очікуванні, вузол не може коректно його завершити й переходить у недоступний стан — разом із ним зупиняються сусідні сервіси, які до сховища взагалі не зверталися. При цьому в журналах усе виглядає справно: сервер відповідає, явних помилок немає.
Друга міна — втрата даних під час рестарту поду. Якщо запис іде в спільний том без узгодження блокувань, рестарт обриває його на середині, і застосунок після підйому читає половину файлу як цілий. Кілька реплік, що пишуть в одну директорію, додають гонки за іменами й перезапис чужих результатів.
На піковому навантаженні вузьке місце сховища проявляється як зростаюча черга запитів: сервер витрачає час на операції з метаданими, застосунок чекає відповіді й тримає з’єднання. Додавання реплік у такій схемі не допомагає — вони впираються в той самий єдиний вузол.
Усе це лікується не «правильним сервером», а розділенням ролей: режимами монтування, рівнями доступу, лімітами й спостережуваністю за томом. Розбираємо, як це закривається.
Що дає кероване файлове сховище кластеру
Порядок у сховищі видно за швидкістю видачі тому.
За динамічного створення томів і декларативно описаного класу зберігання том з’являється в момент планування поду, і контейнер стартує з уже примонтованим каталогом — без ручного експорту на сервері й очікування чергового адміністратора. Затримка між «потрібен том» і «том готовий» перестає залежати від людини.
Другий ефект — передбачуваний клас відмов сховища. Одиночний NFS-сервер без реплікації зупиняє всі поди, які тримають на ньому дані: простій застосунку дорівнює часу відновлення сервера.
Кероване файлове сховище Kubernetes розводить збій вузла і збій сервісу — клієнт перепідключається до доступної точки, под переїжджає й отримує той самий том за тим самим шляхом, а застосунок не перезбирає стан з нуля.
Третій — продуктивність запису під навантаженням. Вузьке місце проявляється на метаданих раніше, ніж на обсязі: багато дрібних файлів, часта ротація журналів, одночасний запис із десятків подів.
Режим доступу й параметри монтування підбирають під профіль — спільний запис для розділюваних каталогів, ексклюзивний для баз і черг, окремі томи під журнали, щоб важкий запис не гальмував читання.
Порядок вимірюється конкретно: секунди на видачу тому, кількість операцій, що залишилися руками, частка відмов вузла, погашених без простою застосунку, і рівність запису на піку. Розбираємо, як це налаштовується під ваш кластер.
Власні NFS-вузли проти хмарного файлового сервісу
NFS у Kubernetes підключається як PersistentVolume через StorageClass і драйвер, а режим доступу вирішує, скільки вузлів можуть змонтувати том одночасно: ReadWriteMany — для спільних каталогів, ReadWriteOnce — для одного споживача.
Помилка у виборі проявляється не під час деплою, а під час масштабування: нова репліка зависає в очікуванні тому.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний NFS-вузол | Потрібен контроль над експортами, правами й снапшотами | Єдина точка відмови: впала машина — стали всі поди зі спільним томом |
| Керований сервіс провайдера, AWS EFS | Кілька зон доступності, не хочеться тримати сховище самим | Вища затримка на дрібних операціях, менше налаштувань, залежність від провайдера |
| Локальні диски вузлів | Бази, кеші, чутливість до швидкості введення-виведення | Тільки ReadWriteOnce, том прив’язаний до вузла й не переїжджає з подом |
| Блоковий том із драйвером | Одна репліка на запис, швидкий відкат за снапшотами | Спільного доступу немає: другий под той самий том не змонтує |
Власний вузол дає повний контроль над експортами й снапшотами, але експлуатація, оновлення та резервні копії залишаються на вашій стороні. Керований сервіс знімає цю роботу, зате обмежує налаштування й додає затримку на безлічі дрібних файлових операцій.
Практичне правило: спільні дані — на спільному томі, бази й кеші — на локальних або блокових. Режим доступу перевіряємо до викочування — на одному вузлі ReadWriteOnce працює, а на трьох репліках той самий маніфест уже не підніметься.
Як ми впроваджуємо файлове сховище: етапи робіт
Порядок робіт вибудовуємо так, щоб кожен наступний крок спирався на підтверджені дані попереднього.
Спочатку аудит сховища: дивимося, які томи вже змонтовані в кластер, які заявки на томи залишилися від видалених застосунків, хто пише в спільний каталог і з якими режимами доступу.
На цьому етапі зазвичай спливають два-три мовчазні вузькі місця — перевантажений експорт і застосунок, що тримає монтування в режимі жорстких очікувань.
- Аудит сховища. Інвентаризація томів, профілів доступу, точок монтування й прав; замір затримок читання й запису під реальним навантаженням застосунків.
- Проєктування схеми. Вибір між спільним експортом і окремими на застосунок, розбиття за класами зберігання, розрахунок запасу за ємністю та пропускною здатністю.
- Підготовка серверної частини. Розгортання служби, експорти з обмеженням за підмережею, режим синхронного запису для критичних каталогів, квоти на користувача.
- Підключення до кластера. Драйвер сховища, класи зберігання й політики звільнення томів, щоб видалений том повертав місце, а не залишався висіти.
- Перевірка відмовостійкості. Гасимо вузол із застосунком, рвемо зв’язок зі сховищем, дивимося, як поводяться поди: переїзд на інший вузол, повторне монтування, швидкість повернення в роботу.
- Навантажувальні прогони. Дивимося, за якого паралельного запису починаються черги, і підбираємо параметри монтування під профіль застосунку.
- Передача в експлуатацію. Метрики за затримками й заповненням томів, оповіщення про збої, регламент розширення й стисла інструкція для чергової зміни.
Аудит займає більше часу, ніж налаштування, і ми цього не приховуємо: переробка схеми після запуску коштує дорожче, ніж два дні інвентаризації до нього.
За підсумком у команди залишається робочий стенд, відтворювана конфігурація й зрозумілий порядок дій у разі відмови вузла або самого сховища.
Конфігурації, схеми та регламенти: що ви отримуєте
На виході ви отримуєте не набір розрізнених маніфестів, а комплект, за яким сховище розгортають, перевіряють і передають черговій зміні.
Усе лежить у репозиторії поруч із застосунками: зміни проходять рев’ю, а стан класів зберігання й томів відтворюється без ручних правок на вузлах.
- Конфігурації томів — StorageClass і описи PVC під різні профілі доступу: ReadWriteMany для спільних даних, ReadWriteOnce для навантажених баз; параметри монтування, каталог усередині тому й ліміт за обсягом.
- Політики доступу до сховища — правила експорту на боці сервера, розмежування за підмережами й просторами імен, окремі права на читання й запис, закритий анонімний доступ.
- Схема розміщення — який вузол NFS віддає які каталоги, у якій зоні він живе, як том потрапляє в под, де точки відмови й як вони розведені між собою.
- Регламент резервного копіювання — що копіюється, з якою періодичністю, скільки зберігаються копії, хто запускає відновлення й як перевіряється, що копія справді читається.
- Документація з інфраструктури — порядок підключення нового тому, дії за недоступності сервера сховища, карта метрик, чек-ліст приймання зміни.
- Спостережуваність — метрики затримки операцій, зайнятого обсягу й помилок на клієнтах, пороги спрацювання та маршрути оповіщень.
- План міграції та відкату — як перенести дані з поточного сховища без простою і як повернутися до попередньої схеми, якщо поведінка застосунку розійдеться з очікуваннями.
Кейс: перевели сховище без простою сервісу
До переїзду всі простори імен у кластері Kubernetes працювали з однією точкою монтування NFS. Томи видавалися вручну: заявка, правка списку експортів, очікування інженера — від кількох годин до доби.
Відмова єдиного сервера означала завислі томи: поди не перезапускалися, а черга заявок накопичувалася, поки черговий розбирався з конфігурацією.
Що змінили
Зібрали два вузли сховища з реплікацією експортів і автоматичним перемиканням, класи зберігання описали декларативно — том створюється й монтується без участі людини.
Додали квоти на простір імен, моніторинг затримок введення-виведення й регламент заміни вузла, перевірений на навчальній відмові.
Переїзд ішов паралельно: новий контур підняли поруч зі старим і перенесли дані з перевіркою контрольних сум. Сервіси перемикали по одному — точка монтування змінювалася в маніфесті, под перестворювався, попередній том залишався доступним для відкату. Старий контур тримали в резерві, поки навантаження не відпрацювало повний цикл на новому сховищі.
Результат у цифрах
Видача тому скоротилася з 4–6 годин ручної роботи до 30 секунд автоматичної. Збоїв доступу до даних не було за пів року спостережень — до переїзду їх набиралося 2–3 на місяць. Ручні операції з експортами зменшилися приблизно на 90%, залишилися розширення квот і планові оновлення.
Час відновлення після відмови вузла — з 40 хвилин ручного розбору до автоматичного перемикання за хвилину.
Динамічні томи чи статичне підключення: що вибрати
У Kubernetes том можна видати двома способами, і різниця не в зручності, а в точці контролю. За динамічного режиму заявка посилається на клас зберігання, і компонент, що відповідає за видачу, сам створює том потрібного розміру, прив’язує його до заявки й монтує в под.
За статичного підключення експорт готують заздалегідь, а в кластер потрапляє опис тому з точною адресою й параметрами — застосунок знаходить його за міткою.
Вибір залежить від того, хто володіє даними і як довго вони живуть.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Динамічні томи | Сервіси зі змінним навантаженням, черги, кеші, багато однотипних середовищ | Потрібен робочий клас сховища й права на створення томів; життям тому керує політика повернення |
| Статичне підключення | Спільний експорт для групи сервісів, дані, що переживають перестворення кластера, зовнішні масиви | Розмір і адреса фіксовані; розширення й ротація — вручну |
Ключова деталь — керування життєвим циклом тому. Клас зберігання задає політику повернення: після видалення заявки том або звільняється разом із даними, або зберігається й потребує ручного підключення. Для баз і черг це вирішує, чи переживе стан перестворення середовища.
На практиці обидва режими співіснують: динамічний — для сервісів без стану й тимчасових середовищ, статичний — для даних, які мають пережити кластер. Ми розкладаємо їх за класами зберігання так, щоб жоден том не залишався безгоспним.
Технічні питання перед упровадженням сховища
Перед упровадженням в інженерної команди залишається короткий список сумнівів, від яких залежить доля проєкту: сумісність томів, одночасний запис, права доступу й поведінка за відмови. Розбираємо ті, що спливають на погодженні найчастіше.
Томи сумісні з поточними маніфестами?
Перевіряємо на стенді той самий маніфест, що піде в продуктив: под отримує каталог і бачить звичайну файлову систему. Відмінність від блокового тому одна — немає форматування, тому перенесення й відкат робляться копіюванням каталогу, а не відновленням знімка стану.
Два поди пишуть в один каталог — це безпечно?
Режим ReadWriteMany дозволяє монтування на кілька вузлів, але узгодженість забезпечує застосунок, а не сховище. Для спільних завантажень і артефактів це нормально; там, де важливий порядок запису, залишаємо одного письменника або розносимо дані за підкаталогами з блокуваннями.
Як видаються права доступу?
Через ідентифікатори користувача всередині поду й режим відображення прав root на сервері. Якщо їх не налаштувати, контейнер пише від непривілейованого облікового запису й отримує відмову. Задаємо власника каталогу й групу в шаблоні один раз — нові сервіси успадковують робочу схему.
Що буде в разі відмови вузла або сервера сховища?
У разі відмови вузла том відчіплюється й переїжджає разом із подом — важливо, щоб точка монтування була доступна з нового вузла.
За недоступності самого сервера поди йдуть в очікування введення-виведення й не видаляються штатно, тому таймаути й режим повернення задаємо заздалегідь.
Обговоримо задачу: що підготувати до розмови
План робіт складається з кількох вступних: як влаштований доступ до томів зараз, який профіль навантаження й які обмеження середовища. Чим конкретніші відповіді, тим менше уточнювальних кіл — оцінка й план приходять за один прохід, а не після трьох дзвінків. Повне ТЗ готувати заздалегідь не потрібно.
Що корисно тримати під рукою:
- версія кластера Kubernetes, спосіб встановлення, кількість вузлів і зон доступності;
- поточна схема зберігання — NFS-сервер, хмарне файлове сховище або локальні томи — і що в ній не влаштовує;
- профіль навантаження: розміри томів, кількість одночасних читачів і письменників, чи потрібен спільний том на кілька подів;
- чутливість до затримки та пропускної здатності на конкретних сценаріях;
- вимоги до відмовостійкості: що має пережити падіння вузла або зони, допустимий час простою й обсяг втрат;
- обмеження середовища: мережеві політики, приватні підмережі, вимоги аудиту, доступи до інфраструктури;
- строки й вікно, у яке допустимо змінювати прод.
Із цим набором ми повертаємося з оцінкою та планом робіт: етапи, ризики й порядок підключення сховища без зупинки сервісів. Якщо частина даних поки невідома — розберемо на розмові й доповнимо по ходу.
