Мультимережа Kubernetes: де ламається зв'язність подів
Мультимережа Kubernetes потрібна там, де под має одночасно жити у двох площинах: службовий трафік через оверлей, а дані — через окремий інтерфейс до сховища, брокера або виділеного сегмента.
Поки інтерфейс один, усе працює; щойно з'являється другий, ламається те, що раніше не викликало питань.
Перший типовий збій — маршрутизація. Другий інтерфейс піднімається, отримує адресу, але таблиця маршрутів залишається одна: трафік до потрібної підмережі йде в дефолтний шлюз оверлею і не доходить. Под бачить інтерфейс, ping за іменем не проходить, застосунок падає за таймаутом підключення.
Другий збій — зв'язність подів між собою: поди на різних вузлах отримують адреси з неперетинних діапазонів, і без узгодженої маршрутизації між вузлами частина пар «джерело-приймач» просто не бачить одна одну.
Третій збій — порядок ініціалізації. Якщо додатковий інтерфейс підключається після старту застосунку, сервіс встигає зайняти порт на основному інтерфейсі й слухає не ту адресу.
Четвертий — перетин діапазонів адрес між площинами: два інтерфейси в одному поді отримують адреси з однієї підмережі, і ядро вибирає маршрут за першим збігом, а не за тим, який потрібен.
Окрема категорія — мережеві політики. Правила, написані для однієї мережі, не застосовуються до другої: трафік іде в обхід обмежень, і це з'ясовується вже на етапі перевірки доступу, а не під час налагодження зв'язності.
Розбираємо, як це закривається: як розвести площини адресації, зафіксувати маршрути для кожного інтерфейсу й перевірити зв'язність до того, як у кластер піде робочий трафік.
Що дає мультимережа: вимірюваний ефект
Коли один фізичний інтерфейс несе і службовий трафік управління, і обмін даними між застосунками, і звернення до зовнішніх сервісів, будь-який сплеск навантаження б'є по всіх одразу.
Планувальник і контролери кластера починають втрачати heartbeat-пакети, ноди переходять у статус NotReady, а прикладні запити отримують затримки, яких у нормі не було.
Мультимережа Kubernetes розводить ці потоки по окремих інтерфейсах: керуючий, прикладний і службовий трафік ідуть незалежно, і перевантаження одного не деградує решту.
Розділення трафіку дає пряму ізоляцію мереж: прикладні поди спілкуються через свій інтерфейс, службові — через свій, і збій або шторм в одному сегменті не перетікає в інший.
Це ж знімає конфлікти адресації, коли різним класам задач потрібні перетинні діапазони, і спрощує застосування мережевих політик — правила пишуться для конкретного сегмента, а не для всього кластера одразу.
За продуктивністю ефект вимірюваний: службовий трафік перестає конкурувати з прикладним за смугу, джиттер на критичних запитах падає, а пікові сплески обміну даними більше не викликають зростання затримок управління.
Відмовостійкість кластера зростає окремо — при деградації одного каналу решта продовжують працювати, а ноди не випадають з ладу через недоставлений службовий пакет.
Для замовника це виражається в передбачуваній поведінці під навантаженням і в тому, що інцидент в одному сегменті залишається локальним. Ми розбираємо, як це закривається на рівні конфігурації.
Варіанти організації мультимережі в кластері
Мультимережа в Kubernetes починається з вибору базової моделі: одна пласка мережа, оверлей поверх неї або кілька незалежних інтерфейсів на под.
Від цього залежить, як трафік піде між подами, нодами та зовнішніми сегментами, і наскільки передбачуваною буде поведінка під навантаженням.
Пласка мережа дає мінімальні накладні витрати та пряму маршрутизацію — поди бачать одне одного без інкапсуляції, але вимагають узгодженої адресації на рівні інфраструктури й погано масштабуються за межі одного сегмента.
Оверлей вирішує питання зв'язності між нодами та зонами, зате додає інкапсуляцію й ускладнює діагностику: частина проблем із затримками та втратою пакетів проявляється лише на межі тунелів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Одна пласка мережа | Один сегмент, низька затримка, контроль над маршрутизацією | Погано тягнеться між зонами, вимагає ручної адресації |
| Оверлей | Багато нод і зон, потрібна зв'язність «з коробки» | Інкапсуляція, складніше налагодження, вищі накладні витрати |
| Кілька інтерфейсів через плагін | Розділення трафіку: сервісний, сховище, управління | Потрібен вибір плагіна та явні режими підключення на кожен под |
Кілька мережевих інтерфейсів на под — окремий клас задач: сервісний трафік, доступ до сховища та управлінський контур розводяться по різних мережах, щоб не заважати одне одному.
Тут і з'являються мережеві плагіни з підтримкою додаткових підключень: базовий відповідає за основну мережу, а додаткові інтерфейси підключаються через окремі конфігурації та режими — міст, маквлан або прямий інтерфейс.
На практиці вибір не бінарний: оверлей часто залишають для службової зв'язності, а критичний трафік виводять у плаский сегмент або на виділений інтерфейс. Далі розбираємо, як це налаштовується і які режими підключення варто перевіряти до викочування в прод.
Етапи впровадження мультимережі Kubernetes
Впровадження мультимережі починається не зі встановлення плагіна, а з аудиту поточного стану кластера.
Інженери збирають карту мережевого трафіку: які поди спілкуються між собою, де проходить межа між службовим і прикладним трафіком, чи є вимоги до ізоляції або пропускної здатності.
Без цієї картини будь-яка схема адресації виявиться навмання — і перший же конфлікт підмереж зупинить розгортання.
- Аудит мережі. Фіксуємо поточну топологію, діапазони адрес, точки виходу назовні та вузькі місця за трафіком. На виході — документ з реальною картиною, а не припущеннями.
- Проєктування схеми адресації. Розводимо службову та прикладну мережі за різними діапазонами, виключаємо перетини з інфраструктурою замовника. Схема узгоджується до початку робіт — правки на цьому етапі дешевші за будь-які переробки в бою.
- Підготовка вузлів та інтерфейсів. На кожному вузлі налаштовуються додаткові мережеві інтерфейси, перевіряється їхня доступність і стабільність лінків. Помилка тут проявиться тільки під навантаженням, тому перевіряємо заздалегідь.
- Налаштування плагіна мультимережі. Встановлюємо та конфігуруємо Multus як метаплагін, підключаємо потрібні CNI для кожної мережі, задаємо прив'язку подів до інтерфейсів через анотації. Службовий трафік залишається на основній мережі, прикладний переходить на виділену.
- Перевірка зв'язності. Проганяємо тести між подами в різних мережах, перевіряємо доступність назовні, поведінку при перезапуску подів і вузлів. Окремо дивимося, що ізоляція працює і трафік не «протікає» між сегментами.
- Навантажувальне тестування. Перевіряємо пропускну здатність і стабільність під реальним профілем трафіку. Це виявляє проблеми маршрутизації, які не видні на холостому ходу.
- Передача в експлуатацію. Віддаємо конфігурації, схему адресації, інструкції з діагностики та регламент додавання нових мереж. Команда замовника може розвивати конфігурацію без нас.
Кожен етап закінчується перевірюваним результатом, а не звітом про роботи. Якщо на аудиті з'ясовується, що мультимережа не потрібна — говоримо про це прямо і пропонуємо простіше рішення.
Артефакти: конфігурації, схеми, регламенти
Після впровадження мультимережі Kubernetes замовник отримує не «працюючий кластер взагалі», а комплект, за яким інфраструктуру можна експлуатувати, розширювати й передавати іншій команді без усних пояснень. Нижче — що саме залишається на руках.
- Конфігурації мережі. Маніфести NetworkAttachmentDefinition для кожної мережі: ім'я, тип, діапазон адрес, шлюз, VLAN-ідентифікатор, режим підключення. Окремо — прив'язки подів і робочих навантажень до потрібних інтерфейсів, щоб маршрутизація трафіку була відтворюваною, а не «налаштованою вручну на одному вузлі».
- Схема адресації. Єдина карта: які підмережі виділені під службовий, прикладний і адміністративний трафік, де проходять межі між ними, які адреси зарезервовані. За нею видно, куди підключати нове навантаження і де закінчується вільний простір.
- Схема маршрутизації та ізоляції. Як трафік ходить між мережами, де стоять правила, що розділяють контури, і що станеться при відмові одного з каналів. Схема відображає реальну топологію, а не проєктну.
- Регламент експлуатації. Порядок додавання нової мережі, зміни діапазонів, підключення подів і виведення вузлів з обслуговування. З описом, які кроки безпечні на працюючому кластері, а які потребують вікна.
- Документація кластера. Опис компонентів, версій, залежностей між мережами та зовнішніми системами, точок відмови. Достатній, щоб новий інженер розібрався без автора впровадження.
- Перевірки та моніторинг. Набір перевірок доступності інтерфейсів, метрики за трафіком і помилками, правила оповіщення при деградації мережі. Плюс — сценарії діагностики типових збоїв.
- План відкату. Що і в якому порядку відключається, якщо нова конфігурація ламає зв'язність, і як повернутися до попереднього стану без втрати керованості.
Комплект передаємо в репозиторій замовника з історією змін — далі команда веде його самостійно. Опишіть вашу задачу, і ми повернемося з оцінкою та планом робіт.
Кейс: розділення трафіку на три мережі
Клієнт — оператор платформи з кількома командами продуктів. Один спільний кластер, і весь трафік — клієнтський, службовий і трафік сховища — йшов через один інтерфейс.
Під піками службові завдання (реплікація, збір метрик, резервне копіювання) забивали смугу, і клієнтські запити починали втрачати пакети. Діагностика впиралася в те, що в одному потоці неможливо було відділити причину від наслідку.
Що зробили
Розгорнули Multus як мета-плагін поверх основного мережевого інтерфейсу і завели три незалежні мережі: клієнтську, службову і мережу сховища.
Кожному робочому вузлу додали окремі інтерфейси, а застосункам видали анотацію з потрібною мережею — под вибирає її автоматично при старті. Службовий трафік і трафік сховища перестали конкурувати з клієнтським за одну смугу.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Втрати пакетів на піку | до 4% | < 0,1% |
| Затримка клієнтських запитів | зростала в 3-4 рази під навантаженням | стабільна |
| Час реплікації сховища | конкурувало з клієнтами | окрема смуга, без впливу |
| Діагностика інциденту | години на розділення потоків | причина видна по мережі одразу |
Результат
Розділення потоків прибрало взаємний вплив: службові завдання більше не роняють клієнтський сервіс, а інциденти локалізуються по конкретній мережі, а не по всьому кластеру.
Відмова однієї мережі не зачіпає решту — платформа переживає пікові навантаження без деградації клієнтських запитів.
Чим мультимережа відрізняється від однієї мережі з політиками?
Мережева політика працює всередині одного плоского адресного простору: поди бачать одне одного напряму, а правила лише фільтрують, кому з ким можна спілкуватися. Це зручно, поки весь застосунок живе в одному кластері й одному довіреному сегменті.
Щойно з'являється трафік, який не повинен навіть теоретично перетинатися з прикладним — службовий обмін баз даних, потік з промислового обладнання, канал платіжного шлюзу — фільтрація перестає бути достатньою гарантією. Правило можна випадково послабити однією правкою маніфесту, і ізоляція зникає.
Мультимережа влаштована інакше: под отримує кілька інтерфейсів, і кожен підключений до свого сегмента зі своєю адресацією. Прикладний трафік іде через один інтерфейс, службовий — через другий, трафік зовнішніх партнерів — через третій.
Розділення задане на рівні підключення, а не на рівні правил: навіть якщо політику на прикладному інтерфейсі буде налаштовано неправильно, чужий сегмент фізично не опиниться в тому самому адресному просторі. Це принципово інший клас гарантії — не «заборонено правилом», а «недосяжно за побудовою».
Порівняння підходів зводиться до трьох осей. За ізоляцією трафіку політики дають логічну межу, мультимережа — топологічну. За керованістю одна мережа простіша: менше сутностей, менше точок відмови, звична діагностика.
Мультимережа потребує планування адресації, узгодження маршрутів і уваги до того, який інтерфейс вибирає застосунок за замовчуванням.
За сумісністю політики працюють з будь-яким подом без змін, а кілька інтерфейсів вимагають, щоб застосунок або sidecar уміли адресуватися в потрібний сегмент.
Практичний висновок не в тому, що одне краще за інше. Політики залишаються обов'язковим базовим шаром — вони закривають lateral movement усередині кластера і коштують дешево.
Мультимережа додається точково, там, де потрібна справжня межа: регуляторні сегменти, мережі обладнання, розділення прод- і службового трафіку. На практиці їх поєднують: політики керують доступом усередині кожного сегмента, а кілька інтерфейсів не дають сегментам зустрітися.
Часті технічні питання щодо мультимережі
Мультимережа в Kubernetes майже завжди впирається не в сам плагін, а в питання сумісності та діагностики, які виринають уже на стенді. Нижче — те, що найчастіше запитують інженери перед тим, як закладати таку схему в прод.
Чи сумісно це з поточним кластером і CNI, який уже стоїть?
Так, Multus працює як метаплагін поверх основного CNI: він не замінює його, а додає додаткові інтерфейси до поду. Основний CNI залишається дефолтним і продовжує відповідати за службовий трафік, а друга та наступні мережі підключаються через NetworkAttachmentDefinition.
Перевіряємо на стенді сумісність версій основного плагіна і Multus, порядок інтерфейсів у поді та те, що маршрутизація за замовчуванням не перехоплюється додатковим інтерфейсом.
Які обмеження у мультимереж, про які варто знати заздалегідь?
Додаткові інтерфейси додають накладні витрати на мережевий шлях і ускладнюють налагодження: у поду з'являється кілька адрес, і застосунок має явно вибирати, через який інтерфейс ходити.
Частина мережевих політик і балансувальників за замовчуванням дивиться лише на основний інтерфейс — це потрібно враховувати під час проєктування. Також варто заздалегідь визначити, які мережі дають L2-зв'язність, а які — лише маршрутизований доступ.
Як діагностувати, що под отримав не той інтерфейс або немає зв'язності?
Починаємо з опису поду: видно, які інтерфейси та адреси реально призначені. Далі перевіряємо сам об'єкт NetworkAttachmentDefinition — коректність посилання на плагін і підмережу.
Якщо адреса є, а трафіку немає, дивимося таблиці маршрутизації всередині поду та на вузлі, а також правила фільтрації. Часто причина — конфлікт маршруту за замовчуванням або неправильно вибраний батьківський інтерфейс на вузлі.
Чи можна відкотитися, якщо схема не приживеться?
Так. Додаткові мережі підключаються декларативно, тому відкат — це видалення прив'язок і повернення подів до одного основного інтерфейсу. Основний CNI при цьому не чіпаємо, службовий трафік не страждає. Ми завжди закладаємо такий план відкату до початку робіт, щоб зміну можна було зняти без простою.
Опишіть вашу задачу — повернемося з оцінкою та планом впровадження.
Обговоримо ваше завдання з мультимережею
Розподіл трафіку між кількома мережами в кластері — це завдання, де ціна помилки в проєктуванні стає видимою не одразу, а через тижні експлуатації.
Тому ми не починаємо з налаштування, а спершу розбираємо вашу топологію: скільки мереж потрібно, який трафік ними піде, чи є вимоги до ізоляції та пропускної здатності. Це визначає і вибір режиму, і порядок робіт.
- Розбір завдання. Збираємо вхідні дані: які поди повинні бачити кілька інтерфейсів, чи потрібна ізоляція між ними, чи є зовнішні вимоги до адресації. Фіксуємо, що критично, а що можна вирішити типовими засобами.
- Оцінка робіт. За підсумками розбору повертаємося з оцінкою термінів і обсягу — без абстрактних «залежить від складності», а з конкретним переліком змін у конфігурації кластера.
- План впровадження. Узгоджуємо послідовність: підготовка вузлів, встановлення та налаштування плагіна, опис мережевих об'єктів, прив'язка подів до потрібних інтерфейсів. Кожен крок із точкою відкату.
- Пілот на одному вузлі або стенді. Перевіряємо, що маршрутизація між мережами працює як задумано, а основний трафік не зачеплений. Тільки після цього розгортаємо на весь кластер.
- Розгортання та перевірка. Застосовуємо конфігурацію поетапно, контролюючи стан вузлів і подів. Окремо перевіряємо сценарії відмов — що станеться при втраті однієї з мереж.
- Передача та документація. Віддаємо схему мереж, конфігурації та інструкції щодо зміни — щоб ваша команда могла розвивати рішення без нас.
Якщо у вас уже є кластер і потрібно додати мультимережу без простою — це окремий сценарій, його теж розберемо. Опишіть завдання: скільки мереж, який трафік, які обмеження щодо доступності.
Повернемося з оцінкою та планом впровадження, а за потреби підключимо інженера для розбору на вашій стороні.
