← Späť na blog
Networking4 min čítania

Cilium a eBPF na bare-metal Kubernetes: siete bez cloudového load balancera

kubernetesciliumebpfnetworkingon-prem

Keď staviaš Kubernetes v cloude, type: LoadBalancer je vyriešený problém — cloud ti pridelí IP a hotovo. Na bare-metale to nemáš. Žiadny cloud-controller, žiadna externá IP, len holé servery, switch a tvoja vlastná sieť. Postavil som produkčnú on-prem platformu na RKE2 a tu je to, čo skutočne funguje.

eBPF a prečo na ňom záleží

eBPF je technológia, ktorá ti dovolí spúšťať malé sandboxované programy priamo v jadre Linuxu — bez patchovania jadra, bez kernel modulov. Pre siete to znamená, že packety vieš spracovať v dátovej ceste jadra namiesto reťazenia desiatok iptables pravidiel v userspace logike. Cilium je CNI postavené presne na tomto.

Cilium nahrádza kube-proxy

Klasický kube-proxy programuje routing služieb cez iptables. Pri tisíckach Services to znamená lineárne dlhý reťazec pravidiel, ktorý jadro prechádza pri každom spojení — O(n) vyhľadávanie, ktoré pri škálovaní bolí. Cilium to nahrádza eBPF hash mapami: vyhľadanie backendu je v praxi O(1) a programovanie pravidiel je rádovo rýchlejšie.

Dôležitý detail z praxe: režim sa konfiguruje cez kubeProxyReplacement: true (alebo false). Staré hodnoty strict, partial a disabled boli odstránené v Cilium 1.16. Ak migruješ z návodov spred dvoch rokov, narazíš na validačnú chybu. true znamená, že agent pri štarte spadne, ak jadro nemá potrebné featury — čo je presne to, čo chceš na produkcii vidieť hneď, nie potichu.

Kube-proxy replacement nie je len výkonová vec — je to podmienka pre L2 Announcements nižšie.

Bare-metal problém: odkiaľ vezmeš externú IP?

Bez cloudu má type: LoadBalancer Service navždy stav <pending>. Nikto IP nepridelí. Historicky sa to riešilo cez MetalLB. Dnes, ak už beží Cilium s kube-proxy replacementom, nepotrebuješ ďalší komponent — Cilium to vie sám.

LB IPAM rieši prideľovanie IP. Definuješ CiliumLoadBalancerIPPool s rozsahom adries z tvojej siete a Cilium z neho automaticky prideľuje IP každej LoadBalancer Service. Pool vyberaj rozumne — adresy musia byť v rovnakom L2 segmente ako nody a nesmú kolidovať s DHCP ani s existujúcimi statickými IP. Toto je najčastejší zdroj záhadných konfliktov.

L2 Announcements rieši dosiahnuteľnosť. Pridelená IP je zbytočná, ak o nej switch nevie. CiliumL2AnnouncementPolicy povie Ciliu, aby odpovedal na ARP (IPv4) a NDP (IPv6) dotazy pre VIP služieb. Pozor — externalIPs aj loadBalancerIPsdefault false, takže prázdna politika neoznamuje nič. A nezabudni na --devices (Helm), inak Cilium nevie, na ktorom rozhraní má ARP posielať.

Gotchas okolo L2 Announcements

Toto ma stálo najviac času:

  • Odpovedá vždy len jeden nod. Pre danú Service IP drží ARP práve jeden nod, vybraný cez Kubernetes lease (cilium-l2announce-<namespace>-<service> v kube-system). Funguje to ako keepalived — žiadny load balancing pred klastrom, jeden nod je north/south brána.
  • Failover má svoje časovanie. Riadia ho leaseDuration (default 15s), leaseRenewDeadline (5s) a leaseRetryPeriod (2s). Pri výpadku leadra je okno výpadku rádovo sekundy, nie milisekundy. Ak čakáš sub-sekundový failover, toto nie je BGP.
  • Switch a ARP cache. Po failoveri sa pošle gratuitous ARP, ale niektoré switche držia starú MAC v cache dlhšie, než by mali. Krátky výpadok po prepnutí leadra je normálny.
  • externalTrafficPolicy: Local je nekompatibilné. Packety padajú na nodoch bez podu. Drž Cluster, ak nevieš veľmi presne, čo robíš.

KubeVIP pre HA control plane

LB IPAM rieši aplikačné služby, ale control plane potrebuje vlastnú vysoko dostupnú VIP — jeden stabilný endpoint pre API server naprieč viacerými mastermi. Na to používam KubeVIP v ARP režime. Leader sa zvolí cez Kubernetes lease, prevezme VIP a pošle gratuitous ARP. Pri páde mastera ďalší leader VIP zdedí — rovnaký vzor ako pri L2 Announcements.

KubeVIP vie aj BGP režim, kde každý nod oznamuje VIP ako /32 route a dostaneš ECMP a smerovateľný failover cez L3 hranice. Ak máš BGP-schopné top-of-rack routery, je to lepšie. Ja som zostal pri ARP — jednoduchšie, žiadna závislosť na sieťovom tíme, a pre control plane úplne stačí.

Network policies a Hubble

Keď už beží Cilium, dostaneš CiliumNetworkPolicy zadarmo. Oproti štandardným L3/L4 policies vie aj L7 — povoliť napríklad len GET /api a zvyšok HTTP zahodiť. To natívny Kubernetes nevie.

A Hubble je dôvod, prečo by si Cilium chcel aj keby kvôli ničomu inému. Je to observability vrstva nad eBPF dátovou cestou — vidíš v reálnom čase, ktorý pod komunikuje s ktorým, čo policy zahadzuje a prečo. Debugovanie „prečo to spojenie padá" sa z hádania mení na pozeranie. Pri písaní network policies je to neoceniteľné.

Záver

Na bare-metale dostaneš plnohodnotný type: LoadBalancer bez cloudu a v podstate bez extra komponentov: Cilium s kube-proxy replacementom, LB IPAM na prideľovanie IP, L2 Announcements na ARP, a KubeVIP na HA control plane. Najväčšie pasce nie sú v konfigurácii — sú v tom, ako sa správa tvoj switch a ARP cache. Maj Hubble po ruke a počítaj s tým, že failover na L2 je sekundový, nie okamžitý.