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