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. Отдельно важны окна обслуживания и допустимое время простоя — от этого зависит, идём мы поэтапно, контур за контуром, или меняем сетевой слой на выделенном стенде, а потом переносим прод.

По итогам разбора возвращаемся с пакетом, в котором:

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

План отдаём документом с этапами, зависимостями и зонами ответственности, плюс разбираем его на созвоне с вашими инженерами — чтобы спорные места снялись до старта, а не в момент переключения.

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