AWS EKS production: де ламається кластер
Керований кластер у продакшені ламається не в момент розгортання, а на другий-третій місяць експлуатації: закінчується ємність, зростає трафік, хтось один раз поправив конфіг руками.
Такий збій діагностувати складніше за падіння пода — відмова проявляється не помилкою, а деградацією: повільніше відповідає API, частина запитів іде в помилки, вузол мовчки випадає з пулу.
Перше типове місце — збирання сміття на вузлах. Образи контейнерів і логи накопичуються на диску, при досягненні порогу вузол починає витісняти поди, і в момент піку вільної ємності вже немає.
Постійні правила очищення образів і ротація логів закривають це заздалегідь, а не в момент інциденту.
Друге — балансування. При кожній зміні Ingress контролер перезбирає правила й перевірки доступності, і поки триває перезбирання, частина трафіку йде повз. Нові поди, які не встигли прогрітися, отримують запити нарівні з готовими — звідси сплеск помилок рівно в момент викатки.
Третє і найдорожче — дрейф конфігурації. Правки через kubectl, змінені вручну групи безпеки, ліміти «на час»: через місяць ні маніфест, ні кластер не збігаються з реальністю, і відкат до попереднього стану неможливий ні в кластері, ні в репозиторії.
Окрема історія — секрети, заведені руками: при перестворенні простору імен або вузлів поди стартують без змінних середовища, і це з'ясовується вже в продакшені. Далі розбираємо, як ці вузькі місця кластера закриваються на AWS EKS production.
Що дає налаштування production-контуру
Production-контур у AWS EKS зібраний з керованих груп вузлів, контролера вхідного трафіку на ALB, драйвера томів на EBS і зовнішнього сховища секретів.
Така зв'язка прибирає ручні правки: версії, ліміти ресурсів і мережеві політики описані в маніфестах і застосовуються однаково в будь-якому середовищі, а стан кластера збігається до заявленого без участі людини.
Час відновлення та відмовостійкість
Несправна репліка знімається з балансування до зупинки — перевірки готовності не пропускають трафік на под, що прогрівається, тому користувач не бачить помилок.
Керована група сама перестворює вузол за шаблоном, а розподіл реплік за зонами доступності не дає застосунку впасти повністю при втраті однієї з них.
Час відновлення визначають політика перезапуску і прогрів застосунку, а не швидкість чергового інженера: типовий збій закривається за хвилини.
Оновлення без простою
Викатка вузлів іде через витіснення подів. Бюджети переривання гарантують планувальнику, що частина реплік залишається доступною, а нові вузли вводяться в роботу лише після проходження перевірок — трафік переїжджає без обриву з'єднань.
Якщо нова версія не проходить перевірки, викатка зупиняється сама, а відкат повертає попередній набір образів.
Окремий ефект — зникнення класу відмов через ручні правки. Секрети підтягуються зі сховища і не лежать у маніфестах, доступи видаються ролям сервісних акаунтів, зміни проходять через репозиторій з історією.
Інцидентів «поправили на сервері й забули» більше не виникає, а метрики і логи збираються в одному місці, тому причина збою знаходиться за даними, а не за пам'яттю учасників.
Режими роботи та варіанти збірки кластера
Режим запуску визначає, хто відповідає за оновлення системи на вузлах, за їхню заміну при відмові та за те, як навантаження стає на машини.
Один кластер зазвичай збирають з кількох варіантів одразу: сервіси з постійним трафіком ставлять на керовані групи, короткі завдання — на безсерверний запуск.
Вибір режиму роботи — це не про «швидше чи повільніше», а про межі відповідальності команди. Чим більше платформа бере на себе, тим менше повсякденної роботи в інженерів і тим менше свободи в налаштуванні системи, сховищ і мережевих надбудов.
| Варіант | Коли підходить | Що накладає на команду |
|---|---|---|
| Керовані групи вузлів | Постійний трафік і передбачуване споживання | Заміна й оновлення вузлів ідуть за правилами платформи; власні налаштування — через конфігурацію групи та обмежений набір розширень |
| Власні вузли | Нестандартний образ системи, особливі драйвери, власне розміщення навантаження по машинах | Обслуговування, оновлення й безпека системи — цілком на команді; потрібен свій порядок заміни вузлів без простою |
| Безсерверний запуск | Короткі завдання та рідкісні сплески, під які невигідно тримати постійні машини | Обмеження щодо типу навантаження і доступу до системи; постійні томи не підключаються напряму; старт завдання займає час |
Змішувати режими в одному кластері — робоча практика: сервіси з трафіком живуть на керованих групах, разові завдання вирушають на безсерверний запуск, а власні вузли залишають під те, що платформа не вміє. Режим вибираємо до збірки: від нього залежать схеми оновлення, роздача прав і модель моніторингу.
Етапи впровадження: від аудиту до передачі
Роботу ведемо послідовними етапами, і кожен закінчується артефактом, який можна перевірити: схемою, конфігурацією або протоколом випробувань. Замовник бачить, на якому кроці проєкт і що отримає на виході.
- Аудит інфраструктури. Розбираємо поточний стан: як влаштований кластер, де зберігаються секрети й томи, як збираються метрики та логи, які точки відмови вже є. На виході — карта вузьких місць і пріоритети правок.
- Схема контуру. Проєктуємо цільовий устрій: розподіл за зонами доступності, простори імен під навантаження, схема мережі, балансувальника й ротації секретів. Схему узгоджуємо до початку налаштування.
- Налаштування середовища. Описуємо інфраструктуру кодом: кластер, балансувальник, постійні томи, сховище секретів, автомасштабування вузлів і подів, обмеження ресурсів. Секрети надходять із зовнішнього сховища, а не лежать у конфігурації.
- Моніторинг і логи. Налаштовуємо показники кластера, вузлів і застосунків, збирання логів, дашборди й оповіщення за критичними порогами — проблема має виявлятися раніше, ніж її помітить користувач.
- Перевірка відмовостійкості. Проганяємо навантажувальні випробування, імітуємо відмову зони доступності та окремого вузла, перезапуск подів, відновлення з копій. Вимірюємо час відновлення і фіксуємо результат.
- Передача в експлуатацію. Віддаємо схему контуру, інструкції та регламент змін з порядком відкату, навчаємо команду. Далі — підтримка за домовленістю.
Конфігурації, схеми та регламенти на виході
Робота над кластером закінчується не запущеними сервісами, а набором артефактів, за якими платформу можна розвивати, передавати зміні та відновлювати після збою.
Усе налаштоване фіксується в репозиторії та документації замовника: інженер, який раніше не торкався проєкту, піднімає середовище за регламентом, а не за пам'яттю колеги.
- Опис конфігурації: пули вузлів та їхнє призначення, стартові розміри, правила автомасштабування, що задано декларативно, а що налаштовано вручну і чому.
- Схема мережі: межі віртуальної мережі, поділ на публічні та приватні підмережі, маршрутизація, точка входу трафіку і шлях запиту до контейнера.
- Політики доступу: ролі та сервісні акаунти, прив'язки до просторів імен, права в кластері та хмарних сервісах, порядок видачі й відкликання доступів.
- Робота із секретами: джерело істини, спосіб доставки значень у поди та оновлення без перезапуску, журнал читання й ротації.
- Регламент оновлень: порядок оновлення вузлів і версії кластера, вікна робіт, перевірки готовності, умови відкату до попереднього стану.
- Регламент розбору інцидентів: які оповіщення і кому йдуть, за якими панелями моніторингу ведеться діагностика, кроки першої лінії при деградації.
- Документація: інструкції з частих операцій, чек-ліст приймання, відповідальні за кожен контур і точки ескалації.
Кейс: як скоротили час відновлення
Замовник прийшов з робочим кластером на Amazon EKS, який обслуговували вручну: вузли додавали через консоль, секрети лежали в маніфестах відкритим текстом.
Моніторинг обмежувався завантаженням процесора, алерти йшли в загальний чат без власника — про падіння пода команда дізнавалася від користувачів.
Перший спільний розбір інциденту показав ціну такого режиму: час відновлення тримався на 45–50 хвилинах, а простій сервісу в години піку розтягувався на кілька годин.
Половину кроків робили вручну — від пошуку актуального маніфесту до повторного підключення тому, і результат залежав від того, хто саме чергує.
Кластер перевели в опис кодом: конфігурацію вузлів і груп автомасштабування, ingress-контролер для балансувальника з перевірками живучості, драйвер постійних дисків.
Секрети винесли в зовнішнє сховище і підставляли в поди як томи — у маніфестах залишилися посилання, а не значення.
Моніторинг перебудували від симптомів: метрики доступності та затримок, алерт на порушення цільового рівня, чергування з чек-лістом і готовими командами відкату. Резервні знімки стану й навчальні відновлення зробили регулярними — процедура перестала перевірятися вперше в бою.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Час відновлення | 45–50 хв | 7–9 хв |
| Ручні операції в інциденті | близько 70% кроків | менше 15% |
| Простій сервісу за квартал | кілька годин | десятки хвилин |
| Відкат релізу | вручну за інструкцією | одна команда, близько 3 хв |
Стенд зберігає здатність до відкату на будь-який з останніх релізів, а нові сервіси піднімаються за шаблоном, а не копіюванням чужого маніфесту.
Чим керований кластер відрізняється від ручної збірки?
У керованому кластері площина керування — не ваша турбота: вендор тримає її доступність, оновлює, розводить репліки та відновлює після збою.
Команді залишається все, що живе вище: робочі навантаження, склад і розмір пулів вузлів, правила автомасштабування, права доступу, мережеві політики, секрети й спостережуваність. Amazon EKS у цьому сенсі — оренда керуючого шару, а не всього кластера цілком.
При ручній збірці до цього додається те, що вендор зазвичай закриває сам: відмовостійкість керуючих вузлів, резервні копії стану кластера, планові оновлення без простою, перевірка сумісності доповнень і драйверів сховища.
Такі варіанти порівнюють не за «зручністю», а за часткою інженерного часу на супровід і за часом відновлення після відмови керуючого шару.
Ручна збірка виправдана, коли вимога жорстка: ізольований контур без виходу назовні, нестандартний мережевий стек, власний стек балансування, який керований шар не підтримує, або особлива політика оновлень ядра.
Тоді зона відповідальності розширюється до інфраструктури цілком, а супровід стає окремою роллю в команді, а не побічним завданням чергового інженера.
На практиці межу фіксують письмово: що закриває керований шар, що наша команда, де проходить стик — оновлення вузлів, ротація секретів, реакція на деградацію зовнішнього балансувальника й томів, розбір інцидентів на рівні застосунку.
Без цієї схеми обидва варіанти дають один і той самий результат: незрозуміло, хто лагодить, коли вночі падає прод.
Тому вибір зводиться до одного питання: чи готові ви тримати у штаті людей, для яких підтримка кластера — основна робота. Якщо ні — керований шар плюс прозора зона відповідальності за супровід дешевші в експлуатації, ніж зекономлений на площині керування час.
Часті запитання про налаштування кластера
Перед стартом зазвичай залишаються ті самі сумніви: як передати секрети, як оновлювати вузли без падінь, як кластер уживеться з уже працюючим контуром і скільки це займе. Нижче — короткі відповіді; якщо ваш випадок інший, розберемо окремо.
Як передати секрети і не тримати їх у репозиторії?
Значення підставляє зовнішнє сховище, у кластері залишаються лише посилання на них і права, прив'язані до сервісних облікових записів. Доступ розмежований за просторами імен, ключі шифруються в стані кластера, а ротація йде без перезапуску сервісів. У репозиторії лежать описи, а не паролі й токени.
Як оновлювати вузли без простою?
Оновлення йде хвилями: спочатку піднімаються нові вузли, на них переїжджають навантаження, лише потім виводяться старі. Правила доступності не дають вигнати більше, ніж потрібно, тому сервіс продовжує відповідати на запити. Томи підключаються заздалегідь — інакше под, який чекає на диск, не зможе переїхати на інший вузол.
Кластер вбудовується в наявний контур?
Так. Мережі стикуються з поточними, трафік надходить через балансувальник за вже прийнятою схемою, сертифікати й домени перевикористовуються. Логи та метрики йдуть у той самий контур спостережуваності, що й інші системи, — черговому не потрібне друге вікно й окрема інструкція.
Який обсяг робіт і з чого почнемо?
Спочатку обговорюємо завдання і поточний контур — повертаємося з планом: етапи, склад робіт, точки відкату. Базовий контур (кластер, мережа, секрети, спостережуваність) зазвичай збирається за одну-дві ітерації, далі йде перенесення сервісів і відлагодження під навантаженням.
Обговоримо ваше завдання і повернемося з планом
Оцінка за таким завданням не робиться «на око» — щоб порахувати склад робіт, нам потрібно побачити фактичний стан контуру і домовленості навколо нього. Нижче — що запитуємо в замовника перед стартом.
Усе це є в команди, яка веде робочий кластер, навіть якщо частину відомостей доведеться збирати по ходу.
- Роль у хмарному акаунті з обмеженими правами на читання — кореневі ключі не запитуємо і не використовуємо.
- Схему поточного контуру: кластер, вхідний балансувальник, томи, сховище секретів — або чесне «схеми немає, все збиралося руками».
- Профіль навантаження: пікові значення, добовий ритм, очікуване зростання й критичність сервісів за групами.
- Вимоги до секретів і доступів: хто отримує чутливі значення, чи є зовнішнє сховище секретів, як організована ротація.
- Куди спрямовувати оповіщення моніторингу і хто чергує: канал, пороги спрацювання, що вважається приводом будити вночі.
- Обмеження на зміни: вікна обслуговування, регламент погоджень, сервіси, які не можна чіпати без попередження.
- Інженера з вашого боку, який підтвердить деталі й прийме результат.
Повертаємося не абстрактною пропозицією, а планом робіт: етапи з результатом на кожному, схема цільової архітектури, перелік змін у порядку викатки, критерії приймання у вимірюваних величинах і порядок відкату.
Залежності та ризики йдуть окремим пунктом — не сюрпризом на середині проєкту. Опишіть завдання — повернемося з оцінкою і планом.
