Selectel Managed Kubernetes: де рветься інфраструктура
Кластер Managed Kubernetes у Selectel піднімається за хвилини, тому перші проблеми помітні не на старті, а на третьому-четвертому релізі. Конфігурація обростає правками, зробленими вручну прямо в проді: хтось поправив ліміти контейнера, хтось додав вузол через панель.
Через місяць відтворити робочий стан уже ніхто не може — і будь-яке оновлення перетворюється на експеримент на живому трафіку.
Найдорожче вузьке місце — вузли без резерву. Коли пул один, а навантаження зростає стрибком (запуск, сезон, рекламна кампанія), нові поди йдуть в очікування і частина запитів падає.
Якщо при цьому не задані політики безпечного витіснення подів і проби готовності, планове оновлення образу вузла знімає одразу кілька екземплярів сервісу — користувач бачить помилки там, де ніхто нічого не змінював.
Непередбачуване зростання добиває: автоскейлинг без прогрітих вузлів і коректних запитів ресурсів реагує із затримкою в кілька хвилин, і саме на цих хвилинах втрачається доступність.
Ручні правки в проді ламають і відкат: стан кластера розходиться з репозиторієм, під час аварії незрозуміло, до якої версії повертатися. Ціна одна — незапланований простій, який обходиться дорожче за саму інфраструктуру.
Розбираємо, як це закривається: описом конфігурації кодом у Terraform, пулами з резервом під піки і контуром GitOps, де ручна правка фізично неможлива.
Що дає керований кластер у щоденній експлуатації
Керований кластер закриває шар робіт, який не створює продукт: оновлення керуючої площини, заміну вузлів, що вийшли з ладу, ротацію сертифікатів, збір діагностики.
Selectel відповідає за це на своїй стороні, а ми описуємо конфігурацію декларативно — стан інфраструктури лежить у репозиторії та відтворюється повторно, без ручних правок на живому контурі.
Швидкість виведення середовищ змінюється на порядок: майданчик для перевірки версії піднімається за хвилини й отримує ті самі залежності, що й робочий контур.
Автоскейлинг під навантаження працює за правилами, а не за дзвінком черговому. Пул робочих вузлів розширюється, коли завантаження процесора й кількість задач у черзі тримаються вище порога довше за задане вікно, і стискається назад, коли трафік спадає.
Ранковий сплеск або розпродаж перестають перетворюватися на чергу запитів, а в спокійні години кластер не тримає простоюючі ресурси.
Окремий ефект — керована поведінка під час відмов. Якщо вузол виходить з ладу, навантаження переїжджає на живі, а перевірки готовності не пропускають трафік на нездоровий екземпляр застосунку.
Час відновлення сервісу вимірюється секундами й не залежить від того, чи встиг хтось побачити повідомлення; невдалий реліз відкочується за історією версій.
Зниження простою досягається не героїзмом чергового, а тим, що типові збої гасяться платформою до того, як їх помітить користувач.
В експлуатації це виглядає як однакові правила на всіх контурах, відтворювана конфігурація й передбачувана реакція на пік — замість ручних операцій, які залежать від того, хто сьогодні на зміні.
Варіанти розгортання: керовані вузли чи власні
Вибір схеми в Selectel Managed Kubernetes — це не суперечка «хмара чи власні сервери», а три різні розподіли відповідальності. Від нього залежить, хто веде оновлення вузлів, як масштабується пул під навантаженням і наскільки глибоко можна впливати на розміщення подів.
Керовані групи вузлів закривають типовий випадок: платформа веде життєвий цикл машин, оновлення й автоскейлинг за метриками, а ми описуємо склад груп декларативно й тримаємо конфігурацію в Git.
Власні вузли всередині кластера потрібні, коли потрібні особливі образи, локальні диски або жорсткі правила розміщення. Гібрид підключають, коли частина контуру — бази, брокери, застарілі сервіси — залишається поза кластером.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повністю керована платформа | Типові сервіси без особливих вимог до образу й диска | Налаштування хоста закриті, оновлення йдуть за графіком платформи |
| Власні вузли всередині кластера | Свої образи, локальні диски, особливі правила розміщення | Оновлення й заміну машин, що вийшли з ладу, беремо на себе |
| Гібрид: частина навантаження поза кластером | Сервіси, які не можна швидко перенести | Дві зони відповідальності, спільний моніторинг і мережеві доступи налаштовуються окремо |
Обмеження платформи перевіряємо до вибору схеми: квоти на пули, доступні конфігурації вузлів у зоні, мережеві політики й те, що керуючий шар закритий від втручання. Враховані заздалегідь, вони не змушують переробляти кластер при зростанні навантаження.
Порядок впровадження: від аудиту до передачі в підтримку
Порядок робіт зафіксовано: кожен крок спирається на артефакти попереднього, тому етап не можна пропустити без втрати результату. Нижче — як відбувається впровадження managed Kubernetes на Selectel: від інвентаризації до передачі в експлуатацію.
-
Аудит інфраструктури. Збираємо інвентаризацію: які сервіси працюють, пікові навантаження й профіль трафіку, зовнішні залежності, хто володіє доступами, де зараз єдині точки відмови. Результат — карта поточного стану й список ризиків, які закриваємо до перенесення.
-
Схема кластера. Визначаємо пули вузлів під різні типи навантаження, розподіл за зонами доступності, квоти, мережеву топологію, сховища й політику оновлень. Схему погоджуємо до розгортання: правки на етапі проєкту дешевші за правки в працюючому контурі.
-
Розгортання. Кластер і пули описуємо в Terraform, маніфести сервісів тримаємо в Git-репозиторії й розкочуємо через GitOps. Автоскейлинг вмикаємо одразу — і на рівні вузлів, і на рівні подів, з різною реакцією на плавне зростання й на різкий сплеск.
-
Перевірка відмовостійкості. Виводимо вузол і цілу зону, заміряємо час перепланування подів і поведінку автоскейлера під навантажувальним профілем. Знайдені вузькі місця закриваємо до приймання, а не в процесі експлуатації.
-
Приймання робіт. Чек-лист: покриття моніторингом і алертами, резервні копії з перевіреним відновленням, рольовий доступ, журнали, відповідність погодженій схемі. Фіксуємо метрики до й після — час відгуку, простої, швидкість викату.
-
Передача в підтримку. Віддаємо регламент типових операцій, схему кластера, описи схем викату й політик, доступи за ролями. Розбираємо з черговою зміною оновлення й відкати, щоб далі команда працювала без нас.
Що залишається в репозиторії та документації
Кластер на Selectel Managed Kubernetes передаємо не як доступи до панелі, а як репозиторій, з якого інфраструктура відтворюється повністю.
Наша команда йде, але у ваших інженерів залишається робочий опис конфігурацій, політики доступу й регламенти — за ними платформу можна розвивати й розбирати інциденти без нас.
- Інфраструктура як код: кластер, пули вузлів, мережі й балансувальники описані декларативно, стан піднімається з нуля однією послідовністю, зміни проходять рев'ю до застосування.
- Налаштування автоскейлингу: пороги спрацьовування, мінімум і максимум вузлів, поведінка на піку навантаження й правила зворотного стискання — видно, чому кластер розширюється саме так.
- Опис конфігурацій GitOps: структура каталогів, прив'язка середовищ, порядок узгодження розбіжностей між репозиторієм і живим станом.
- Політики доступу: ролі та прив'язки, розподіл прав між командами й сервісними обліковими записами, відмова від спільних ключів і ручних винятків.
- Схеми кластера: топологія, шляхи трафіку, розміщення за зонами доступності, точки, відмова яких не обвалює сервіс.
- Документація щодо кластера: як розгорнути з нуля, як оновити мажорну версію, як зняти діагностику й на що дивитися першим під час збою.
- Регламенти супроводу: періодичність оновлень, вікна робіт, порядок реагування на інциденти й межі відповідальності сторін.
- Правила роботи з секретами: де зберігаються значення, як ротуються й у кого є доступ — самих значень у репозиторії немає.
Кейс: переїзд навантаженого сервісу без простою
Сервіс із добовим піковим навантаженням жив на трьох виділених машинах: розгортання йшло вручну, а відкат займав вечір. У години розпродажів черга на обробку замовлень зростала, і черговий вручну піднімав ще одну машину — за інструкцією, яку давно ніхто не оновлював.
Перевели контур на Selectel Managed Kubernetes: застосунок запакували в контейнери, секрети й конфігурації винесли в декларативні маніфести, стан кластера описали в Terraform. Трафік переносили поступово — 5% запитів на новий контур, потім 25, 50 і 100%.
На кожному кроці звіряли частку помилок і час відповіді, і при відхиленні вага поверталася назад за хвилини.
Що змінилося в метриках
- Час розгортання версії: з 40 хвилин ручних кроків до 6 хвилин автоматичного проходу.
- Відкат на попередню версію: з вечора до одного перемикання вагою, менше двох хвилин.
- Відмовостійкість: при відмові вузла контейнери переїжджають на вільні, частка помилок на піку впала приблизно вчетверо.
- Пікове навантаження: вузли додаються за розкладом і метриками заздалегідь, а не коли черга вже виросла.
Пороги автомасштабування й правила витіснення контейнерів налаштовували за фактичними вимірами, а не за довідником. Запас на піку з'явився, а ручне чергування в інженерів зникло.
Kubernetes своїми руками чи керований сервіс
Керований сервіс — наприклад, Selectel Managed Kubernetes — забирає керуючий шар: мастер-вузли, сховище стану кластера, оновлення версій, ротацію сертифікатів, відновлення після відмови зони.
На боці команди залишається те, що описує навантаження: маніфести, політики доступу, ліміти, мережеві правила — і це не залежить від варіанта.
Власний кластер виправданий, коли платформа не закриває вимоги: власні образи вузлів із патчами ядра, нестандартні контролери допуску, жорстка прив'язка до конкретних версій.
Платять за це постійною експлуатацією — оновлення з ручним вибором вікна, чергування, резервні копії стану, розбір мережевих інцидентів.
| Зона | Kubernetes своїми силами | Керований сервіс |
|---|---|---|
| Мастер-вузли й стан кластера | ставимо, патчимо, відновлюємо самі | на боці платформи |
| Оновлення версій | вручну, з вікном простою | поетапно, з відкатом |
| Відмова зони | своя чергова зміна, свої інструкції | обробка платформою |
| Автомасштабування вузлів | свої правила й метрики | вбудовані плюс свої правила |
| Мережа, балансування, диски | інтеграції під задачу | готові, у межах каталогу |
| Навантаження й політики доступу | наша команда | наша команда |
Частіше вибирають гібрид: керований керуючий шар плюс власні пули вузлів, описані Terraform разом із мережею й правами доступу. Платформа відповідає за відмовостійкість мастер-вузлів, а команда контролює версії середовища виконання, розміщення навантажень і порядок оновлень.
Технічні сумніви перед стартом робіт
Перед стартом перевіряють не інструменти, а ризики: що буде з уже працюючим кластером, хто тримає доступи, як відкочувати зміни. Нижче — відповіді на часті запитання етапу оцінки, включно з роботою з керованим сервісом Selectel.
Чи можна перенести працюючий кластер без простою?
Піднімаємо цільовий кластер, розгортаємо навантаження з маніфестів, звіряємо сервіси й лише потім переводимо зовнішній трафік. Простій — хвилини на перемикання, а старий контур залишається відкритим як шлях назад.
Як відбуваються оновлення платформи?
Оновлюємо хвилями за групами вузлів: спочатку службовий пул, потім робочі. Навантаження перед витісненням переходять на здорові вузли, тому загального простою не виникає, а сумісність із цільовою версією перевіряємо заздалегідь.
Як видаються доступи й де зберігаються секрети?
Роздаємо за ролями через єдиний провайдер автентифікації, без разових ключів на кожного інженера. Секрети зберігаються в захищеному сховищі й підставляються під час розгортання — відкритих значень у маніфестах і логах не залишається.
Що якщо оновлення пройшло невдало?
Маніфести версіонуються, тому повернення до попереднього стану — одна команда; для даних фіксуємо точки відновлення. Процедуру відкату репетируємо до того, як вона знадобиться.
Як закриваєте нерівномірне навантаження?
Автоскейлинг налаштовуємо за кількома метриками: завантаження процесора, довжина черги, активні з'єднання. Нижня межа пулу гасить пікові сплески, верхня обмежує витрату ресурсів.
Обговоримо вашу задачу й повернемося з планом
Оцінка «за описом у месенджері» майже завжди розходиться з фактом: з'являються інші середовища, схеми доступу й вимоги до відмовостійкості.
Тому перед розрахунком ми просимо мінімальний набір вхідних — його достатньо, щоб зрозуміти обсяг робіт і ризики, не вивантажуючи внутрішню кухню повністю.
Щоб обговорити задачу предметно, надішліть:
- перелік сервісів і середовищ, які мають працювати в керованому кластері;
- поточні конфігурації, маніфести й схеми мереж, якщо контейнеризацію вже розпочато;
- профіль навантаження: піки, добовий ритм, вимоги до автомасштабування;
- обмеження щодо доступів, ізоляції середовищ і вікон обслуговування;
- вимоги до відмовостійкості й допустимого часу відновлення;
- що вже пробували й чому результат не влаштував.
Далі порядок роботи передбачуваний. Ми розбираємо вхідні, уточнюємо спірні місця й повертаємося з оцінкою робіт: склад етапів, трудовитрати, залежності від вашої сторони.
Потім — план впровадження з критеріями готовності на кожному кроці, щоб проміжний результат перевірявся, а не приймався на віру. Після запуску залишається підтримка: регламент оновлень, реакція на інциденти, передача документації вашій команді.
Опишіть задачу — повернемося з оцінкою та планом впровадження.
