Cilium CNI з eBPF: продуктивність і безпека Kubernetes

Cilium CNI: де ламається мережа всередині кластера

Мережа Kubernetes найчастіше ламається не на фізичних каналах, а вище — на трансляції адрес і сервіс-проксі.

Ланцюжки правил зростають лінійно з кількістю сервісів, таблиця відстеження з’єднань переповнюється, і втрати пакетів між сервісами починаються задовго до того, як закінчується пропускна здатність.

Діагностика впирається в те, що вузьке місце мережі кластера не видно ні в метриках вузла, ні на графіках комутатора: лічильники чисті, а клієнт отримує помилки.

Друге джерело — інкапсуляція між вузлами.

Оверлей загортає трафік у додатковий заголовок, корисний розмір кадру падає, і застосунок про це не знає: частина пакетів фрагментується або губиться мовчки, TCP переходить до повторних передач, а час відповіді зростає ступенями під навантаженням.

Третє — перебудова маршрутів при відмові вузла. Правила оновлюються послідовно, і в цьому вікні частина з’єднань іде в нікуди: поди живі, перевірки проходять, а запити до них не доходять.

Для сервісів із короткими таймаутами це виглядає як випадкові помилки за цілком здорової інфраструктури.

Cilium CNI змінює точку, у якій ухвалюються рішення: замість довгих ланцюжків трансляції адрес — програми eBPF прямо в ядрі, прив’язані до мережевих інтерфейсів, із таблицями з’єднань і балансуванням на рівні сокета. Далі розбираємо, де саме губиться трафік у таких схемах і що змінюється при відмові вузла.

Що дає мережева модель на eBPF: затримки, відмови, ізоляція

Відмінність видно на рівні шляху пакета. У традиційній моделі кожен пакет проходить ланцюжки правил, і їхня довжина зростає разом із кількістю сервісів і політик.

Мережева модель на eBPF ухвалює рішення про маршрут і дозволи в точці підключення трафіку, минаючи довгі ланцюжки, — вартість обробки перестає залежати від кількості оголошених правил.

Затримка між сервісами скорочується: частина з’єднань іде напряму між екземплярами, без проміжного вузла, який приймає й перевстановлює з’єднання.

При зростанні кількості сервісів із десятків до сотень крива затримки залишається майже плоскою замість лінійного зростання, тому на піках менше каскадних таймаутів — сервіс не чекає на мережу.

Відмовостійкість мережі тримається на розподіленій карті сервісів: кожен вузол знає, які екземпляри живі.

При падінні вузла сусіди перенаправляють трафік на вцілілі копії без центрального узгодження й обходу всієї мережі — час відновлення вимірюється секундами, і частина запитів встигає надіслатися повторно замість помилки.

Ізоляція трафіку описується мітками сервісів, а не адресами й портами. Правило доступу задається один раз і поширюється на нові копії, включно з тими, що з’явилися при масштабуванні; за замовчуванням трафік між просторами імен заборонений, поки доступ не дозволено явно.

Приймання спирається на заміри до й після: затримка між сервісами під навантаженням, час відновлення мережі після падіння вузла, частка успішних запитів у момент відмови, покриття сервісів політиками ізоляції.

Без цих чисел перехід залишається питанням віри — ми знімаємо їх на стенді, що повторює робочий контур.

Cilium CNI та альтернативні мережеві режими: порівняння

У кластері режим мережі визначає, як пакет іде від пода до пода: через інкапсуляцію, прямим маршрутом або з обробкою на боці ядра. Вибір майже завжди впирається не в пропускну здатність, а в те, що вже є в інфраструктурі: L2-сегмент, BGP-сусідство, політики хмарного провайдера. Нижче — порівняння режимів мережі за тим, коли кожен доречний і де починає заважати.

Налаштування задаються на рівні Cilium і перемикаються оборотно, але не безслідно: зміна режиму зачіпає маршрути на вузлах і на зовнішньому обладнанні.

До перемикання перевіряємо, чи проходить вибраний тип тунелю через мережу, чи є запас за розміром пакета і чи готові маршрутизатори прийняти анонси адрес подів.

Порядок впровадження: від аудиту мережі до передавання регламентів

Роботи йдуть у порядку, за якого мережа кластера змінюється передбачувано й не роняє прод. Спочатку фіксуємо поточний стан, потім проєктуємо цільову схему, перевіряємо її на копії кластера і лише після цього переносимо робочі навантаження. На кожному кроці залишається шлях назад.

1. Аудит мережі. Знімаємо карту потоків між сервісами, інвентаризуємо політики, шукаємо правила «дозволити все» та сервіси без обмежень. На виході — перелік ризиків і вузьких місць, а не загальні рекомендації.
2. Проєктування схеми. Визначаємо адресні простори, точки виходу трафіку та політику за замовчуванням: заборона всього, дозволи — точково. Схему узгоджуємо з вашою командою до початку налаштування.
3. Налаштування на копії кластера. Розгортаємо Cilium CNI на тестовому контурі, переносимо політики, вмикаємо спостережуваність: метрики за потоками й журнал відкинутих з’єднань. Тут же відпрацьовуємо процедуру відкату.
4. Перевірка на стенді. Прогоняємо навантаження, близьке до бойового, перевіряємо поведінку при відмові вузла й втраті зовнішнього каналу, дивимося затримки та частку втрачених пакетів.
5. Перемикання без простою. Переводимо робочі навантаження за пулами вузлів: нові стають на цільову схему, старі виводимо після того, як трафік на них припинився. Сервіси доступні весь цей час.
6. Передавання регламентів. Віддаємо схему, конфігурації та політики в системі контролю версій, описуємо порядок діагностики й відкату, навчаємо чергову зміну.

Політики доступу та схема мережі: що залишається в проєкті

Працюючий кластер на Cilium CNI — це ще не результат для команди, яка залишиться його обслуговувати.

Тому разом із налаштованою мережею ми передаємо комплект артефактів, за якими конфігурацію можна повторити в іншому середовищі, перевірити під час приймання й розібрати інцидент без автора: усе лежить у репозиторії поруч із маніфестами, а не в листуванні.

• Схема мережі — сегменти, діапазони адрес подів і сервісів, маршрути між нодами, точки виходу в зовнішні мережі та до внутрішніх систем.
• Матриця доступу — зведена таблиця «джерело — призначення — порт», де видно кожен дозвіл і явне правило заборони за замовчуванням.
• Мережеві політики у декларативному вигляді — заборона вхідного й вихідного трафіку за замовчуванням, дозволи за мітками, окремі правила для DNS.
• Конфігурація мережевого шару — параметри обробки пакетів на рівні ядра, балансування, інкапсуляція між нодами та прив’язка до режиму роботи кластера.
• Схема спостережуваності — метрики відмов у розрізі політик, панелі моніторингу й алерти з прив’язкою до конкретних правил.
• Регламент обслуговування — порядок оновлення мережевого шару, обов’язкові перевірки перед викочуванням, процедура повернення до попередньої конфігурації.
• Інструкція для чергової зміни — як подивитися чинні правила, визначити, яка політика відхилила трафік, і що робити при деградації зв’язку.

Технічна документація пишеться не «для галочки», а під конкретні операції: зміна політик проходить рев’ю за матрицею доступу, а розбір збою йде за схемою та логами, а не за пам’яттю конкретного інженера.

Кейс: як прибрали відмови мережі та скоротили час відновлення

Кластер замовника — кілька десятків вузлів, десятки сервісів, висока щільність подів. Мережа працювала на класичному плагіні: правила маршрутизації збиралися в ланцюжки ядра й перезбиралися повністю за кожної зміни.

Чим більше ставало сервісів, тим довше йшла будь-яка правка, а на піках новий под чекав на мережу секундами.

Ми почали не із заміни, а із замірів. Зібрали історію інцидентів за кілька місяців і розклали їх за причинами — мережа, застосунок, інфраструктура.

Виявилося, що близько двох третин відмов доступності припадало на мережевий шар, а відновлення після падіння вузла займало понад десять хвилин: маршрути сходилися поступово, і частина трафіку йшла в недоступні адреси.

Що змінили

Перевели мережевий шар на Cilium: маршрутизація й балансування перейшли в ядро, зникли проміжні ланцюжки, які перезбиралися за кожної правки.

Політики доступу описали декларативно на рівні сервісів, а не адрес — правило «сервіс А бачить лише сервіс Б» перевіряється на вході в под, без проміжного проксі. Увімкнули спостережуваність: трасування потоків між подами, щоб інцидент розбирався за логами, а не вгадуванням.

Результат за зіставний період: частка відмов, пов’язаних із мережею, упала з двох третин до однієї десятої від загальної кількості інцидентів.

Час відновлення після падіння вузла скоротився з хвилин до десятків секунд — маршрути перебудовуються розподілено, а не перезбиранням спільних правил. Кластер тримає піки без деградації мережі, а черговий інженер розбирає інцидент за готовим трасуванням.

Що робити, якщо в кластері вже розгорнуто інший мережевий модуль?

Так, заміна чинного мережевого модуля на Cilium без перерви в обслуговуванні реальна — але не встановленням поверх наявного, а поетапним переведенням вузлів.

Ключова перевірка тут не продуктивність нового модуля, а сумісність із поточним кластером: чи перетинаються діапазони адрес подів і сервісів, хто відповідає за переадресацію трафіку, чи залишається вбудований балансувальник, чи збігаються значення MTU та режими інкапсуляції.

Сумісність перевіряємо до першої зміни: звіряємо адресні пули, список мережевих політик, правила балансування, інтеграцію з контролером вхідного трафіку та спосіб роздачі адрес.

Розбіжності в MTU й режимі маршрутизації дають втрати пакетів і непомітну деградацію затримок, тому такі параметри вирівнюємо заздалегідь, на тестовому контурі з тим самим набором робочих навантажень.

Міграція без простою будується на розведенні за вузлами: вузол виводиться з балансування, на ньому піднімається новий мережевий модуль, трафік перевіряється на контрольних сценаріях, і лише після цього вузол повертається в роботу.

Далі — наступний вузол, поки весь пул не перейде на нову схему; частина правил перший час працює в режимі сумісності, щоб нічого не загубилося на межі.

Зворотний відкат закладаємо одразу: попередній модуль залишається в кластері в неактивному стані, конфігурація вузлів зберігається версіями, а перемикання описується однією командою.

Якщо після переведення групи вузлів зростають затримки або рвуться з’єднання — вузол повертається на стару схему за хвилини, без перезбирання кластера.

За підсумком знімаємо заміри до й після: обробка мережевих політик, частка втрачених пакетів, час встановлення з’єднання, навантаження на обчислювальні ядра.

Технічні питання щодо сумісності та навантаження

Перед зміною мережевого шару перевіряють чотири речі: сумісність із поточною версією Kubernetes, навантаження на вузли, порядок оновлення й поведінку працюючих сервісів. Нижче — відповіді на сумніви, які виникають у цьому розборі найчастіше.

Перевірки йдуть у фіксованому порядку: інвентаризація політик і режимів мережі, стенд із профілем бойового навантаження, потім оновлення хвилями.

Як перехід вплине на навантаження вузлів?

Частина правил вирішується в ядрі, а не розгортається в ланцюжки маршрутизації: на вузлах із сотнями сервісів падає кількість правил і час відгуку. Плата — постійний видаток на агент Cilium на кожному вузлі. Знімаємо метрики до й після переходу.

У якому порядку оновлювати кластер?

Хвилями: спочатку керуючий шар, потім робочі вузли групами з перевіркою готовності між кроками. Політики переносимо заздалегідь, щоб трафік не залишався без правил; при збої відкочуємо лише цю групу.

Чи не зламаються працюючі застосунки?

Застосунки не перезбираються — змінюється лише мережевий шар під ними. Ризики в іншому: поведінка політик, збереження вихідної адреси клієнта, розв’язання імен. Списки дозволених з’єднань звіряємо до й після.

Обговоримо задачу: повернемося з оцінкою та планом робіт

Щоб оцінка була предметною, а не «за відчуттями», нам потрібні ввідні: скільки кластерів і вузлів, яка версія Kubernetes, як влаштована мережа сьогодні, які вимоги до ізоляції між просторами імен і що критично не втратити при переході на Cilium CNI.

Окремо важливі вікна обслуговування й допустимий час простою — від цього залежить, ідемо ми поетапно, контур за контуром, чи змінюємо мережевий шар на виділеному стенді, а потім переносимо прод.

За підсумками розбору повертаємося з пакетом, у якому:

• план впровадження за етапами: підготовка вузлів, перенесення частини робочих навантажень, увімкнення мережевих політик, виведення старого мережевого шару;
• оцінка робіт — обсяг, строки та склад команди під ваш контур;
• схема міграції з точками відкату на кожному кроці та зрозумілим критерієм «пора повертатися»;
• перелік вимог до доступів, тестового контуру й розкладу змін у проді;
• чек-лист підготовки до старту — що варто зробити на вашому боці до першої правки;
• набір метрик приймання: затримки, пропускна здатність, частка трафіку під політиками, час відновлення після збою вузла.

План віддаємо документом з етапами, залежностями й зонами відповідальності, плюс розбираємо його на дзвінку з вашими інженерами — щоб спірні місця знялися до старту, а не в момент перемикання.

Опишіть задачу та поточний стан кластерів — повернемося з оцінкою та планом робіт.