Cilium och eBPF

Cilium eBPF Tony Norlin

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

Video av Snacka Kubernetes med Conoa från 9 december 2021

Tony Norlin från Conoa om Cilium och eBPF

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:

  • Google har det som dataplan i Anthos och GKE
  • AWS har det för produkten EKS Anywhere
  • DigitalOcean för sin managerade produkt DOKS
  • Alibaba har det i sitt dataplan

Lär dig mer. Bland några av de större eBPF projekten kan nämnas

  • Hubble UI https://cilium.io/ https://github.com/cilium/hubble-ui
  • Tracee https://github.com/aquasecurity/tracee https://www.aquasec.com/
  • Sysdig och Falco https://sysdig.com/ https://github.com/falcosecurity
  • Pixie https://github.com/pixie-io/pixie https://pixielabs.ai/
  • Cilium https://cilium.io/ https://github.com/cilium/
  • Cilium Enterprise https://isovalent.com/
  • bpftrace https://bpftrace.org/ https://github.com/iovisor/bpftrace

Dela inlägg

Dela på facebook
Dela på linkedin
Dela på twitter
Dela på email