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.
• Фиксируем цель в измеримых терминах: доля трафика под взаимной аутентификацией, время реакции на инцидент, глубина истории наблюдаемости.
• Предлагаем схему внедрения: режим замены сетевого слоя, порядок включения политик, точки отката на каждом этапе.
• Согласуем план по этапам с понятными критериями готовности — что должно работать до перехода к следующему шагу.
• Разворачиваем на пилотном контуре: одна среда, ограниченный набор сервисов, полный контроль метрик до и после.
• Переносим на продуктив с сохранением возможности вернуться к прежней конфигурации без простоя.
• Передаём документацию и настраиваем мониторинг, чтобы команда дальше вела систему сама.

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