Есть в мире Kubernetes вещи вечные.

Например:

  • разработчик, который «ничего не менял»;
  • DevOps-инженер, который в 02:47 смотрит tcpdump с глазами человека, увидевшего бездну;
  • и выбор CNI-плагина, который превращается в религиозный спор похлеще Vim против Nano.

Каждый Kubernetes-кластер рано или поздно приходит к вопросу:

А что вообще ставить для сети?

И тут появляются три всадника инфраструктурного апокалипсиса:

  • Flannel - простой деревенский трактор;
  • Calico - суровый корпоративный безопасник;
  • Cilium - киберпанк из будущего на eBPF.

Причем смешно то, что все три решают одну и ту же задачу: они заставляют контейнеры общаться друг с другом так, будто Kubernetes - не куча серверов, а единый организм.

Хотя внутри это часто напоминает попытку связать синей изолентой датацентр, Linux-сеть и психическое состояние дежурного инженера.

Зачем вообще нужен CNI в Kubernetes

Начнем с базы.

Kubernetes сам по себе сетью не занимается. Вообще.

Он такой:

«Вот тебе Pod. А дальше разбирайтесь сами.»

Именно поэтому существует CNI - Container Network Interface.

CNI отвечает за:

  • выдачу IP адресов Pod’ам;
  • маршрутизацию;
  • связь между нодами;
  • NetworkPolicy;
  • NAT;
  • overlay/network fabric;
  • шифрование;
  • балансировку;
  • observability;
  • иногда вообще половину датацентра.

Если убрать CNI - Pods будут жить как соседи в панельке, которые не знают о существовании друг друга.

Почему выбор сети - это важно

На маленьком кластере из трех нод почти все работает одинаково. На проде начинается самое веселье.

Появляются:

  • тысячи Pod;
  • сотни namespace;
  • сервис-меши;
  • ingress;
  • базы данных;
  • Kafka;
  • Ceph;
  • monitoring;
  • security-аудиты;
  • multi-cluster;
  • east-west traffic;
  • VPN;
  • WireGuard;
  • BGP;
  • VXLAN;
  • MTU mismatch;
  • packet fragmentation;
  • conntrack overflow;
  • и легендарное: «Иногда просто отваливается сеть, но только по четвергам».

И вот тут внезапно выясняется: сеть Kubernetes - это уже не «какая-то настройка». Это фундамент всего кластера.

Flannel - дедовский автомат Калашникова

Что такое Flannel

Flannel - один из самых старых и простых CNI для Kubernetes.

Главная идея Flannel:

«Сделать сеть максимально тупой и максимально рабочей.»

И знаете что?

Это великолепная философия.

Flannel не пытается быть:

  • service mesh;
  • firewall;
  • IDS;
  • observability платформой;
  • SDN из NASA.

Он просто дает Pod’ам сеть. И все.

Как работает Flannel

Flannel строит overlay-сеть между нодами.

Обычно через:

  • VXLAN
  • host-gw
  • WireGuard (реже)

Самый популярный вариант - VXLAN.

Схема выглядит примерно так:

Pod -> veth -> bridge -> vxlan -> другая нода -> Pod

То есть пакеты инкапсулируются внутрь VXLAN.

  • Это просто.
  • Это надежно.
  • Это медленно.
  • Но надежно.

Плюсы Flannel

1. Простота

Flannel - это буквально:

kubectl apply -f kube-flannel.yml

И оно работает.

Никаких:

  • CRD на 900 строк;
  • eBPF maps;
  • BGP peering;
  • route reflectors;
  • философских вопросов о природе dataplane.

Иногда это огромный плюс.

2. Минимальное потребление ресурсов

Flannel очень легкий.

Он не жрет:

  • CPU;
  • память;
  • conntrack как не в себя;
  • душу DevOps-инженера.

Для маленьких кластеров - идеально.

3. Хорош для edge и homelab

Если у вас:

  • k3s;
  • Raspberry Pi;
  • mini cluster;
  • тестовая среда;
  • небольшой internal cluster;

то Flannel - отличный выбор.

Минусы Flannel

1. Почти нет security

И вот тут начинается: «А кто вообще может ходить к базе данных?»

Ответ: «Да кто угодно.»

У Flannel historically почти отсутствует нормальная реализация NetworkPolicy.

Да, сейчас есть костыли через другие компоненты. Но нативно Flannel - не про безопасность.

2. Overlay дает overhead

VXLAN - это дополнительная инкапсуляция.

А значит:

  • overhead по CPU;
  • overhead по MTU;
  • fragmentation;
  • latency.

На маленьких нагрузках это незаметно. На highload - уже очень даже.

3. Нет advanced networking

Flannel - это:

  • минимум фич;
  • минимум контроля;
  • минимум observability.

Если вам нужны:

  • zero trust;
  • microsegmentation;
  • BGP;
  • advanced policies;
  • observability;

то Flannel скажет: «Брат, я вообще-то трактор.»

Когда использовать Flannel

Flannel хорош когда:

  • маленький кластер;
  • low-cost инфраструктура;
  • homelab;
  • edge;
  • тестовые стенды;
  • простая инфраструктура;
  • нет строгих security требований.

Calico - корпоративный безопасник с папкой регламентов

Calico - это уже совсем другой уровень.

Если Flannel - деревенский механик, то Calico - архитектор enterprise-сетей с сертификатами, аудитами и PTSD после PCI DSS.

Главная идея Calico

Calico делает ставку не на overlay, а на routing.

Главная философия: «Зачем инкапсулировать пакеты, если можно нормально маршрутизировать?»

И это очень мощная идея.

Как работает Calico

Calico может работать:

  • без overlay;
  • через BGP;
  • через VXLAN;
  • через IP-in-IP;
  • mixed mode.

Самая знаменитая фича - BGP. Ноды Kubernetes обмениваются маршрутами как полноценные роутеры. Это уже почти SDN.

Что это дает

  • Производительность
  • Нет VXLAN overhead.
  • Нет лишней инкапсуляции.
  • Меньше latency.
  • Меньше CPU.
  • Для highload это огромный плюс.

Гибкость

Calico умеет:

  • NetworkPolicy;
  • GlobalPolicy;
  • microsegmentation;
  • multi-cluster;
  • encryption;
  • BGP peering;
  • route advertisement;
  • external fabric integration.

То есть это уже не «сеть для Pod». Это полноценная platform networking solution.

Почему Calico любят безопасники

Потому что NetworkPolicy в Kubernetes без нормального CNI - это лотерея.

Calico позволяет делать:

deny all
allow only frontend -> backend
allow monitoring
block everything else

И это работает. В enterprise это критично. Особенно когда приходит ИБ и задает вопрос:

«Почему staging может ходить в production PostgreSQL?»

А ты такой:

«Потому что Kubernetes верит в дружбу.»

Минусы Calico

1. Сложность

Calico может быть:

  • простым;
  • средним;
  • адом.

Все зависит от того, насколько глубоко вы полезли.

BGP внезапно открывает портал в мир:

  • routing;
  • ECMP;
  • MTU;
  • route reflectors;
  • asymmetric routing;
  • blackhole routes.

И вот уже Kubernetes-инженер превращается в сетевика. А это опасная мутация.

2. Debugging сложнее

С Flannel:

tcpdump

С Calico:

birdcl
ip route
calicoctl
iptables
bgpctl

Через пару часов инженер начинает разговаривать с маршрутами.

3. iptables scaling

Исторически Calico сильно завязан на iptables.

А iptables:

  • плохо масштабируется;
  • любит большие таблицы;
  • жрет CPU;
  • вызывает latency spikes.

Особенно на огромных кластерах.

Когда использовать Calico

Calico - отличный выбор если:

  • enterprise;
  • compliance;
  • безопасность;
  • multi-tenant cluster;
  • production;
  • highload;
  • bare metal;
  • нужны NetworkPolicy;
  • нужна интеграция с существующей сетью.

Cilium - киберпанк на eBPF

Cilium - это уже не просто CNI.

Это:

  • networking;
  • security;
  • observability;
  • load balancing;
  • service mesh;
  • tracing;
  • kernel magic;
  • немного черной магии.

Что такое eBPF

Если кратко:

eBPF позволяет запускать код прямо внутри Linux kernel.

Не через:

  • iptables;
  • userspace;
  • legacy networking stack.

А напрямую внутри ядра. И это переворачивает вообще все.

Почему все сейчас говорят про eBPF

Потому что iptables начинает умирать на больших масштабах.

Когда у вас:

  • десятки тысяч rules;
  • тысячи Pod;
  • огромный east-west traffic;

iptables превращается в печку.

А eBPF работает сильно эффективнее.

Что умеет Cilium

1. Очень высокая производительность

Cilium умеет:

  • kube-proxy replacement;
  • direct routing;
  • eBPF load balancing;
  • XDP acceleration.

На больших кластерах разница может быть огромной.

2. Фантастическая observability

Hubble в составе Cilium - это просто праздник.

Можно видеть:

  • кто куда ходит;
  • какие DNS запросы;
  • latency;
  • drops;
  • policies;
  • flows.

И все это красиво. Иногда даже слишком красиво для инфраструктуры.

Пример мышления Cilium

Flannel: «Вот пакет.»

Calico: «Вот маршрутизируемый пакет.»

Cilium: «Вот packet flow с metadata, identity, policy context и observability pipeline.»

Security в Cilium

Cilium умеет policy на уровне:

  • IP;
  • Pod;
  • namespace;
  • DNS;
  • HTTP;
  • L7.

То есть можно написать:

  • разрешить только GET /api
  • запретить POST

И это уже уровень service mesh.

Почему Cilium сейчас хайповый

Потому что:

  • cloud-native рынок растет;
  • eBPF развивается;
  • hyperscaler любят eBPF;
  • Kubernetes становится огромным;
  • observability важнее с каждым годом.

Сейчас многие новые production-кластеры сразу стартуют на Cilium.

Минусы Cilium

1. Сложность

Cilium - это уже не просто CNI.

Это:

  • Linux kernel internals;
  • eBPF;
  • dataplane;
  • maps;
  • tracing;
  • kube-proxy replacement;
  • tc hooks;
  • XDP.

Если junior-инженер случайно откроет документацию Cilium - можно услышать, как у него в голове падает segmentation fault.

2. Требования к kernel

Старые ядра Linux? - Проблемы.

Древний enterprise-дистрибутив? - Проблемы.

Kernel modules? - Проблемы.

eBPF требует современную инфраструктуру.

3. Отладка - отдельное искусство

Если Flannel дебажится молотком, Calico - отверткой, то Cilium - квантовой физикой.

Когда использовать Cilium

Cilium прекрасен если:

  • большие Kubernetes-кластеры;
  • highload;
  • cloud-native;
  • observability;
  • zero trust;
  • service mesh;
  • microservices;
  • multi-cluster;
  • modern Linux kernels;
  • platform engineering.

Что выбрать в реальной жизни

И вот тут начинается самое интересное.

Потому что: «Лучшего CNI не существует.» Есть подходящий.

Flannel выбирают когда

  • Нужно быстро
  • Нужно просто
  • Нужно дешево
  • Нужно надежно

Это Kubernetes без лишней философии.

Calico выбирают когда

  • Нужна безопасность
  • Нужны политики
  • Нужен enterprise
  • Нужен контроль

Это корпоративный Kubernetes.

Cilium выбирают когда

  • Нужен максимум производительности
  • Нужен modern stack
  • Нужен observability next-gen
  • Нужен eBPF

Это Kubernetes из будущего.

А теперь суровая правда инфраструктуры

Большинство проблем Kubernetes-сети не из-за CNI.

А из-за:

  • кривого MTU;
  • broken routing;
  • overlay поверх overlay;
  • firewall;
  • asymmetric routing;
  • conntrack;
  • cloud networking;
  • VPN поверх VXLAN поверх IPSec поверх WireGuard.

И конечно: «Мы просто взяли дефолтные настройки.»

Самый главный совет

Не выбирайте CNI по хайпу.

Потому что:

  • маленькому кластеру не нужен Cilium;
  • enterprise не выживет на голом Flannel;
  • Calico не нужен Raspberry Pi-кластеру на балконе.

Сеть Kubernetes - это всегда компромисс между:

  • сложностью;
  • производительностью;
  • безопасностью;
  • observability;
  • ресурсами;
  • квалификацией команды.

И вот последний пункт - самый важный.

Потому что можно поставить самый модный eBPF networking stack в мире.

Но если команда не умеет его дебажить - в три часа ночи все равно будете сидеть в tcpdump, смотреть на VXLAN-пакеты и шептать:

«Ну пожалуйста… ну пинганись…»