Налаштування EKS в AWS: де кластер втрачає стійкість
Кластер в EKS піднімається за вечір: група вузлів, балансувальник, базові ролі. Стійкість на цьому не з'являється — вона проявляється лише під навантаженням, коли кластер перестає тримати пік, вузли виходять з ладу, а сервіси починають відповідати із затримкою.
Налаштування EKS в AWS — це не встановлення, а набір рішень про те, як система поводиться в найгіршому сценарії.
Перше вузьке місце — розподіл ресурсів. Якщо в контейнерів не задані запити й ліміти, планувальник вважає вузли порожніми й пакує на них більше подів, ніж вони витримують.
При першому ж сплеску спрацьовує витіснення за пам'яттю, поди перезапускаються хвилею, і сервіс потрапляє в цикл «піднявся — упав».
Друге — мережа. Поди забирають адреси з підмереж, і при щільному пакуванні вільні адреси закінчуються: нові репліки висять в очікуванні, а горизонтальне масштабування вже не допомагає.
Поверх цього лягають затримки між сервісами — зайві переходи трафіку між зонами доступності додаються до кожного виклику й накопичуються в ланцюжку з десятка залежностей.
Третє — відмова вузлів. Без політик витіснення й рознесення копій по зонах втрата однієї групи вузлів забирає із собою весь сервіс, а не одну його репліку.
Розбираємо, як це закривається: розносимо навантаження по зонах, задаємо межі ресурсів, тримаємо запас адрес і заздалегідь описуємо поведінку кластера при втраті зони.
Вимірний ефект: стійкість і швидкість відновлення
Правильне складання кластера видно не в день здачі, а в першу аварію або планове оновлення. Тому ефект вимірюємо в чотирьох величинах: час відновлення після відмови вузла, простій сервісів під час оновлень, частка успішних розкаток і поведінка на піку навантаження.
Стійкість і відновлення
Відмовостійкість кластера Amazon EKS тримається на тому, що вузли рознесені по зонах доступності, а навантаження витісняється з вузла до його зупинки. Ротація проходить без втрати запитів: застосунок піднімається на вузлах, що залишилися, з потрібною кількістю реплік.
Час відновлення скорочується з годин ручних дій до кількох хвилин — відновлення виконує автоматика, а не черговий за інструкцією.
Масштабування й оновлення
Автоматичне масштабування реагує на завантаження й довжину черги, а не лише на зайнятість процесора, тому пік обробляється без постійного запасу вузлів. Оновлення версії йде хвилями з обмеженням кількості недоступних реплік, і розкатка без відкатів стає нормою. Простій сервісів під час планових робіт перестає бути очікуваною подією.
Що перевіряємо на прийманні:
- вузли розподілені по зонах — втрата однієї не валить сервіс;
- налаштовані перевірки стану й готовності, нездорові екземпляри не отримують трафік;
- оновлення йдуть контрольованими хвилями з можливістю відкотити версію;
- масштабування спрацьовує на навантаження, а не за розкладом;
- політики витіснення не дають вибити критичні сервіси;
- аварії розбираються за метриками й журналами, а не за здогадками.
Підходи до розгортання: керований AWS чи ручне складання
Режим розгортання вибирають за двома осями: хто відповідає за шар керування кластером і де фізично живуть робочі вузли. Від цього залежить, скільки зон доступності реально переживає відмову й які операції закриває провайдер, а які залишаються на вашій команді.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Керований кластер | Немає виділеної команди експлуатації, потрібен швидкий старт і оновлення силами провайдера | Менше контролю над версіями й налаштуваннями шару керування, частина параметрів недоступна |
| Самостійне складання | Жорсткі вимоги до ізоляції, власні образи вузлів, нестандартні мережеві схеми, закритий контур | Оновлення, відмовостійкість шару керування й резервні копії стану — повністю на вас |
| Гібридна схема | Керований шар керування плюс власні робочі вузли на своїх машинах | Самі оновлюєте вузли й стежите за стикуванням мереж між контурами |
На практиці частіше виграє керований або гібридний варіант: робочі вузли розносяться по трьох зонах доступності, і втрата однієї зони не зупиняє сервіси — перезапуск навантаження займає хвилини, а не години.
Самостійне складання виправдане там, де ізоляція або вимоги регулятора важливіші за швидкість операцій. У цьому випадку ми окремо плануємо трудовитрати на супровід шару керування, оновлення й відновлення стану.
Етапи впровадження: від аудиту до передавання в підтримку
Налаштування кластера EKS в AWS — це послідовність кроків, де кожен наступний спирається на артефакти попереднього. Порядок не формальність: якщо політики доступу проєктувати раніше за схему мережі, їх доведеться переробляти разом із розбиттям на підмережі.
- Аудит інфраструктури. Що вже є: акаунти, мережі, реєстр образів, працюючі навантаження, хто і як отримує доступ. На виході — список обмежень, які схема зобов'язана врахувати.
- Схема кластера. Кількість пулів вузлів, розбиття по зонах доступності, вимоги до автомасштабування. Узгоджуємо до складання: переробка на живому кластері дорожча.
- Мережа й політики доступу. Підмережі, маршрутизація, ролі, розмежування за просторами імен, зв'язка з корпоративною автентифікацією. Права видаємо за мінімальної необхідності, а не «щоб точно працювало».
- Складання кластера. Керуючий шар, мережевий плагін, вхідний шлюз, сховище для постійних даних, політики допуску. Усе описуємо конфігурацією, а не діями в консолі.
- Перевірка відмовостійкості. По черзі гасимо вузли й цілі зони, дивимося перепланування навантаження й час відновлення. Окремо — поведінка при відмові зовнішніх залежностей.
- Спостережуваність і регламенти. Метрики, логи, оповіщення, панелі моніторингу для чергової зміни, інструкції на типові інциденти.
- Передавання в підтримку. Доступи, документація, розбір навчального інциденту, порядок ескалації. Далі кластер живе без нашої участі.
Передавані артефакти: конфігурації, схеми, регламенти
Після здачі в команди замовника залишається не лише робочий контур, а й повний комплект артефактів у ваших репозиторіях: код, схеми й регламенти. Цього достатньо, щоб підняти копію оточення, пройти перевірку безпеки й змінювати налаштування без підрядника.
- Інфраструктура як код — опис кластера й пов'язаних ресурсів у Terraform: модулі за шарами (мережа, кластер, вузли, доступи), стан у віддаленому сховищі з блокуванням, зміни через перевірку й план перед застосуванням.
- Конфігурація кластера — маніфести й Helm-чарти системних компонентів: автомасштабування вузлів і подів, вхідний контролер, збір метрик і логів, квоти й ліміти на простори імен.
- Схеми мережі — адресація підмереж, розділення публічних і приватних зон, маршрутизація, виходи в інтернет, правила доступу до зовнішніх сервісів: графіка плюс таблиця відповідності.
- Регламент оновлень — періодичність апгрейду керуючого шару й вузлів, вікна робіт, перевірка сумісності компонентів, порядок відкату на попередню версію, точки узгодження.
- Політики доступу й секретів — ролі та прив'язки, розділення прав команд і сервісних облікових записів, зберігання й ротація ключів.
- Моніторинг і алерти — панелі моніторингу, ключові метрики, пороги спрацьовування, маршрути сповіщень і вказівка, на що реагує черговий.
- Документація — інструкції з типових операцій (відновлення вузла, розширення пулів, викат релізу), схема архітектури, журнал рішень і чек-лист приймання.
Кейс: як кластер перестав падати на пікових навантаженнях
Початкова картина
Кластер на Amazon EKS збирали точковими правками через панель керування: групи вузлів одного розміру, автомасштабування лише за середнім завантаженням процесора, пороги перевірок готовності виставлені «на око».
На піках це давало передбачувану деградацію — час відгуку зростав із 400 мс до 3 секунд, частка запитів з помилками сягала 4–5%, а нові копії сервісів з'являлися через 8–12 хвилин після початку зростання трафіку.
Черговий інженер піднімав вузли вручну, тому інцидент жив від 20 до 40 хвилин. Оновлення знімали занадто багато копій одразу: реліз у час пік гарантовано призводив до короткочасної недоступності.
Що змінили
Конфігурацію перевели в декларативний опис, щоб стан кластера відтворювався з репозиторію, а не відновлювався з пам'яті. Вузли розділили на профілі під різний характер навантаження: сервіси з рівним потоком запитів і обробники черг.
Автомасштабування перевели на сигнали довжини черги й часу відгуку, додали бюджети переривань, щоб планові оновлення й ущільнення вузлів не знімали робочі копії разом. Перевірки готовності отримали реалістичні таймаути замість значень за замовчуванням.
Як вимірювали результат
Перед кожним великим релізом проганяли навантажувальні перевірки на копії контуру з профілем пікового трафіку й знімали одні й ті самі метрики: частку помилок, час відгуку на 95-му процентилі запитів, затримку масштабування й час відновлення після примусової відмови вузла. Порівняння йшло з базовим прогоном на попередній конфігурації.
За квартал частка відмов на піку впала з 4–5% до 0,2%, час відгуку — з 3 секунд до 700 мс, додавання копій прискорилося з 12 хвилин до 90 секунд, відновлення сервісу зайняло 4 хвилини замість 35. Кількість інцидентів, що потребували ручного втручання, скоротилася з дев'яти до одного.
Що робити, якщо кластер уже розгорнуто й він працює
Діючий кластер майже ніколи не потрібно зносити — починаємо з аудиту поточного стану. Дивимося розподіл ресурсів по вузлах, ліміти й запити застосунків, політики оновлення, розмежування доступів і те, як система поводиться при відмові одного вузла. Аудит дає пряму відповідь: що тут лікується точково, а що доведеться змінювати по суті.
Якщо каркас робочий, завдання закривають точкові доопрацювання.
Зазвичай цього достатньо: автоматичне масштабування під реальний профіль навантаження, приведення лімітів до фактичного споживання, розділення прав сервісів, мережеві політики, резервне копіювання стану й перевірка, що відновлення з копії справді проходить.
Такі правки не потребують зупинки сервісів і дають вимірний результат — падає частка відмов на піках, випуск прискорюється.
Коли точково не закривається, добудовуємо: виділяємо окремі пули вузлів під чутливі навантаження, виносимо стан, розводимо сервіси за просторами імен, щоб важкий сусід не забирав ресурси в критичного.
Це інкрементальні кроки — кожен перевіряється на живому середовищі й відкочується окремо, без загального простою.
Перескладання без простою — це переведення трафіку, а не зупинка. Поруч піднімається новий контур, на ньому проганяється реальний сценарій, навантаження переводиться частинами, а старий гаситься лише після того, як метрики й перевірки підтвердили здоров'я.
Поки залишається сумнів щодо конкретного сервісу, трафік повертається на попередній контур — це і є страховка.
Порядок дій вибираємо за ціною помилки й оборотністю кроку, а не за обсягом робіт. Далі це перетворюється на план: що правимо відразу, що добудовуємо, де потрібен паралельний контур.
Технічні питання: доступи, оновлення, відмова вузла
Експлуатаційні сумніви щодо кластера зводяться до кількох тем: хто і що в ньому може змінювати, що станеться при відмові зони доступності, як оновлюватися без зупинки сервісів і як утримати витрату ресурсів під контролем. Нижче — короткі відповіді, як ми закриваємо кожне з цих місць під час налаштування AWS EKS.
Як розмежувати доступи й ролі?
Права описуємо декларативно й прив'язуємо до груп у зовнішньому каталозі, а не до людей: інженер отримує доступ до свого контуру, підрядник — на час робіт. Довгоживучі особисті ключі не видаємо, а дії потрапляють у журнал аудиту з прив'язкою до користувача.
Що буде при відмові зони доступності?
Робочі вузли розподіляються по кількох зонах, а правила розміщення не дають зібрати всі копії сервісу на одному вузлі. При втраті зони екземпляри переплановуються в ті, що залишилися — це перевіряється навчаннями, а не лише конфігурацією.
Як оновлювати без простою?
Спочатку оновлюємо керуючу частину, потім робочі вузли — по одному, з плавним витісненням екземплярів і бюджетом переривання. Сервіси викочуються поступово, тому частина ємності завжди залишається під навантаженням, а попередня версія — доступною для відкату.
Як контролювати витрату ресурсів?
Кожному сервісу задаються запити й ліміти, автомасштабування працює за метриками, а не за розкладом. Окремі правила закривають зростання дисків і забуті стенди — обсяг сховища перестає зростати безконтрольно.
Як перенести наявні сервіси?
Переносимо поетапно: знімаємо залежності й виносимо стан, потім переводимо частину трафіку на кластер і звіряємо метрики. Поки показники збігаються, частка трафіку зростає — відкат до попередньої схеми залишається доступним на кожному кроці.
Обговоримо завдання й повернемося з оцінкою та планом робіт
Оцінка кластера залежить не від кількості вузлів, а від того, що вже є: скільки сервісів, як вони потрапляють у розгортання, де зберігаються секрети й як влаштовані мережеві маршрути.
Щоб обговорити завдання предметно й повернутися з оцінкою та планом робіт, а не з вилкою «від і до», потрібні ввідні дані — за ними ми збираємо склад робіт.
- Список сервісів та їхні залежності: що переїжджає в кластер, що залишається поза, хто з ким спілкується напряму.
- Поточні маніфести й чарти розгортання — за ними видно зрілість конфігурації й обсяг перенесення.
- Схема мережі: підмережі, зони доступності, вимоги до ізоляції оточень, точки входу трафіку.
- Модель доступів: як пов'язані облікові записи хмари й службові акаунти, хто і що може в кластері.
- Профіль навантаження: пікові значення, характер трафіку, вимоги до масштабування й відновлення.
- Обмеження: політики безпеки, вимоги аудиту, обов'язкові перевірки перед викатом.
- Цільові показники: час розгортання релізу, частка автоматизованих перевірок, прийнятний простій.
Далі — розбір ввідних даних, уточнювальні питання щодо спірних місць і письмовий план: склад робіт, етапи, порядок подальших кроків і те, що отримуєте на виході. Завдання, які вже закриті всередині команди, відзначаємо окремо й не включаємо в обсяг. Опишіть завдання — повернемося з оцінкою та планом робіт.
