Cilium och eBPF

Datum: 2021-12-10
Kategorier: Snacka Kubernetes med Conoa

Cilium och eBPF stod på agendan för Snacka Kubernetes med Conoa 9 december 2021. Tony Norlin bjuder på presentation och demo. Anmäl dig här för att vara med live på nästa meetup.

Tony är Senior Infrastructure Engineer och Kubernetes-konsult på Conoa. Under dagens dragning ger han en bakgrund kring instrumentering, BPF, eBPF, Cilium med mera.

Miljön för demo:

Maskinerna skapas med hjälp av cloud-init och json-templates och får ”senaste” Ubuntu 21.04 hirsute cloud image (kernel v5.11.0-40)
För att snabba på flödet så har Tony satt upp ett lokalt repo med nödvändiga paket och filer, samt en gemensam filyta över NFS för delning av konfiguration
Tummat lite på säkerheten för att ge en bra upplevelse

Målet med demo:

Två separata vm-baserade små kluster segmenterade med olika VLAN
Cilium utan kube-proxy
Hubble
Klustren ihopkopplade med en funktion som heter Cluster Mesh

Om instrumentering

Instrumentering används för att få ökad förståelse över applikationen/systemet och typiska inriktningar är:

Prestandamätning – exempelvis genom profilering med histogram
Event loggning – auditing
Diagnostik – felsökning, telemetri

Statisk instrumentering har nackdelen att den lämnar ett avtryck hos applikationen, antingen i form av prestanda eller stabilitet. Instrumenteringskoden måste kompileras in i kerneln/applikationen innan den körs.

Dynamisk instrumentering används bara vid behov, genom så kallad just-in-time (JIT) kompilering och lämnar inget avtryck efter sig när det inte används. Man kan se det som att Kernelns systemanrop/funktioner utökas dynamiskt och återställs efter instrumenteringen.

Vad betyder eBPF och vilken nytta har man av det

BPF = Berkeley Packet Filter
eBPF står för extended BPF (i motsats till cBPF som är classic BPF) och är ett eget subsystem i Linux kerneln (sedan v3.18)

Från början var extended BPF tänkt att som en modernare implementation av BPF, exempelvis för user-space verktyg som paketanalys (tcpdump), men användningsområdet har sedan dess utökats och det vi främst ska beröra är nätverkskommunikation och hur detta ersätter kube-proxy genom att nyttja en vassare design (kortare kodvägar).

eBPFs instrumentering lägger man in en gång hos noden och sen är instrumenteringen tillgänglig för såväl observabilitet som säkerhet och nätverk.

Vad är eBPF

eBPF program är event-drivna och körs när kerneln triggar en ”hook”, och det finns olika fördefinierade hooks för bland annat: systemanrop, funktions-anrop/avslut, kernel tracepoint, nätverks events.

Även där det inte finns en hook, finns det möjlighet att nyttja kernel probe (kprobe) eller user probe (uprobe) för att ansluta eBPF nästan överallt i systemet.

Några av de kritiska komponenterna för eBPF:

kernel hook som triggas av event.
kod – en variant av C kompileras till eBPF bytecode.
Sandbox – Koden granskas i en sandbox innan den laddas in vid den hook som triggades
Helper – det kompilerade eBPF-programmet kan i sin tur anropa speciella hjälpfunktionerna
eBPF map – Interfacet mellan system- och user-space. BPF i sig är stateless och eBPF maps skapar ”states” och konfigurationer med nyckel-värde-par.

Två hooks som är intressanta för trafik:

XDP – eXpress Data Path kör ett BPF-program vid det tidigast möjliga tillfället i kodvägen, nämligen direkt som nätverksmodulen tar emot paketet. XDP är för närvarande enbart ingress.

Till användningsområden hör: brandvägg (XDP_DROP, XDP_PASS eller XDP_REDIRECT),lastbalansering och paketforward (XDP_TX, XDP_REDIRECT), flöden och paketanalys.

tc – traffic control ingress/egress kommer något senare i flödet än XDP, precis i början av nätverksstacken och körs innan nätverkslagret (L3). Användningsområdet hos tc är är liknande XDP, men används idealiskt för nodens lokala trafik – hos veth (virtuella nätverksinterface)

Cilium

Cilium är ett CNI som är uppbyggt kring eBPF, och som nyttjar tidigare nämnda hooks.

Denna teknik kan avsevärt förbättra nätverksprestandan hos stora kluster, särskilt om man jämför med kube-proxy i iptables-läge då varje service skapar minst två nya regler, men Cilium erbjuder även funktioner som:

Loggning av Policy och Network Flows
Metrics – Cilium kan metrics över nätverksflöden till prometheus och med metadata som vilken applikation/pod skapade anslutningen
Transparent kryptering (utan sidecar) – IPSec eller WireGuard
Network Policies, såväl Kubernetes Network Policies som Cluster Wide Network Policies och L7-policies ( tillåta/blocka enskilda /URL-path)
Skalbarhet – där iptables lider av skalbarhetsproblem på grund av att reglerna läggs i kedjor med långa listor som måste göras hos varje nod (sökningen sker genom en linjär sökalgoritm), så använder eBPF en snabbare algoritm genom hash maps.

CNCF incubating project

Ungefär ett halvår efter ansökan accepteras Cilium i oktober 2021 till att vara ett CNCF incubating project.I och med att Cilium, som enda CNI, har nått mognadsgraden incubating kommer det rimligen att bli ett naturligt förstahandsval hos större aktörer.

Som exempel bland större moln som använder Cilium är: