SDN в Kubernetes: Flannel, Calico, Cilium и OVN-Kubernetes

Обложка

Цикл «Виды связности и SDN», часть 11. Предыдущая часть: «SDN в ЦОД: spine-leaf, EVPN/VXLAN и OVN».

Ось: область — Kubernetes.

Kubernetes задаёт простую модель: pods должны иметь сетевую связность без ручного NAT между каждым контейнером. Как именно пакет попадёт с одного узла на другой, решает CNI и нижележащая сеть.

Режим CrossSubnet и выбор IPIP/VXLAN как транспорта — в части 4. Двойная инкапсуляция WireGuard поверх VXLAN/Geneve — в части 8. Здесь смотрим, что именно прячет слово «CNI».

Flannel

Flannel решает базовую задачу связности pod. Наиболее известный backend — VXLAN. Каждый узел получает свой pod CIDR, а пакеты к удалённому CIDR инкапсулируются и отправляются VTEP другого узла.

Кроме VXLAN есть host-gw: overlay нет, underlay должен маршрутизировать pod CIDR между узлами. Есть backend WireGuard. У VXLAN есть DirectRouting — близкий родственник Calico CrossSubnet: внутри подсети напрямую, через границу — туннель.

Linux Flannel VXLAN обычно слушает UDP/8472, Windows — 4789.

Это хороший вариант, когда нужна понятная базовая сеть, а сложные policies реализуются отдельным компонентом. Возможностей маршрутизации, identity и observability меньше, чем у Calico или Cilium.

Calico

Calico сочетает networking и NetworkPolicy.

Основные варианты data plane:

VXLAN использует UDP/4789 и подходит большему числу сред. В VXLAN mode Calico может не использовать BGP для overlay.

В eBPF mode Calico рекомендует native routing, а если overlay необходим — VXLAN обычно предпочтительнее IPIP. Ограничения IPIP (IPv4, protocol 4, облака) разобраны в части 4.

Cilium

Cilium использует eBPF для forwarding, policies, service load balancing и observability. Он может заменить kube-proxy.

Режимы связности:

В tunnel mode Cilium строит сетку VXLAN/Geneve между узлами. В native mode underlay должен маршрутизировать pod CIDR.

WireGuard не всегда заменяет tunnel protocol. При tunnel mode Cilium сначала инкапсулирует трафик pod в VXLAN/Geneve, затем защищает межузловой поток WireGuard. При native routing остаётся одна инкапсуляция WireGuard. Firewall должен пропускать UDP/51871.

Hubble даёт наблюдаемость на уровне flows и identity, что особенно полезно, когда внешний firewall видит только зашифрованные пакеты между узлами.

OVN-Kubernetes

OVN-Kubernetes использует OVN и Open vSwitch: logical switches, routers, ACL и Geneve overlay. Это мощная модель, близкая к виртуальным сетям OpenStack.

Она удобна для сложной сегментации, logical routing и интеграции с OpenShift. Цена — больше компонентов и необходимость понимать OVN databases, logical flows и поведение gateway.

NetworkPolicy не является шифрованием

NetworkPolicy определяет, кто может обращаться к кому. Она не обязана шифровать разрешённый поток.

Шифрование не заменяет policy: зашифрованный пакет от неразрешённого workload всё равно должен быть заблокирован.

Нужны обе оси:

Как выбирать

Нужна простая базовая overlay-сеть: Flannel VXLAN.

Нужны BGP, гибридные режимы и зрелая NetworkPolicy: Calico.

Нужны eBPF, observability, service load balancing и identity-aware policy: Cilium.

Нужна модель logical switches/routers OVN или используется OpenShift: OVN-Kubernetes.

Но продукт выбирают после проверки среды:

Минимальная проверка перед production

  1. Pod-to-pod между узлами.
  2. Service и NodePort при локальном и удалённом backend.
  3. MTU и большие TCP-пакеты.
  4. NetworkPolicy для ingress и egress.
  5. Отказ одного node.
  6. Смена маршрута или AZ.
  7. Шифрование и фактический внешний transport.
  8. Throughput, PPS и CPU.

Где это ломается

Кластер закончился, каналов между площадками несколько — дальше это уже выбор пути. В следующей части выйдем к SD-WAN.

Предыдущая часть: «SDN в ЦОД: spine-leaf, EVPN/VXLAN и OVN»

Оглавление цикла: «SDN без магии: карта видов связности»

Следующая часть: «SD-WAN: связность филиалов, ЦОДов и облаков»

Схема

#network #selfhosting