Чому Weave Net у Kubernetes втрачає пакети під час масштабування
На десяти-п’ятнадцяти вузлах кластер поводиться передбачувано, а після переходу через кілька десятків починають «блимати» сервіси.
Частина TCP-сесій обривається на середині, окремі SYN не доходять до пода, міжсервісні виклики падають за таймаутом — при цьому метрики вузлів чисті, а самі поди живі. Втрата пакетів у кластері виглядає як випадковий шум: відтворюється не на всіх парах вузлів і не щоразу.
Причина зазвичай складається з трьох шарів. Перший — інкапсуляція: оверлей загортає трафік у власний заголовок, ефективний MTU інтерфейсу падає, і великі пакети із забороною фрагментації тихо губляться на тунелі.
Другий — обмін топологією: зі зростанням числа вузлів агенти довше сходяться до узгодженої картини маршрутів, і у вікні сходження частина шляхів веде в нікуди. Третій — NetworkPolicy з неправильним селектором: трафік відкидається без жодного запису в логах застосунку.
Збої зв’язності оверлею неприємні тим, що діагностика мережі кластера впирається у відсутність схеми. Інженер бачить обрізані пакети на одному вузлі, але не розуміє, де саме губиться шлях: на виході з пода, на тунелі між вузлами чи вже на приймачі.
Немає карти підмереж, адресації подів і сервісів, немає списку перекривних діапазонів — і розслідування перетворюється на перебір гіпотез прямо на живому кластері.
Тому починаємо не з правки конфігурації, а з відновлення картини мережі — розбираємо, як це закривається.
Що дає оверлейна мережа кластера: вимірюваний ефект
Оверлейна мережа кластера задає два вимірювані параметри: час відновлення вузла і частку втрачених запитів під час перебудови маршрутів.
Поки мережа зібрана з розрізнених налаштувань, кожна нова нода або переїзд пода дає сплеск помилок — втрати рахуються відсотками, а не десятими частками.
Ми розгортаємо Weave Net як єдиний мережевий шар: адресація, маршрутизація між вузлами і правила доступу живуть в одній конфігурації, а не в трьох різних місцях. Заміри знімаємо на тестовому контурі до і після впровадження — на них і будуємо висновки.
Шифрування трафіку між вузлами без втрати швидкості
Шифрування трафіку між вузлами вмикається на рівні мережі: застосунок про нього не знає і доопрацювань не потребує.
Перед увімкненням проганяємо навантажувальний сценарій і порівнюємо пропускну здатність — за коректних налаштувань просідання залишається в межах похибки заміру, а трафік між нодами більше не ходить відкритим текстом.
Передбачуване відновлення після відмови вузла
Падіння вузла перестає бути подією з невизначеним результатом: маршрути перебудовуються за секунди, поди переїжджають на живі ноди, частка втрачених запитів залишається в десятих частках відсотка.
Заодно зникає цілий клас відмов — коли після перезапуску частина трафіку йде в нікуди і сервіс формально піднятий, але відповідає помилками.
Перевіряємо це не на словах: гасимо ноду під навантаженням, дивимося час відновлення і втрати, окремо переконуємося, що правила доступу не пропускають зайвий трафік. Якщо цифри розходяться з очікуваними — правимо налаштування, а не звіт.
Режими роботи оверлейної мережі: порівняння варіантів
Вибір режиму визначає, як пакети ходять між вузлами і скільки ресурсів іде на кожен новий вузол. Оверлей поверх мережі вузлів інкапсулює трафік, прямий режим віддає маршрутизацію ядру, гібрид поєднує обидва. Нижче — порівняння за двома осями: коли варіант підходить і чим він обмежує.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Оверлей поверх мережі вузлів | Кластер у хмарі або в кількох підмережах, де прямий маршрут між вузлами недоступний | Інкапсуляція забирає частину смуги, граничний розмір пакета нижчий — великі пакети фрагментуються |
| Прямий маршрутизований режим | Один домен зв’язності або керована мережа, де вузли бачать одне одного напряму | Залежить від політики мережі: зміна підмережі або фільтри ламають маршрути між вузлами |
| Гібрид | Змішана інфраструктура: частина вузлів у хмарі, частина на своєму залізі | Конфігурація складніша, відмови потрібно розмічати окремо за кожною підмережею |
Коли оверлей виправданий
Оверлей вмикають, коли вузли живуть у різних підмережах і мережа не дає анонсувати маршрути між ними.
Weave Net у цьому режимі закриває зв’язність і шифрування трафіку, а мережеві політики описуються однаково для будь-якого варіанта — зміна режиму не вимагає переписувати правила заново.
Обмеження на реальному навантаженні
На потокових задачах інкапсуляція помітна за часом відгуку, тому базу даних і шину подій частіше виносять у прямий режим. Але помилка в маршрутах там призводить до того, що частина вузлів перестає бачити одне одного. Тому обидва профілі проганяємо на тестовому контурі з бойовим характером трафіку до перемикання.
Порядок розгортання: від аудиту мережі до передачі
Розгортання починається не зі встановлення, а з аудиту мережі кластера: які діапазони адрес зайняті, як влаштована маршрутизація між вузлами, де проходять межі довіри. Помилка тут спливає пізніше — частина подів не бачить сервісів, а діагностика розтягується на дні. Тому шість етапів ідуть строго за порядком, і кожен закінчується перевірюваним результатом.
Що перевіряємо на вході
Збираємо карту кластера: зайняті та вільні діапазони, перетини з мережами офісу і хмарних майданчиків, чинні правила доступу між сервісами. Фіксуємо, які простори імен залишаються ізольованими і в кого є права змінювати мережеву конфігурацію.
- Аудит мережі кластера — інвентаризація вузлів, діапазонів і маршрутів, пошук перетинів із наявною інфраструктурою.
- Схема адресації — пул адрес для подів і службових сервісів, план за просторами імен.
- Встановлення і налаштування шифрування — розгортання Weave Net у кластері, увімкнення шифрування трафіку між вузлами, порядок ротації ключів.
- Політики доступу — дозволені зв’язки між сервісами і заборона за замовчуванням для чутливих просторів імен.
- Перевірка зв’язності під навантаженням — тести між вузлами і майданчиками, поведінка при падінні вузла, замір затримок.
- Навчання команди і передача — розбір конфігурацій, схем і сценаріїв діагностики.
Критерії готовності до передачі
Передача можлива, коли трафік між вузлами зашифрований, політики застосовуються до всіх потрібних сервісів, а відновлення вузла перевірено на практиці. У команди залишаються схема адресації, інструкції щодо типових збоїв і порядок змін.
Комплект передачі: конфігурації, схеми, регламенти
Робочий кластер і кластер, який можна передати на супровід, — не одне й те саме. Тому здача — це не демонстрація запущених контейнерів, а комплект документації, за яким ваша команда розгорне стенд з нуля, розширить мережу і розбере відмову без нас.
Що входить у комплект
- Конфігурації мережі: маніфести встановлення, параметри оверлею і значення, винесені в окремі файли, — розгортання стенда повторюється один в один.
- Карта адресації: діапазони подів і сервісів, адреси вузлів, зайняті підмережі — при розширенні кластера не конфліктуємо з корпоративною мережею.
- Політики доступу: які простори імен і сервіси кому доступні, на яких портах, який трафік шифрується між вузлами.
- Схема проходження трафіку: шлях пакета від пода до пода, точки шифрування і вузли, де знімається діагностика.
- Регламент обслуговування: планові оновлення вузлів, порядок виведення вузла на профілактику, ротація ключів шифрування.
- Порядок дій при відмові: сценарії на обрив зв’язку між вузлами, деградацію оверлею і втрату вузла — з командами перевірки на кожному кроці.
- Чек-лист приймання: набір перевірок перед кожним релізом, щоб зміна конфігурації не ламала зв’язність.
Регламенти під типові інциденти
Окремо фіксуємо, хто і що робить при збої: де дивитися метрики, як ізолювати проблемний вузол, у який момент відкочувати конфігурацію до попередньої версії.
Регламент обслуговування закриває планові роботи, а порядок дій при відмові — позапланові, тому черговий інженер не шукає рішення з нуля.
Кейс: кластерна мережа під навантаженням до і після
Початковий стан і обмеження
Кластер із кількох десятків вузлів збирали поетапно, і мережа за ним не встигала: частина трафіку йшла напряму по L2, частина — через самописну оверлейну надбудову.
Шифрування між вузлами було вимкнене, розмежування доступу трималося на підмережах і ручних правилах фаєрвола, а розсинхрон MTU на різних інтерфейсах давав втрати пакетів.
У години пік зв’язність просідала: сервіси перепідключалися, частина запитів завершувалася таймаутами, а черговий не міг швидко відокремити мережеву проблему від прикладної.
Результат у метриках до і після
Розгорнули Weave Net з шифруванням трафіку між вузлами, вирівняли MTU на всіх інтерфейсах і перенесли сегментацію в декларативні політики доступу. Додатково вивели метрики зв’язності, щоб деградація була видна до того, як її помітять користувачі.
| Метрика | До | Після |
|---|---|---|
| Втрати пакетів між вузлами в години пік | 8-12% | 0.1% |
| Розбір інциденту зі зв’язністю | близько 5 годин | близько 35 хвилин |
| Інциденти без зрозумілої причини | 40% | 5% |
| Введення нового вузла в мережу | 40 хвилин вручну | 3 хвилини автоматично |
Зв’язність перестала бути джерелом випадкових відмов, а регламент розбору звівся до трьох кроків: метрики оверлею, стан каналів між вузлами, спрацювання політик.
Чергові перестали ескалувати мережеві питання навмання, і навантаження на команду супроводу за того самого обсягу трафіку вирівнялося.
Що робити, якщо в Kubernetes уже працює інший мережевий модуль
Перейти можна, але «в лоб» — знести один модуль і поставити інший — не вийде. На час зміни мережевого модуля поди втрачають адреси, а разом з об’єктами старого модуля зникають і мережеві політики.
Тому перехід ведуть поетапно: поруч піднімають новий модуль, переносять правила і лише потім знімають старий.
Першим кроком іде інвентаризація того, що реально працює в кластері. Дивляться, які мережеві політики застосовуються (частина об’єктів зазвичай виявляється чернетками), чи є поди з прямим прив’язуванням до мережі вузла, чи перетинаються діапазони адрес старого і нового модулів.
Перетин підмереж і незбіг режиму маршрутизації — найчастіша причина, через яку зміна мережевого модуля вимагає ручної правки, а не простої заміни.
Сумісність модулів мережі перевіряють до переходу, а не під час. Новий модуль ставлять у режимі, де він бачить вузли і читає стан кластера, але адреси не видає — маршрутизація залишається попередньою. Помилка на цьому етапі коштує одного вузла, а не всього кластера.
Мережеві політики переносять окремо: селектори і правила у модулів різняться, і політика, яка раніше блокувала трафік, у новому модулі може трактуватися інакше. Кожне правило перевіряють на тестовому оточенні, і лише коли сервіси відповідають, старі об’єкти видаляють.
Перехід без простою роблять повузлово: вузол виводять з обслуговування, перемикають, перевіряють зв’язність і повертають у кластер. Потрібен запас ємності — кластер має переживати втрату одного вузла.
Конфігурацію старого модуля тримають зафіксованою як план відкату і знімають лише після того, як усі перевірки пройдено.
Часті технічні сумніви щодо оверлейної мережі
Сумніви щодо оверлейної мережі Weave Net у кластері зазвичай спливають не на встановленні, а в експлуатації: як вона поводиться під навантаженням, що станеться при втраті вузла, чим обернеться увімкнення шифрування. Нижче — те, що наші інженери перевіряють на стенді перед виведенням кластера в робочу експлуатацію.
Наскільки інкапсуляція додає затримку між сервісами?
Інкапсуляція додає заголовок до кожного пакета, і частина шляху проходить поза звичайним стеком ядра, тому затримка зростає. На типових веб-навантаженнях це частки мілісекунди, але при частому обміні дрібними запитами різниця стає помітною.
Ми заміряємо затримку до і після увімкнення оверлею і залишаємо прямі маршрути там, де вузли стоять в одній підмережі.
Як вмикається шифрування і що воно змінює?
Шифрування вмикається на рівні оверлею і закриває весь трафік між вузлами, включно зі службовим. Ціна — додаткове навантаження на процесор і падіння пропускної здатності на великих потоках.
Тому вмикаємо вибірково: для середовищ, де трафік іде через недовірені сегменти, і завжди зі зняттям замірів до і після.
Що відбувається при відмові вузла?
Вузли, що залишилися, перебудовують маршрути до втрачених підмереж, а контролери перестворюють поди на живих машинах.
Час відновлення складається з таймаутів перевірок і часу запуску контейнерів — ми вимірюємо його і фіксуємо як цільовий показник, щоб деградація була передбачуваною, а не випадковою.
Чи можна змінити адресацію підмереж на живому кластері?
Діапазон адрес змінюють поетапно: спочатку піднімають новий пул, потім переносять на нього вузли по одному, перевіряючи зв’язність після кожного кроку.
Повна зміна адресації з перестворенням кластера простіша і передбачуваніша — вибір залежить від того, скільки сервісів зав’язані на старі адреси.
Як діагностувати проблеми мережі?
Ідемо від простого до складного: зв’язність між подами на різних вузлах, стан мережевого агента на кожній машині, лічильники відкинутих пакетів, потім правила доступу між просторами імен. Так проблема оверлею відокремлюється від помилок у конфігурації сервісів і політиках.
Обговоримо задачу: підберемо режим і повернемося з планом
Щоб оцінка була предметною, а не «за фотографією», на першій розмові достатньо ввідних щодо кластера: скільки вузлів і в яких підмережах, який мережевий шар працює зараз, чи є обмеження на простій і хто володіє маршрутами між сегментами. Доступи «на всякий випадок» не потрібні — достатньо опису і поточних маніфестів.
За підсумками розмови повертаємося з оцінкою і планом робіт:
- схема розміщення: як Weave Net Kubernetes ляже на наявну адресацію і не перетнеться з діапазонами сервісів;
- підбір режиму мережі — оверлей поверх маршрутизації чи прямий режим, і де потрібен шифрований канал між вузлами;
- план переходу за кроками з точками відкату на попередній мережевий шар;
- перелік політик ізоляції трафіку між просторами імен: що вже покрито, що належить описати;
- оцінка за строками і складом робіт з розбивкою на етапи;
- список того, що потрібно з вашого боку: доступи, вікно узгодження, контакт чергового.
Супровід кластера — окремий контур: оновлення мережевого шару, контроль зв’язності вузлів, реакція на деградацію і передача документації вашій команді, щоб конфігурація не залишилася «чорною скринькою».
Опишіть задачу і надішліть ввідні — повернемося з оцінкою, планом робіт і складом етапів.
