В 2026 году выбор CNI (Container Network Interface) для Kubernetes — это уже не «какой плагин раздаёт IP». CNI определяет, как будет работать сервисная маршрутизация, как быстро применяются NetworkPolicy, какие у вас есть инструменты наблюдаемости, и насколько предсказуемо всё это обновляется и дебажится.
Ниже — практическое сравнение трёх популярных вариантов: Cilium, Calico и kube-router. Я буду смотреть на вещи глазами админа/DevOps: дата-плейн (iptables/IPVS vs eBPF), замена kube-proxy, поддержка политик, задержки и масштабирование, observability и шифрование east-west.
Как читать сравнение: что реально важно в 2026
Перед выбором «лучшего CNI» полезно зафиксировать критерии, которые чаще всего ломают прод при росте кластера или при ужесточении безопасности.
1) Дата-плейн: iptables/IPVS или eBPF
Calico и kube-router в типовых режимах опираются на классический стек Linux networking (маршрутизация и правила через iptables/IPVS). Cilium делает ставку на eBPF: пакеты обрабатываются на другом «слое», меняются подходы к балансировке, политике и диагностике.
eBPF в 2026 уже зрелый, но требует дисциплины: версии ядра, параметры, апгрейды. Если у вас «зоопарк» дистрибутивов/ядер между нодами, это станет фактором.
2) Service load-balancing: нужен ли kube-proxy
Стандартно сервисы Kubernetes реализуются через kube-proxy, который программирует iptables или IPVS. На небольших кластерах это часто нормально. На больших — можно столкнуться с ростом количества правил, временем их перепрограммирования и сложностью диагностики (особенно когда много сервисов, endpoint’ов и churn).
Отсюда вопрос: нужен ли вам kube-proxy replacement как проектное решение, или лучше оставить «классику» и решать проблемы точечно.
3) Политики безопасности: NetworkPolicy и «качество поддержки»
Поддержка Kubernetes NetworkPolicy на бумаге есть у многих. В эксплуатации важнее другое:
- скорость применения правил (convergence) при изменениях;
- насколько удобно понять «почему пакет не прошёл»;
- сценарии egress, DNS, FQDN-политики и практичность дебага.
4) Наблюдаемость и дебаг сетевых проблем
Чем больше микросервисов, тем дороже становится «слепая» сеть. В 2026 observability — это не роскошь, а способ сокращать MTTR. Для Cilium ключевой элемент — Hubble. Для Calico/kube-router чаще строят наблюдаемость из метрик, логов и внешних инструментов.
5) Шифрование трафика: WireGuard и IPsec
Если вам нужно шифровать east-west (между нодами/подами), CNI становится одним из основных рычагов. И тут важны не лозунги, а эксплуатация:
- что поддерживается нативно и насколько это легко катать в прод;
- предсказуемость нагрузки на CPU;
- влияние на MTU/фрагментацию и удобство диагностики.
Коротко о каждом: кто они и где применяются
Cilium
Cilium — eBPF-ориентированный CNI, который часто рассматривают как «платформу дата-плейна»: сеть, политики и observability идут в одном наборе. Практически это означает меньше iptables-магии, возможность (при желании) отказаться от kube-proxy и сильный упор на наблюдаемость потоков.
Обычно Cilium выбирают, когда важны видимость трафика, зрелая диагностика и есть интерес к eBPF-подходу и/или замене kube-proxy.
Calico
Calico — один из самых распространённых вариантов в проде. Его часто ценят за предсказуемость и понятное поведение на классическом Linux networking. Важно и то, что у многих команд уже есть опыт эксплуатации Calico, а значит ниже риски внедрения.
Calico обычно выбирают, когда нужна стабильная база для NetworkPolicy и маршрутизации без радикального изменения модели (и требований) дата-плейна.
kube-router
kube-router — «компактный» вариант, совмещающий функции, которые часто разнесены по нескольким компонентам (включая реализацию сервисов в своей модели). Его выбирают, когда хотят минимализм, меньше движущихся частей и контролируемую простую топологию — чаще в небольших кластерах или специализированных установках.
kube-router хорошо заходит там, где важна простота и вы заранее принимаете более скромную экосистему по tooling и интеграциям.
Если вы строите кластер на собственных нодах, заранее оцените требования к ядру, MTU и сетевым режимам: на VDS эти параметры обычно полностью под вашим контролем, и это сильно упрощает стандартизацию дата-плейна (особенно для eBPF и шифрования).
Сравнение Cilium, Calico и kube-router по ключевым критериям
Ниже — эксплуатационная выжимка без маркетинга. Конкретика зависит от версий и режимов, но общий смысл для 2026 такой.
- Дата-плейн: Cilium — eBPF; Calico — классический Linux networking с iptables/IPVS (в зависимости от режима); kube-router — маршрутизация + iptables/IPVS.
- Замена kube-proxy: Cilium — распространённый сценарий; Calico — чаще оставляют kube-proxy; kube-router — реализует сервисную модель в своём подходе (часто без отдельного «replacement» как у Cilium, но с похожей целью уменьшить зависимость от kube-proxy).
- NetworkPolicy: Cilium — сильная связка политики + диагностика потоков; Calico — зрелая и привычная реализация; kube-router — базовые сценарии, но меньше возможностей и tooling.
- Производительность/задержки: Cilium часто выигрывает на масштабных кластерах и сложных политиках; Calico обычно даёт стабильное, понятное поведение; kube-router может быть эффективен в простых топологиях, но функциональный «потолок» ниже.
- Observability: Cilium (Hubble) даёт преимущество «из коробки»; Calico/kube-router чаще требуют внешней обвязки и ручной диагностики.
- Шифрование east-west: Calico часто выбирают за практичную эксплуатацию WireGuard; Cilium тоже умеет шифрование (варианты зависят от режима); kube-router обычно закрывают шифрование другими слоями.
- Сложность эксплуатации: Cilium — выше (режимы, ядро, eBPF-пайплайн); Calico — средняя и привычная; kube-router — меньше компонентов, но можно раньше упереться в ограничения/особенности.
eBPF на практике: что даёт Cilium и где «цена входа»
Практические плюсы eBPF-подхода в Cilium обычно проявляются не в «пиковом throughput», а в управляемости и дебаге:
- меньше зависимости от огромных наборов iptables-правил;
- лучше наблюдаемость потоков и причин дропа;
- гибкость в сервисной балансировке и политике, вплоть до сценария без kube-proxy.
Но и плата понятная:
- версии ядра и совместимость: вам нужен стандарт на уровне образов нод и регулярные обновления без сюрпризов;
- много режимов: важно не получить разные профили включений по кластерам без документации и контроля дрейфа;
- дебаг меняется: вместо «посмотрел iptables» вы чаще будете работать через инструменты Cilium/Hubble и eBPF-диагностику.
Если вы хотите глубже разобраться в диагностике eBPF-инструментами, держите в закладках материал про eBPF-диагностику bcc/bpftrace: это сильно помогает, когда проблема уходит на уровень ядра и потоков.
kube-proxy replacement: когда это действительно нужно
Замену kube-proxy обычно рассматривают в двух ситуациях:
- кластер растёт, и iptables/IPVS начинают мешать: долгое перепрограммирование, сложная диагностика, деградация при большом churn;
- вам нужна более прозрачная наблюдаемость «сервис → поды» и понятный ответ, где именно ломается поток.
В случае Cilium kube-proxy replacement — рабочий и распространённый путь. Но это не «галочка», а изменение сетевого слоя: заложите пилот, тесты отказов и проверку совместимости с ingress/gateway.
Из практики пилота полезно отдельно замерять:
- время сходимости при массовых изменениях endpoints;
- поведение при rolling upgrade нод;
- влияние на p95/p99 задержек сервисного трафика.
Если в вашем кластере активно используется IPVS или вы планируете L4-сценарии, пригодится отдельная шпаргалка по IPVS и L4-балансировке — чтобы сравнивать с eBPF-подходом на одинаковых терминах.
NetworkPolicy: где чаще всего болит внедрение
Редкая команда начинает с идеальной модели политик. Чаще всё начинается с «default deny» в отдельных namespace и постепенного открытия нужных направлений. Поэтому в проде важны скорость итераций и качество диагностики.
Cilium
Сильная сторона — связка политика + наблюдаемость. Когда трафик режется, важно быстро понять, это DNS, egress, межнеймспейсовый доступ или конкретный L4-порт. За счёт Hubble и eBPF-телеметрии разбор обычно быстрее.
Calico
Calico хорош, когда нужны воспроизводимые правила и «классическое» поведение на уровне Linux networking. Командам, которые уже уверенно живут с iptables/IPVS/conntrack, часто проще эксплуатировать и дебажить именно такой профиль.
kube-router
Базовые сценарии политик закрываются, но при росте требований к сегментации и удобству расследований вы можете раньше упереться в ограничения и нехватку инструментов.
Производительность и задержки: что сравнивать правильно
Запрос «у кого быстрее» часто приводит к неправильным бенчмаркам. Для CNI важнее:
- стабильность задержек (p95/p99) под нагрузкой;
- время применения политик и восстановления связности после изменений;
- поведение при большом количестве сервисов и endpoints;
- накладные расходы на observability и шифрование.
Если кластер небольшой и политики простые, разница между Calico и Cilium может быть вторичной. Если вы растёте по количеству сервисов/политик и требованию «видеть сеть», eBPF-подход обычно начинает выигрывать именно по управляемости и предсказуемости.
Observability: почему Hubble часто меняет эксплуатацию
Козырь Cilium — Hubble: потоковая видимость сетевых событий и причин отказов. В проде это обычно превращается в:
- быстрее RCA (какая политика сработала, где дроп, кто и куда ходит);
- контроль изменений (после деплоя или правки NetworkPolicy видите ошибки и блокировки на уровне потоков).
В Calico и kube-router наблюдаемость чаще собирают «снизу вверх»: метрики нод/подов, логи компонентов, трассировка приложения, плюс tcpdump/conntrack по необходимости. Это работает, но обычно увеличивает стоимость времени на расследования.
Шифрование east-west: WireGuard и IPsec как операционная задача
Шифрование — это не «включил и забыл». В эксплуатации важно, как вы доказываете, что оно действительно работает, и что будет при обновлениях, проблемах с MTU и нагрузке.
- как устроена ротация ключей и где это мониторить;
- как диагностировать проблемы MTU/фрагментации;
- какой будет overhead CPU на вашем профиле трафика;
- как быстро вы найдёте «почему часть подов шифруется, а часть нет» (если такое возможно в вашей схеме).
Если нужен относительно простой operational-профиль шифрования east-west, Calico часто рассматривают из-за практичного опыта с WireGuard. Cilium тоже закрывает шифрование, но встраивается в более богатую модель дата-плейна, и это может быть плюсом (единая платформа), либо усложнением (больше режимов и точек контроля).
Если вы публикуете сервисы вовне, не путайте шифрование east-west и TLS на входе. Для внешних endpoints обычно нужен нормальный TLS-контур, и проще всего закрывать это через проверенные SSL-сертификаты и понятный процесс ротации.
Operational complexity: где вас будут ждать сюрпризы
Честное сравнение по сложности эксплуатации — это список вопросов, которые всплывают после внедрения, а не в день установки.
Стандартизация режимов и конфигурации
У Cilium реально больше вариантов: режимы балансировки, включение/выключение kube-proxy replacement, настройки наблюдаемости, шифрование. Без внутреннего стандарта легко получить разные «профили кластера» и разный опыт расследования инцидентов.
Компетенции команды по сетевому дебагу
Если команда уверенно работает с iptables/IPVS, маршрутизацией и conntrack, то Calico и kube-router будут ближе к привычному миру. В Cilium инструментарий и мышление смещаются к eBPF: это даёт мощную видимость, но требует обучения и дисциплины по версиям ядра.
Обновления и откаты
Сетевой слой должен обновляться так же регулярно, как Kubernetes. Заранее проверьте:
- совместимость с вашим ядром/дистрибутивом;
- поведение при rolling upgrade нод;
- наличие понятного плана отката (и отработку этого плана на тестовом контуре).
Рекомендации по выбору: 6 типовых сценариев
1) Нужны топовая observability и контроль потоков
Чаще всего это путь к Cilium (особенно если вы хотите Hubble и более «прозрачный» RCA сетевых проблем).
2) Нужна зрелая «классическая» сеть и привычная NetworkPolicy
Обычно выигрывает Calico: предсказуемо, широко распространено, проще найти опыт и понятные практики эксплуатации.
3) Малый кластер, минимум компонентов, простая маршрутизация
kube-router может быть разумным выбором, если вы осознанно выбираете минимализм и готовы к более скромной экосистеме инструментов.
4) Большой кластер, много сервисов, kube-proxy становится узким местом
Сильный аргумент в пользу Cilium и kube-proxy replacement, но с обязательным пилотом и тестированием отказов.
5) Жёсткие требования к сегментации и egress-контролю
И Cilium, и Calico подойдут. Выбор обычно упирается в приоритет: максимальная видимость и eBPF-пайплайн (Cilium) или классическая зрелость и привычный operational-профиль (Calico).
6) Шифрование east-west обязательно
Смотрите не только на «умеет», а на то, как вы это будете мониторить и дебажить: CPU, MTU, ротации ключей, аварии при обновлениях. На практике чаще сравнивают Cilium и Calico; kube-router реже закрывает эту задачу «из коробки».
Как выбрать безопасно: мини-чеклист пилота
Если есть возможность, делайте пилот. Он почти всегда окупается.
- Функционал: Ingress/Gateway, сервисы, Stateful-нагрузки, DNS, egress.
- NetworkPolicy: default deny, разрешение DNS, доступ к базам/кешам, запрет межнеймспейсовых соединений.
- Инцидент-симуляции: ротация ноды, пропадание интерфейса, packet loss, перегруз conntrack (если актуально).
- Наблюдаемость: сколько времени занимает ответить на вопрос «почему под A не ходит в сервис B».
- Шифрование (если нужно): overhead CPU, влияние на MTU, диагностируемость.
- Операционные процессы: обновление, откат, стандартизация конфигов, обучение команды.
Итог: «лучший CNI» зависит от зрелости и целей
В сравнении Cilium/Calico/kube-router нет победителя «в вакууме»:
- Cilium — когда вам нужен современный eBPF-дата-плейн, сильная observability и вы готовы управлять режимами (включая kube-proxy replacement) и требованиями к ядру.
- Calico — когда важны зрелость, предсказуемость, привычный operational-профиль и понятная реализация NetworkPolicy без резких изменений модели сети.
- kube-router — когда вы осознанно ставите на простоту и компактность, а требования к расширенной наблюдаемости и сложным policy-сценариям умеренные.
Главный совет на 2026: выбирайте не только «по фичам», а по тому, как вы будете жить с этим дата-плейном 2–3 года — обновляться, дебажить и держать предсказуемые задержки под нагрузкой.
