Cilium kompletně nahrazuje kube-proxy a tradiční iptables tím, že integruje logiku síťování, observability a zabezpečení přímo do linuxového kernelu pomocí eBPF. Místo procházení řetězců pravidel v iptables je každý paket zpracováván optimalizovanými eBPF programy připojenými ke klíčovým bodům v síťovém stacku kernelu. Tento přístup dramaticky snižuje režii a latenci.

Hlavními vstupními body pro zpracování paketů jsou hooky eXpress Data Path (XDP) a Traffic Control (TC). XDP se aktivuje na nejnižší možné úrovni, přímo v ovladači síťové karty, ještě předtím, než kernel alokuje struct sk_buff. To umožňuje extrémně rychlé akce, jako je odhození paketů pro mitigaci DDoS nebo přesměrování pro load balancing. TC hooky naopak operují na úrovni ingress a egress front síťového rozhraní a pracují s plným kontextem sk_buff, což je ideální pro komplexní logiku síťových politik a transparentní šifrování.

eBPF programy běžící v kernelu jsou ze své podstaty bezstavové. Pro ukládání stavových informací, jako jsou překlady služeb, data pro sledování spojení (conntrack) nebo mapování bezpečnostních identit, využívá Cilium eBPF mapy. Tyto mapy jsou efektivní datové struktury klíč-hodnota, které existují v paměti kernelu a jsou přístupné jak pro eBPF programy, tak pro procesy v uživatelském prostoru, jako je cilium-agent.

cilium-agent sleduje stav clusteru (např. pody, služby, politiky) a překládá je do datových struktur, které zapisuje do eBPF map. eBPF programy pak tyto mapy čtou při zpracování paketů, aby mohly učinit správná rozhodnutí. Tento mechanismus umožňuje dynamicky aktualizovat pravidla datapathu bez nutnosti rekompilace nebo znovunačítání eBPF programů.

Cilium využívá několik typů map, z nichž každý je optimalizován pro konkrétní účel:

• Hash Maps: Používají se pro rychlé vyhledávání (O(1)) pro data jako záznamy conntrack, mapování služeb na backendy a mapování IP adres na bezpečnostní identity.
• LPM Tries (Longest Prefix Match): Nezbytné pro efektivní implementaci síťových politik založených na CIDR. Umožňují rychle najít nejkonkrétnější shodující se síťový prefix pro danou IP adresu.

eBPF programy mají omezení na počet instrukcí (dnes 1 milion), aby byla zajištěna jejich rychlá exekuce a aby se předešlo nekonečným smyčkám. Pro implementaci komplexní logiky, která by toto omezení překročila, využívá Cilium mechanismus zvaný tail calls (ocasová volání). Tail call umožňuje jednomu eBPF programu předat exekuci jinému eBPF programu bez návratu do původního programu. Je to v podstatě goto v kernelu.

Tento přístup umožňuje Cilium rozdělit logiku zpracování paketů do menších, specializovaných a znovupoužitelných eBPF programů. Například hlavní TC program může nejprve určit, zda je paket IPv4 nebo IPv6, a poté pomocí tail call skočit do specializovaného programu pro daný protokol. Tím se udržuje kód čistý, modulární a lépe se spravuje.

Pojďme si projít zjednodušenou cestu paketu přicházejícího z vnější sítě do podu spravovaného Ciliem:

1. Driver & XDP: Paket dorazí na síťovou kartu. Pokud je aktivní, eBPF program na XDP hooku provede první kontrolu. Může paket zahodit (DDoS ochrana), nebo pokud se jedná o provoz pro službu typu NodePort nebo LoadBalancer, může provést rychlý DNAT a přesměrovat paket přímo na backendový pod (obejde tak zbytek síťového stacku).

2. TC Ingress: Pokud paket projde XDP, je předán do hlavního síťového stacku kernelu. Zde je zpracován eBPF programem na TC ingress hooku. Tento program provede několik kroků:

   • Dekapsulace: Pokud je paket součástí overlay sítě (např. VXLAN), je zde dekapsulován.
   • Ověření identity: Z eBPF mapy (hash map) se načte bezpečnostní identita na základě zdrojové IP adresy. U lokálního provozu je identita získána přímo z metadat soketu.
   • Vynucení politiky: Pomocí zdrojové a cílové identity se v další mapě ověří, zda je komunikace povolena síťovou politikou.
   • Překlad služby (Service NAT): Pokud je cíl paketu IP adresa služby, eBPF program vyhledá v mapě služeb aktivní backend a provede DNAT, čímž nahradí cílovou IP a port adresou konkrétního podu.

3. Doručení do podu: Kernel doručí modifikovaný paket do síťového jmenného prostoru cílového podu.

Odchozí provoz z podu prochází podobným, ale reverzním procesem na TC egress hooku, kde se aplikují egress politiky, provede se SNAT a případná enkapsulace do overlay sítě. Díky této architektuře je Cilium schopno dosáhnout téměř nativního síťového výkonu a zároveň poskytovat bohaté L3/L4 a dokonce i L7 síťové služby.

Otestujte si své znalosti klíčových mechanismů, které tvoří datapath Cilium.