Керований Kubernetes у Selectel: де ламається інфраструктура
Керований Kubernetes у Selectel знімає з команди обслуговування керуючих вузлів: їхні оновлення та доступність API — турбота провайдера. Але точки відмови кластера не зникають — вони зміщуються на рівень робочого навантаження: групи вузлів, середовища, сценарій відновлення.
Ручне масштабування вузлів — перше таке місце. Поки запас ємності рахує черговий інженер, пік приходить швидше, ніж додається машина: поди висять в очікуванні, проби готовності не проходять, частина запитів відвалюється за таймаутом. Вузли, підняті із запасом, місяцями простоюють і все одно потребують оновлень.
Розсинхрон середовищ накопичується непомітно. Правку в тестовому кластері внесли руками, повз конфігурацію, — у прод вона не потрапила; стан Terraform розійшовся з фактичним, і черговий прогін показує десятки незапланованих змін. Відлагодження перетворюється на порівняння середовищ замість пошуку причини збою.
Відновлення після збою без репетиції — лотерея. Копія стану кластера не перевірялася, StorageClass з політикою видалення тому забирає дані разом із PVC, порядок підйому залежних сервісів ніхто не фіксував. Тоді простій вимірюється не годинами планових робіт, а добами експериментів.
Розбираємо, як це закривається: декларативні групи вузлів, єдине джерело конфігурації для всіх середовищ і відновлення, яке проганяється заздалегідь, до аварії.
Ефект від виділеного кластера: що змінюється в експлуатації
Ефект від впровадження керованого кластера видно не за презентаціями, а за чотирма метриками, які команда знімає до і після: час розгортання середовища, час відновлення сервісу, частка ручних операцій і клас відмов, який перестає відтворюватися. Нижче — що саме змінюється і за рахунок чого.
- Розгортання середовища — з днів на десятки хвилин. Опис інфраструктури в коді дає однакові середовища для розробки, тестування та промислової експлуатації: новий майданчик піднімається тією самою конфігурацією, що вже перевірена, а розбіжності між стендами перестають бути окремою задачею.
- Відновлення сервісу — за регламентом, а не за пам’яттю. Вузли перестворюються автоматично, навантаження перерозподіляється між тими, що залишилися, стан сховища описується класом зберігання. Простій сервісу вимірюється хвилинами і не залежить від того, хто з інженерів на зв’язку.
- Частка ручних операцій падає. Оновлення версій, масштабування, видача сертифікатів і маршрутизація трафіку виконуються декларативно: правка в описі інфраструктури застосовується до кластера загалом, без заходу на окремі машини.
- Зникає клас відмов «поправили руками й забули». Конфігурація перестає жити лише в головах адміністраторів, будь-яке відхилення видно під час наступного застосування опису і або відкочується, або усвідомлено вноситься до нього.
Кластер розгортаємо на Selectel: керуюча частина та відмовостійкість вузлів — на боці провайдера, а за опис інфраструктури, маршрутизацію та політики зберігання відповідаємо ми. Опишіть задачу — повернемося з оцінкою та планом переходу.
Режими роботи керованого кластера: порівняння варіантів
Режим кластера обирають за двома осями — ціна помилки та вартість ізоляції. Поки продукт один, а команда невелика, спільний контур прискорює все: одна точка оновлень, один набір прав, менше сутностей у контролі.
Як тільки з’являються тестові дані, платіжні сценарії та друга команда, той самий кластер стає джерелом взаємних перешкод — невдалий реліз або нестача ресурсів на одному сервісі зачіпає інші.
Нижче — чотири режими, між якими реально обирають у керованому Kubernetes.
| Варіант | Коли підходить | Чим обмежений |
|---|---|---|
| Один спільний кластер | Один продукт, невелика команда, ранній етап | Немає розділення середовищ: тест і прод ділять вузли та керуючий шар, помилка одразу видна користувачам |
| Кластер на середовище | Кілька команд, вимоги до тестових даних | Кількість сутностей контролю зростає лінійно: більше оновлень, сертифікатів і точок моніторингу |
| Простори імен усередині кластера | Потрібна помірна ізоляція без зростання кількості кластерів | Спільний пул вузлів: сусіднє навантаження на піку впливає на затримки та витісняє поди |
| Виділений пул вузлів | Платежі, персональні дані, чутливі навантаження | Частина вузлів простоює, планувальник налаштовується вручну — мітки вузлів і правила допуску |
Що залишається спільним за будь-якого режиму
Обмеження managed-рішення в тому, що керуючий шар належить провайдеру: версії та порядок оновлень він задає сам, окремий керуючий шар під задачу не видається. Тому ізоляція навантажень будується на пулах вузлів, просторах імен і квотах.
Робочий підхід — починати з одного кластера і розділяти середовища тоді, коли з’являється друга команда або вимога тримати тестові дані окремо від продуктивних.
Як проходить впровадження: етапи інженерних робіт
Роботи йдуть послідовно: спочатку фіксуємо поточний стан контуру, потім проєктуємо та збираємо кластер, і лише після цього перевіряємо його під реальним навантаженням.
Такий порядок не залишає місця для правок «по ходу» — кожне рішення або підтверджене заміром, або зафіксоване в схемі.
Порядок робіт
- Аудит інфраструктури. Інвентаризація сервісів, зв’язків і ручних операцій; на виході — карта залежностей і список обмежень, які не можна порушити під час переїзду.
- Схема кластера. Проєктуємо пули вузлів під різні класи задач, політики оновлення, розмежування доступу та простори імен. Погоджуємо до створення перших ресурсів — правки на схемі дешевші за перебудову працюючого контуру.
- Складання середовища. Налаштовуємо точку входу трафіку, сертифікати, класи зберігання під різні профілі даних і резервне копіювання томів.
- Перенесення сервісів. Конфігурацію описуємо кодом: стан зберігається в репозиторії, середовище відтворюється з нуля, секрети винесені з маніфестів у захищене сховище.
- Навантажувальна перевірка. Проганяємо профіль реального навантаження: пікові запити, відмова вузла та окремого компонента, поведінка автомасштабування і момент вичерпання квот.
- Приймання та передача регламентів. Звіряємо цільові показники за часом відновлення та часткою успішних запитів, віддаємо документацію: оновлення, відкат, додавання сервісу, дії під час інциденту.
Що залишається у замовника: конфігурації, схеми, регламенти
Кластер керованого Kubernetes у Selectel передаємо не як доступ до панелі, а як набір артефактів у вашому репозиторії: інженер вашої команди піднімає середовище з нуля і не ставить уточнювальних питань. Нижче — що саме залишається на руках після здачі.
- Опис інфраструктури як коду. Модулі на кластер, пули вузлів, мережу та балансувальник: будь-яка зміна проходить перевірку та план, а не правиться руками в консолі — стан середовища відтворюваний.
- Схема інфраструктури. Топологія мережі, приватні та публічні сегменти, точки підключення сховищ, шлях трафіку від зовнішнього балансувальника до сервісів усередині кластера.
- Політики доступу. Ролі та прив’язки прав, окремі облікові записи для людей і автоматики, сервісні облікові записи для конвеєрів складання, обмеження на системні простори імен.
- Правила розміщення сховищ. Класи зберігання під різні типи навантаження, розміри томів, політики знімків і життєвий цикл даних — щоб том переживав перестворення вузла.
- Регламент оновлення. Порядок і вікна оновлення версії кластера, пулів вузлів і доповнень, обов’язкова перевірка на тестовому контурі та план відкату до попереднього стану.
- Інструкції з відновлення. Резервні копії конфігурацій і томів, покроковий підйом кластера на чистому майданчику, відповідальні та точки контролю на кожному кроці.
- Експлуатаційна документація. Карта сервісів та їхніх власників, схема моніторингу й оповіщень, розбір типових відмов і порядок дій чергового інженера.
Будь-який пункт можна залишити нам на супровід, але критерій здачі інший: команда без нашої участі розгортає копію середовища, проводить оновлення і відновлюється після збою.
Кейс: перенесення сервісів у кластер і метрики до та після
Що було до переїзду
Сервіс із шести застосунків і двох черг жив на віртуальних машинах, налаштованих вручну: викатка релізу займала близько сорока хвилин і вимагала чергового інженера, а відкат ішов через відновлення зі знімка.
Падіння вузла розтягувалося на години, і половину інцидентів давали розбіжності налаштувань між стендами. Перенесення в керований кластер Selectel ми будували саме навколо цих двох точок.
Що змінили
Інфраструктуру перевели в декларативний опис: Terraform створює кластер, пули вузлів і мережу, Ingress живе окремим об’єктом, StorageClass з політикою зберігання прив’язаний до томів баз даних.
Застосунки збираються в образи з незмінними тегами, міграції схеми йдуть окремою задачею перед розкаткою, проби готовності не пускають трафік на непрогрітий под. Живий трафік перемикали через балансувальник, тому переїзд пройшов без простою.
Метрики до та після
Викатка скоротилася з сорока хвилин до шести, частота релізів зросла з одного за два тижні до кількох на тиждень за того самого складу команди. Відновлення пода займає хвилини: вузол виводиться з пулу, навантаження перерозподіляється, стан піднімається з тому.
Відмови класу «розійшлися налаштування стендів» більше не повторюються — середовище збирається з одного опису.
Чим опис інфраструктури як коду кращий за ручне налаштування
За ручного налаштування кластера дії ніде не фіксуються: параметри пулів вузлів, ліміти томів і правки правил маршрутизації живуть лише в консолі та пам’яті інженера. Формально середовище працює, але відтворити його з нуля вже не можна — і це головний ризик супроводу.
Інфраструктура як код переносить ці дії в декларативні файли: опис кластера, пулів вузлів, мереж, маршрутизації та класів зберігання лежить у репозиторії поряд із маніфестами застосунків.
Відтворюваність середовищ перестає бути домовленістю на словах: стенд розробки та стенд для навантажувальних прогонів розгортаються з однієї гілки і відрізняються лише значеннями змінних.
Версіонування конфігурацій додає історію змін на рівні комітів: видно, хто і навіщо розширив пул вузлів або змінив клас зберігання. Правки проходять рев’ю до застосування, а не розбираються постфактум за логами.
Відкат змін перетворюється на звичайну операцію: повертаємо попередню версію опису і застосовуємо заново — кластер приводиться до минулого стану без відновлення за пам’яттю. За ручного налаштування той самий відкат — це години в консолі під тиском і високий шанс пропустити крок.
Без опису інфраструктури витрати часу на супровід зростають з кожною зміною: новий інженер довше входить у контекст, інциденти розбираються повільніше.
У керованому Kubernetes провайдер обслуговує лише керуючу частину, а вузли, мережа та сховище залишаються на команді — їх і тримаємо в коді, описуючи через Terraform.
Технічні сумніви: доступи, сховище, оновлення
Сумніви щодо керованого кластера зазвичай зводяться до чотирьох питань: хто і що може змінювати, де живуть дані баз і логів, як проходять оновлення і що залишається після збою. Нижче — короткі відповіді на кожне.
Як розмежувати права між командами та підрядниками?
Ролі видаємо на рівні просторів імен, а не всього кластера: розробник бачить свої сервіси, конвеєр складання отримує окремий обліковий запис лише на викат. Секрети підтягуються контролером і не лежать у маніфестах. Усі зміни потрапляють до журналу аудиту.
Який клас зберігання обрати під бази та під логи?
Під бази — клас із гарантованою продуктивністю та політикою збереження тому: дані переживають перестворення пода. Під логи й метрики достатньо мережевого диска з відкладеним підключенням. Розділення за класами прибирає випадок, коли аналітика забиває диски бази.
Оновлення проходять без простою?
Вузли оновлюються пулами по одному: навантаження витісняється, бюджети переривань не дають погасити всі копії сервісу одразу. Панель керування провайдер оновлює окремо, тому версії вузлів відстають на мінорну — це штатний режим.
Що з резервним копіюванням і відновленням?
Знімки кластера робить провайдер, але відновити з них окремий застосунок не можна. Додаємо копіювання за просторами імен і томами з розкладом і зберіганням кількох поколінь. Раз на квартал розгортаємо копію на тестовому контурі: неперевірена копія дорівнює відсутній.
Обговоримо задачу: з чого починається робота
Для оцінки строків нам достатньо розмови та кількох ввідних: скільки зараз середовищ і робочих навантажень потрібно перенести, чи є вимоги щодо доступності та вікон обслуговування, хто володіє акаунтом у хмарного провайдера і які політики безпеки вже діють. Цього достатньо, щоб зрозуміти обсяг робіт і порядок кроків, не розбираючи кластер повністю.
Повертаємося з планом робіт, у якому:
- розбивка за етапами: підготовка доступів і реєстру образів, опис інфраструктури як коду, налаштування вхідного трафіку та класів зберігання, перенесення навантажень;
- оцінка строків за кожним етапом і загальний орієнтир за тривалістю;
- перелік того, що потрібно від вас: доступи, список сервісів, вимоги до простоїв;
- схема відкату та порядок перевірки результату на кожному кроці;
- відповідальні з обох сторін і точки, де чекаємо вашого рішення;
- варіант мінімального першого кроку — перевірити підхід на одному середовищі, не чіпаючи інші.
Перший крок завжди той самий: фіксуємо поточний стан, описуємо кластер як код і піднімаємо тестове середовище — після нього видно реальні строки та ризики, а не розрахункові. Опишіть задачу у вільній формі: повернемося з планом робіт, строками та пропозицією щодо старту.
