Cilium Service Mesh у Kubernetes: eBPF, mTLS, Hubble

Cilium service mesh: чому sidecar-архітектура впирається в стелю

Класичний service mesh будується на sidecar-проксі: поруч із кожним контейнером застосунку піднімається окремий проксі, через який іде весь вхідний і вихідний трафік.

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

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

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

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

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

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

Cilium service mesh прибирає саме джерело цих витрат: маршрутизація та політики виконуються на рівні ядра через eBPF, без проміжного проксі в тракті даних. Розбираємо, як це змінює затримки, споживання пам'яті та відмовостійкість.

Що дає архітектура eBPF без sidecar

Класичний service mesh будується на sidecar-проксі: поруч із кожним контейнером застосунку піднімається окремий контейнер-посередник, через який проходить весь вхідний і вихідний трафік.

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

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

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

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

Ресурси. З подів іде sidecar-контейнер: вивільняється пам'ять, яку він тримав, і процесорний час, який він витрачав на проксіювання. На щільному кластері це вивільняє ресурси під самі робочі навантаження, а не під інфраструктуру меша.

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

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

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

Режими розгортання: sidecar, sidecarless та гібрид

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

Класичний sidecar ставить проксі-контейнер поряд з кожним подом: застосунок не змінюється, але зростає споживання ресурсів і ускладнюється життєвий цикл поду.

Sidecarless-режим переносить обробку трафіку в ядро через eBPF — проксі в поді немає, затримки нижчі, але частина сценаріїв L7 потребує явного ввімкнення. Гібридний режим залишає sidecar лише там, де він реально потрібен, а решту віддає ядру.

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

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

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

Етапи впровадження Cilium service mesh у кластер

Впровадження Cilium service mesh починається не зі встановлення, а з інвентаризації того, що вже працює в кластері. На цьому етапі важливо зрозуміти топологію мережі, поточні CNI-плагіни, набір мережевих політик і те, як застосунки спілкуються між собою.

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

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

1. Аудит кластера та мережі. Збираємо карту вузлів, версій, поточного CNI, мережевих політик і точок входу трафіку. Фіксуємо, які сервіси критичні, а які можна переводити першими.
2. Проєктування схеми мережі. Визначаємо режим роботи (overlay або native routing), діапазони адрес, політику маршрутизації між подами та вузлами. Схема узгоджується до початку змін.
3. Підготовка середовища. Розгортаємо Cilium у тестовому контурі, перевіряємо сумісність із поточними компонентами, налаштовуємо шифрування трафіку між подами та базові політики.
4. Налаштування service mesh. Вмикаємо маршрутизацію на рівні L7, mTLS між сервісами, правила доступу та спостережуваність через Hubble. Політики описуються декларативно та версіонуються разом із кодом.
5. Перевірка на пілотних сервісах. Переводимо 2–3 некритичних сервіси, дивимося на затримки, частку успішних з'єднань і поведінку при відмові вузла. Порівнюємо з вихідними метриками.
6. Поступова розкатка. Розширюємо контур на решту сервісів хвилями, з моніторингом і готовим планом відкату на кожному кроці.
7. Передача документації. Віддаємо схему мережі, конфігурації, опис політик, регламент оновлення та інструкції з діагностики інцидентів.

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

Політики доступу та IAM-ролі в Cilium

Політики доступу в Cilium описуються декларативно — як об'єкти CiliumNetworkPolicy та CiliumClusterwideNetworkPolicy, а не як набір правил в інтерфейсі хмари.

Це означає, що замовник отримує не «налаштування», а версіонований артефакт: його можна покласти в git, прогоняти через рев'ю та відкочувати разом із релізом.

IAM-ролі при цьому залишаються на боці хмари або кластера й пов'язуються з мережевими політиками через явне зіставлення сервісних облікових записів.

Нижче — що саме передаємо на руки після впровадження.

• Конфігурації мережевих політик: L3/L4-правила за мітками подів і просторів імен, L7-правила для HTTP/gRPC з обмеженням методів і шляхів, окремий набір для DNS та egress.
• Схеми потоків трафіку: карта «хто з ким і за яким портом», побудована за фактичними даними спостереження, а не за припущеннями.
• Матриця зіставлення IAM-ролей і сервісних облікових записів: яка роль до якого сервісу прив'язана і які політики її обмежують.
• Регламент зміни політик: порядок рев'ю, обов'язкові перевірки перед застосуванням, процедура відкату до попередньої версії.
• Політики за замовчуванням: режим заборони всього вхідного трафіку з явним списком дозволених напрямків — щоб новий под не отримував доступ «за фактом запуску».
• Інструкції з діагностики: як читати журнал скинутих з'єднань і відрізняти блокування політикою від мережевого збою.
• Чек-лист приймання: перелік сценаріїв, які перевіряються після кожної зміни — доступність сервісів, ізоляція просторів імен, робота зовнішніх інтеграцій.

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

Кейс: перехід на Cilium service mesh без простою

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

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

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

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

Що було до впровадження

• Затримка між сервісами на кожному хопі — через подвійний прохід через проксі.
• Пам'ять і процесорний час ішли на sidecar-контейнери, а не на корисне навантаження.
• Діагностика інцидентів — за логами розрізнених проксі, без єдиної карти зв'язків.
• Шифрування трафіку налаштовувалося вручну для кожного сервісу.

Що змінили

Розгорнули Cilium у режимі, де мережеві політики та маршрутизація працюють на рівні ядра, а mTLS між сервісами вмикається налаштуванням, а не ручною правкою кожного маніфесту.

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

Що стало після

Затримка між сервісами знизилася приблизно на третину на ланцюжках із кількох хопів. Пам'ять, яку займали sidecar-контейнери, вивільнилася — щільність розміщення подів на вузлах зросла. Шифрування трафіку стало поведінкою за замовчуванням, а не окремою задачею на кожен сервіс.

Розбір інциденту скоротився з годин до хвилин: граф потоків у Hubble одразу показує, де рветься зв'язок.

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

Чим Cilium service mesh відрізняється від Istio?

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

Istio історично працює через sidecar-контейнери: поруч із кожним подом піднімається Envoy, який перехоплює трафік і застосовує правила.

Звідси головна архітектурна розбіжність — Cilium вбудовується в ядро і використовує вже наявний мережевий шлях, тоді як Istio додає окремий проксі-шар на кожен под.

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

Cilium прибирає цей шар для L3/L4-політик і балансування, а L7-розбір підключає точково, тільки там, де потрібні правила за HTTP.

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

За mTLS підходи теж розходяться. Istio випускає сертифікати через власний центр і тримає їх у sidecar, шифруючи трафік між подами на рівні проксі.

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

Спостережуваність: у Cilium це Hubble з картою сервісних залежностей і потоків прямо з ядра, у Istio — телеметрія Envoy з багатими мітками, але ціною того ж проксі-шару.

Сценарії вибору такі. Cilium service mesh виграє, коли кластер великий і важлива щільність: менше контейнерів, нижчі затримки, єдина політика мережі та сервісів в одному шарі.

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

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

Часті технічні сумніви при впровадженні

Cilium встановлюється поверх стандартного CNI-інтерфейсу Kubernetes, тому відмовлятися від звичного мережевого шару не потрібно — змінюється лише той, хто реалізує правила.

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

Як відбувається відкат, якщо щось пішло не так?

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

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

Що з безпекою та шифруванням трафіку?

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

Як налагоджувати, якщо трафік не проходить?

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

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

Обговоримо ваше завдання і повернемося з планом

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

Цього достатньо, щоб зрозуміти, чи потрібен вам service mesh поверх eBPF, чи завдання закриває штатний мережевий шар Kubernetes.

Далі працюємо за кроками, і на кожному ви бачите артефакт, а не лише статус у листуванні:

• Розбираємо поточний стан: як влаштована мережа між сервісами, де увімкнено mTLS, які політики вже діють, що показує Hubble.
• Фіксуємо мету у вимірюваних термінах: частка трафіку під взаємною автентифікацією, час реакції на інцидент, глибина історії спостережуваності.
• Пропонуємо схему впровадження: режим заміни мережевого шару, порядок увімкнення політик, точки відкату на кожному етапі.
• Узгоджуємо план за етапами зі зрозумілими критеріями готовності — що має працювати до переходу до наступного кроку.
• Розгортаємо на пілотному контурі: одне середовище, обмежений набір сервісів, повний контроль метрик до і після.
• Переносимо на продуктив зі збереженням можливості повернутися до попередньої конфігурації без простою.
• Передаємо документацію і налаштовуємо моніторинг, щоб команда далі вела систему сама.

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