Налаштування Envoy проксі: де рветься трафік на піках
Коли зворотний проксі під навантаженням поводиться непередбачувано, шукати причину в застосунку майже марно: вузьке місце на вході проявляється раніше, ніж запити доходять до сервісів.
Довгі з’єднання — потокові вивантаження, важкі звіти, сесії реального часу — рвуться під час планового перезапуску процесу, бо він завершується швидше, ніж встигають доопрацювати вже прийняті запити. У логах це виглядає як сплеск відповідей з помилкою на рівному місці, без жодної правки в коді.
Друге джерело — розсинхрон конфігурації між вузлами. Правила маршрутизації оновлюють на одному сервері перечитуванням файлу, а на решті вони залишаються незмінними.
Поки трафік розподіляється по всіх вузлах, та сама адреса потрапляє то під новий маршрут, то під старий: частина клієнтів отримує коректну відповідь, частина — помилку маршрутизації. Відтворити це на стенді не виходить — там вузол один, і розходженню просто нема звідки взятися.
Третій клас відмов — ручні правки під навантаженням. Зміна правил у годину пік вимагає перечитати конфігурацію, а зробити це без розриву вже встановлених з’єднань вдається не завжди.
Кожна така операція відкриває вікно, у якому втрачається частина трафіку, і чим частіше змінюються маршрути, тим ширше це вікно.
Саме тому налаштування Envoy проксі починається не з файлу конфігурації, а з відповіді на питання, як правила потрапляють на всі вузли одночасно і що відбувається зі з’єднаннями в момент їх застосування.
Розбираємо, як це закривається: від динамічної видачі конфігурації без перезапуску до керованого завершення з’єднань.
Що дає керований зворотний проксі: ефект у цифрах
Єдина точка входу знімає із застосунків роботу вхідного шару: перевірку клієнтських сертифікатів, обмеження частоти запитів, повтори до недоступних вузлів, узгодження схеми.
Сервіс займається своєю логікою, а не транспортом, — і перестає падати від некоректного запиту чи від того, що сусід не відповів вчасно.
Таку роль віддаємо проксі Envoy, де маршрути, правила та взаємна автентифікація за сертифікатами описані декларативно, а не розмазані по коду застосунків.
Що змінюється в цифрах
Час застосування конфігурації. Раніше правка маршруту означала перезбирання образу й перезапуск — десятки хвилин і обрив з’єднань. Динамічна конфігурація підхоплюється на льоту: зміна набуває чинності за секунди, активні з’єднання не рвуться, перезапуск не потрібен.
Частка відмов під навантаженням. Балансування з урахуванням фактичного стану вузлів, автоматичні повтори на іншому екземплярі та розмикання кола до нездорового сервісу прибирають каскадні помилки на сплеску. Просідання одного екземпляра перестає бути помітним для користувача.
Ручні операції на викладку. Маршрути, сертифікати й правила описуються версіонованим набором файлів і застосовуються однією зміною — замість серії ручних правок на кожному вузлі.
Окремо зникає клас інцидентів «оновили вхідний шар — частина сервісів відпала»: відмовостійкість вхідного шару забезпечується на рівні самого проксі, а не героїчними діями чергового.
Порівняння режимів конфігурації: статика, файли, динаміка
В Envoy налаштування потрапляє в процес одним із трьох шляхів: статичний файл під час старту, конфігурація як код із репозиторію з автозастосуванням або потік із керувального сервера.
Різниця проявляється в ціні правки — перезапуск із розривом з’єднань проти оновлення маршруту на живому трафіку.
Четвертий шлях — не утримувати проксі-шар узагалі, а взяти готовий хмарний балансувальник. Нижче межі застосовності кожного варіанта, включно з тими, де підхід упирається у власні обмеження.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Статична конфігурація | Стенди, поодинокі сервіси, рідкісні правки маршрутів | Будь-яка зміна — перезапуск із розривом з’єднань; не масштабується на десятки вузлів |
| Конфігурація як код у репозиторії з автозастосуванням | Один-два контури, зміни за розкладом, потрібен аудит і відкат через історію | Застосування займає хвилини; немає реакції на падіння вузла або зростання навантаження |
| Динамічна видача налаштувань з керувального сервера | Багато сервісів, часті релізи, канареечні схеми, гаряча зміна маршрутів | Потребує керувального сервера та його спостережуваності; помилка розходиться по всіх вузлах одразу |
| Готовий хмарний балансувальник | Не хочеться утримувати проксі-шар, трафік уже йде через хмару | Менше контролю над таймаутами, повторами та mTLS-політиками; складніше змінити провайдера |
На практиці варіанти комбінують: статика піднімає сам проксі, динаміка оновлює маршрути й сертифікати. Спільне обмеження одне — без перевірки конфігурації в тестовому контурі та поетапного розкату помилка потрапляє одразу на весь трафік.
Порядок впровадження: від аудиту трафіку до передачі
Починаємо з інвентаризації: які сервіси приймають зовнішній трафік, де термінується TLS і де потрібна взаємна автентифікація. Без карти потоків правка маршрутів перетворюється на вгадування — спочатку фіксуємо факти, потім чіпаємо конфігурацію.
- Аудит трафіку. Знімаємо картину з журналів і метрик: частки протоколів, пікові значення, довгі з’єднання, джерела запитів. На виході — перелік маршрутів із власниками та вимогами до шифрування.
- Схема маршрутизації. Проєктуємо listeners, clusters і правила: за доменом, шляхом або заголовком, з політиками mTLS, перевіркою сертифікатів і таймаутами. Узгоджуємо схему до написання конфігурації.
- Налаштування вузлів. Розгортаємо проксі Envoy і підключаємо динамічну конфігурацію, щоб правки застосовувалися без перезапуску й обриву з’єднань. Окремо перевіряємо поведінку при недоступному джерелі конфігурації.
- Перевірка під навантаженням. Прогоняємо профіль, близький до бойового: пікові запити, обрив з’єднання на половині відповіді, відмова одного вузла. Дивимося час відгуку та частку помилок, правимо ліміти.
- Поетапне переведення трафіку. Перемикаємо потоки частинами, від менш критичних до основних, з можливістю повернути маршрут назад однією правкою. На кожному кроці звіряємо метрики з базовими.
- Передача регламентів. Віддаємо схему, конфігурацію в системі контролю версій, порядок випуску змін і порядок відкату, навчаємо чергових.
Далі маршрути й сертифікати змінює ваша команда — за документованими правилами, без простоїв і без нас.
Артефакти конфігурації: схеми, політики, регламенти
Кілька конфігурацій проксі, які правляться руками в редакторі, живуть рівно до першого звільнення інженера. Робоче налаштування Envoy — це набір узгоджених артефактів, де зафіксовано маршрути, правила доступу та порядок їх зміни. Нижче — перелік того, що залишається в замовника разом із доступом до стендів.
- Схеми маршрутизації: карта віртуальних хостів, префіксів шляхів і цільових сервісів із часом очікування відповіді, числом повторів і правилами розподілу навантаження.
- Топологія вузлів: де стоять екземпляри проксі, як роздається конфігурація і що відбувається при втраті зв’язку з її джерелом.
- Політики доступу: правила двосторонньої перевірки сертифікатів, списки довірених клієнтів, обмеження за методами та шляхами, ліміти частоти запитів.
- Ролі та права: хто змінює маршрути, хто лише читає метрики, хто видає сертифікати, і порядок узгодження таких дій.
- Регламент випуску змін: перевірка синтаксису, прогін на проміжному стенді, викатка по вузлах, підтвердження результату.
- Регламент відкату: зберігання попередніх версій, ознака запуску повернення та час, за який конфігурація знову стає робочою.
- Інструкція чергової зміни: типові симптоми, команди діагностики, порядок ескалації та дії, які черговий не виконує без узгодження.
Документація лежить у тому ж репозиторії, що й конфігурація, і оновлюється разом із нею — новий інженер входить у роботу без переказів, а кожна зміна залишається відтворюваною.
Приклад із практики: цифри до і після зміни
Клієнт прийшов із платформою з дев’яти сервісів: вхід у бойовий контур тримався на одному вузлі з конфігурацією, яку правили руками. Викладка нової версії означала перезапуск — трафік на 1–3 хвилини йшов у помилку, а при одруківці в маршруті вікно затягувалося до 20 хвилин.
Сертифікати оновлювалися за календарем і двічі за квартал ламали взаємну автентифікацію між сервісами — ззовні це виглядало як відмови на рівному місці.
Що змінили
Перевели вхід на Envoy з динамічною конфігурацією: маршрути й перелік сервісів віддає керувальний шар за підпискою, тому правило застосовується без перезапуску й розриву з’єднань.
mTLS налаштували з автоматичною видачею та ротацією — короткий строк життя сертифіката й перевипуск без участі чергового. Маршрути й перевірки здоров’я винесли в декларативні файли, зміни проходять перевірку до застосування.
Що вийшло
Простій під час викладки зник: конфігурація змінюється на живому трафіку, частка успішних відповідей у момент релізу не відрізняється від звичайного дня. Шлях від правки до ефекту на всіх вузлах скоротився з 25–40 хвилин до хвилини.
Інциденти з простроченими сертифікатами й розсинхроном вузлів перестали повторюватися: за квартал — жодного позапланового простою через зміну входу.
Відкат тепер — повернення попередньої версії конфігурації, а не аварійний перезапуск із прогрівом, тому час відновлення впав із десятків хвилин до пари хвилин.
Чим відрізняється взаємна автентифікація на вузлі від перевірки в сервісі?
Взаємна автентифікація на вузлі та перевірка справжності сервісу — це два різних рівні, і плутати їх дорого.
На вході Envoy відповідає на питання «хто прийшов»: чи пред’явлено сертифікат, виданий довіреним центром сертифікації, чи сходиться ланцюжок до кореня, чи не минув строк дії та чи збігається ім’я власника з очікуваним.
Сервіс відповідає на інше питання — «що цьому викликачу дозволено»: конкретна операція, роль, область доступу в даних. Перше — про справжність, друге — про повноваження, і підміна одного одним ламає всю модель.
Зона довіри закінчується там, де термінується захищене з’єднання. Якщо перевірку залишити лише в коді сервісів, кожен із них тягне власну логіку розбору ланцюжка, контролю відкликання й оновлення кореневих сертифікатів — і рано чи пізно один відстає в цьому від решти.
Розходження в правилах означає, що частина внутрішніх звернень проходить за ослабленими вимогами, і ніхто цього не помічає, доки не почнеться розбір інциденту.
Внутрішнім вважається звернення, яке пройшло вхідний шар і несе підтверджену мітку зони. На практиці це виглядає так: вихідні виклики перехоплюються на рівні вузла, сертифікат підставляється автоматично, а сервіс узагалі не зберігає приватні ключі й не вміє їх читати.
Такий підхід прибирає цілий клас помилок — забутий таймаут перевірки відкликання, зашитий в образ кореневий сертифікат, самопідписаний ключ, що залишився з відлагодження.
На вхідний шар переносять усе, що можна перевірити без знання бізнес-логіки: ланцюжок, строки, відкликання, набір допустимих протоколів і версій, обмеження за адресами. У сервісі залишається авторизація — вона залежить від предметної області й без неї не працює.
Розділення дає ротацію сертифікатів без перезбирання сервісів і єдину точку, де змінюється політика контуру безпеки. Тому два рівні не замінюють, а доповнюють один одного.
Технічні сумніви: відкат, відлагодження, відмовостійкість
В Envoy динамічна конфігурація приходить від керувального сервера, і її застосування не потребує перезапуску процесу: слухачі й кластери оновлюються на льоту, а встановлені з’єднання доживають до завершення активних запитів.
Якщо новий набір виявився битим, вузол повертається до останньої валідної версії без ручного втручання.
Що відбувається зі встановленими з’єднаннями під час застосування нової конфігурації?
Слухач переходить на новий набір правил, але активні потоки не обриваються: з’єднання живе до закриття з боку клієнта або до спливання часу очікування з політики. Для довгих сесій час задається окремо, щоб оновлення не рвало поточну роботу.
Як відкотити невдалу зміну?
Конфігурація версіонується, тому відкат — це повернення попереднього набору, а не ручна правка з пам’яті. Сценарій відпрацьовується заздалегідь: відомо, за який час вузол повертається в робочий стан і які з’єднання переживають перемикання.
Як читати журнали під час розбору інциденту?
Журнали доступу, журнали проксі та трасування зв’язуються за ідентифікатором запиту: за ним видно вузол, правило та причину відмови. Цього достатньо, щоб відокремити помилку маршрутизації від збою вищого сервісу.
Що буде, якщо один вузол вийде з ладу?
Вузли працюють групою: при падінні одного трафік іде на живі, а перевірки доступності виводять нездорові екземпляри з ротації. Кожен вузол зберігає конфігурацію локально, тому недоступність керувального сервера не валить уже працюючий контур.
Обговоримо задачу: що потрібно з вашого боку і що робимо ми
Старт не повинен перетворюватися на тиждень листування: ввідні фіксуємо одразу, щоб оцінка спиралася на реальний контур, а не на припущення. Нижче — що потрібно з вашого боку і що закриваємо ми.
- Доступи. Лише на читання — до вузлів, де працює проксі, до репозиторію з поточною конфігурацією, до системи керування секретами та до зони DNS. Список облікових записів і ролей передаємо заздалегідь, зайвого не запитуємо.
- Інвентаризація контуру. Які сервіси публікуються назовні, де точки входу, скільки середовищ і як вони ізольовані. Від цього залежить число конфігурацій і схема маршрутизації.
- Потоки та сертифікати. Домени й шляхи, звідки приходять клієнти, чи потрібна взаємна перевірка сертифікатів на вході й хто їх випускає — ваш центр сертифікації чи зовнішній.
- Доставка конфігурації. Чи правиться вона зараз руками чи доставляється автоматично, чи є спосіб повернутися до попередньої версії й хто має право на правку в промисловому середовищі.
- Спостережуваність. Куди йдуть журнали доступу, метрики й трасування, які оповіщення вже налаштовані й за якими порогами спрацьовують.
- Обмеження. Вимоги щодо доступності, вікна, коли зміни заборонені, і порядок узгодження правок.
Наша зона — проєктування маршрутизації та політик доступу, рознесення конфігурації Envoy по шарах, оновлення без перезапуску вузлів і описаний порядок відкату.
За підсумками розбору повертаємося з оцінкою та планом робіт: етапи, послідовність викатки, ризики й перевірки на кожному кроці.
